On Mon, Mar 25, 2013 at 10: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.
Have *any* changes been made related to python recently? See my mailing list post with reproducible example: - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html This was definitely working for me with a minimal config and starting with `emacs -Q`. I cannot reproduce that example anymore. Sessions don't work any longer, named or un-named for me, and we had two data points (myself and Ista) for whom it worked (at least for named). I think something was changed that broke it for my working setup. Might be nice to figure out what that was. Is there a way to see one's local git history? Not the git log, but something like what git versions I've been hopping from/to with each successive pull? I could try and see what I was at on 3/20 when I posted that and when I last pulled? I see a change related to ob-python from Bastien on 3/19... perhaps I could switch to a commit prior to that and try again? John > > -- > Eric Schulte > http://cs.unm.edu/~eschulte
