emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] python sessions


From: Eric Schulte
Subject: Re: [O] python sessions
Date: Mon, 25 Mar 2013 09:40:18 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

John Hendy <address@hidden> writes:

> On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos <address@hidden> wrote:
>> Eric Schulte <address@hidden> 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.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



reply via email to

[Prev in Thread] Current Thread [Next in Thread]