[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
- Re: [O] python sessions, (continued)
- Re: [O] python sessions, Gary Oberbrunner, 2013/03/20
- Re: [O] python sessions, Andreas Röhler, 2013/03/21
- Re: [O] python sessions, Bastien, 2013/03/21
- Re: [O] python sessions, Andreas Röhler, 2013/03/21
- Re: [O] python sessions, Eric Schulte, 2013/03/23
- Re: [O] python sessions, John Hendy, 2013/03/23
- Re: [O] python sessions, Eric Schulte, 2013/03/24
- Re: [O] python sessions, Nick Dokos, 2013/03/24
- Re: [O] python sessions, John Hendy, 2013/03/24
- Re: [O] python sessions, Andreas Röhler, 2013/03/25
- Re: [O] python sessions,
Eric Schulte <=
- Re: [O] python sessions, John Hendy, 2013/03/25
- Re: [O] python sessions, Eric Schulte, 2013/03/25
- Re: [O] python sessions, Nick Dokos, 2013/03/25
- Re: [O] python sessions, Ista Zahn, 2013/03/25
- Re: [O] python sessions, John Hendy, 2013/03/25
- Re: [O] python sessions, Eric Schulte, 2013/03/25
- Re: [O] python sessions, Andreas Röhler, 2013/03/25
- Re: [O] python sessions, John Hendy, 2013/03/25
- Re: [O] python sessions, Ista Zahn, 2013/03/25
- Re: [O] python sessions, Ivan Andrus, 2013/03/25