Re: [O] python sessions

[Andreas Röhler]

Am 27.03.2013 07:19, schrieb Andreas Röhler:
> Am 26.03.2013 22:41, schrieb Gary Oberbrunner:
> > I did some further testing.  With my patch, my real org-mode python file is
> > now actually working.  There were a few gotchas I didn't understand about
> > session mode and python and matplotlib:
> >
> > 1. In session mode, you are essentially running an interactive python.
> >   (This is made explicit by my patch, which passes -i).
> > 2. In interactive mode, blank lines are special: they indicate the end of
> > an indented block.  So you have to write your org-mode python a little
> > differently when using session mode.
> > 3. matplotlib uses an "interactive" backend when started from an
> > interactive python (sensibl

y).  So you have to set the backend explicitly
> > when using session mode, or it hangs forever with no indication what's
> > wrong.
> > 4. ob-python does not handle python errors at all in session mode: it
> > ignores them silently.  This makes it really hard to debug the python code.
> >
> > I'd like to document #s 1-3; where should that go?
> > I'd like to work on a patch for #4; it seems like the only thing is to
> > search in the session buffer for likely error strings.  Is there any better
> > method anyone can think of?
>
> AFAIU the error string is missing, because it's sent the wrong 
> path-to-interpreter,
> i.e. using shell-command.
> Shell returns 0 or 1, not the Python errors.
>
> Also the interactive spec is related. Usually Python shell as started from 
> py-shell or run-python include this already.
> When send from a python-mode, also the empty lines you mentioned and related 
> stuff is treated.
>
> Andreas

That turned out not being the case. I'm quoting:

> This is incorrect.  In session mode, there is one long-running python
> interpreter session.  Emacs passes it code snippets, and it spits out
> stdout and stderr (all mixed up: output from your program, the lines
> themselves which get echoed, prompts, and error messages if any).  There is
> never any "return" value since the python interpreter doesn't exit.  The
> only way to handle errors in interactive mode AFAICS is to use approximate
> regexes to look for errors, un-handled exceptions and so on.
>

Cheers