On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte <schulte.e...@gmail.com> wrote: > John Hendy <jw.he...@gmail.com> writes: > >> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <nicholas.do...@hp.com> wrote: >>> Eric Schulte <schulte.e...@gmail.com> wrote: >>> >>>> > >>>> > From participating in evaluating code throughout the discussion and >>>> > catching the comments throughout, I'd say yes, at least in terms of >>>> > how other babel languages function. In other words =#+begin_src R >>>> > :session foo= creates an R session named "foo" whereas doing the same >>>> > with =python= instead of =R= does not yield a named session. >>>> > >>>> > From what others experienced, however, the functionality was working >>>> > correctly (results were persistent across blocks and two differently >>>> > names blocks created two different sessions), just not named >>>> > correctly. >>>> > >>>> >>>> See the cond form starting at line 169 in ob-python.el. Different >>>> session functionality is used based on the `org-babel-python-mode' >>>> variable, and on the version of Emacs in use (prior to 24.1 or not). >>>> >>>> The branch taken when `org-babel-python-mode' equals 'python is >>>> certainly broken, as it never saves the name of the newly created >>>> buffer, so session re-use and use of multiple named sessions probably >>>> works only when `org-babel-python-mode' equals 'python-mode. >>>> >>> >>> That's me: org-babel-python-mode's value is python, so it's no wonder >>> it's broken given what Eric says. I'm on emacs 24.3.50 where there is >>> python.el but no python-mode.el. I tried the "cheap" workaround of >>> switching the value to python-mode, but that does a (require >>> 'python-mode) somewhere, so that option is out as well. >> >> I'm on Emacs 24.3.1 and have no python-mode.el, either (only >> python.el). My setup is working correctly (again, with the caveat of >> not having named sessions). >> > > It sounds like we have the same setup, and the following un-named > session example does not work for me. The first code block evaluates > successfully, but it doesn't appear to be having any impact on the > default session (e.g., in the *Python* buffer). > > Returns the value of x as expected. > > #+begin_src python :session > x = 1 > return x > #+end_src > > #+RESULTS: > : 1 > > #+begin_src python :session > return x > #+end_src > > #+RESULTS: > > The second code block /should/ have access to the x variable defined > previous, but instead it throws an error because x is undefined. > > Currently I'd say session support for python is completely broken.
As of this morning I've joined the "it does not work" crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Best, Ista > > -- > Eric Schulte > http://cs.unm.edu/~eschulte >
