emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Babel Python sessions severely broken
@ 2012-03-09 18:20 Jacek Generowicz
  2012-03-09 20:31 ` Eric Schulte
  0 siblings, 1 reply; 4+ messages in thread
From: Jacek Generowicz @ 2012-03-09 18:20 UTC (permalink / raw)
  To: emacs-orgmode


Picking up a few-month-old thread ...

On Tue, 21 Jun 2011 10:26:17 -0700, Eric Schulte wrote:

> You are suggesting that code to be run "interactively" should be written
> to an external file then loaded into the interactive session.  This
> would certainly work around the syntax limitation of the current setup.
> My two concerns here are that
> 1. users who use interactive babel blocks side-by-side with the session
>    may be used jumping into the session to play with code interactively
>    and debug, in such cases rather than seeing their code in the session
>    history they would only see execfile('/tmp/blahblah').

This is (almost) exactly what Emacs' python mode does, so I suspect
that many people who wish to work in this way, would be very familiar
with this state of affairs.

Actually, In modern python modes (Emacs 23, 24, maybe even 22) no clue
about any code having been injected into the session appars at all:
instead of seeing "execfile(/'tmp/blah')" they see nothing at all. I
think that IPyton's emacs-python-mode, might visually inject the whole
evaluated code into the session buffer. 

>    Note I do recall discussion on list related to user's reading
>    their session code in the inferior session buffer.

I'd say that that interacting with their code in the session buffer is
more important than reading it there (on the grounds of this being the
usual python-mode workflow), but reading it there could be good too.

> 2. similarly error messages would now point into this temporary file,
>    rather than back into the session history

Yes, this is what happens in current python modes, but M-g M-n and M-g
M-p usually manage to send you to the correct place (i.e. your genuine
source file, rather than the temporary file) anyway.

To see this in action:

1. (In Emacs 23 or 24) Create the following buffer

,----[ foo.py ]
| print 1
| print 1/0
| print 2
2. Ensure that Python mode is enabled for the buffer (Emacs should
   have switched it on automatically, by observing the .py extension.)

3. C-c C-z (This should start an inferior Python process, and switch
   to its buffer.)

4. Go back to the foo.py buffer

5. C-c C-c (This should evaluate the whole buffer)

   The inferior Python buffer should now show something like

,----[ *Python* ]
| >>> 1
| Traceback (most recent call last):
|   File "/tmp/py79095qL", line 2, in <module>
|     print 1/0
| ZeroDivisionError: integer division or modulo by zero
| >>> 

6. M-g M-n (This should jump to line 2 in the foo.py buffer)

Maybe some of the stuff that's already in python-mode can be reused ?

> Basically you would prefer more decoupling from the interpreter

I would prefer it to be useable for evaluating normally formatted
Python code. In its current state it isn't. That makes it pretty much
unuseable for literal programming, creating documentation, tutorials,

I don't understand what you mean by "more decoupling from the
interpreter". Do you mean "overcoming Python's standard REPL's
inability to receive copy-pasted standard Pyton code?". I think that
would be a *very* worthwhile thing to support, which is why pretty
much anything that pretends to support Python interactivity, goes out
of its way to make it possible (Emacs' python-mode, IPython, IDLE are
a few obvious examples that come to mind.)

> and I'm not sure for the average user if this would be a worthwhile
> exchange simply to be able to avoid syntax errors like your
> originally mentioned example (which was the first such post I've
> seen on this list).

The current situation essentially makes Python babel sessions unusable
for anything but the most trivial cases. (Or it makes non-trivial use
possible at the cost of presening code in a horribly formatted style,
one which would be a horror to read.)

> I'm disinclined to make such a change without a wider base of support
> for the request from the Babel/Python user community

Please, please, make it possible to evaluate normal Python code in
Python babel sessions.

It's really important to understand that the restrictions imposed by
Python's plain REPL really are a horrible quirk: I can't imagine
anyone preferring the broken (if standard) behaviour, over correct

Put another way: You won't find many people who take Python
interactivity seriously, using the standard REPL. They all use
something that gets around the horrible restrictions it
imposes. Nobody wants this.

> or at least without more complaints about the existing behavior.

Please consider this to be a *vehement* complaint about the existing
behaviour. :-)

(I'd be happy to try to contribute some code to this, but I won't have
any time to think about it for, at least, the next 3 weeks.)

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-03-09 21:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-09 18:20 Babel Python sessions severely broken Jacek Generowicz
2012-03-09 20:31 ` Eric Schulte
2012-03-09 21:05   ` Jacek Generowicz
2012-03-09 21:24     ` Eric Schulte

Code repositories for project(s) associated with this inbox:


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).