Bug? Improper interaction with python variable _ ?

Bug? Improper interaction with python variable _ ?

[Brian Beckman]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

Please see the gist below for a self-explaining example
copied here for convenience.  Emacs 24.5.1 with org-mode
8 something (not sure how to get it to report its exact
version)... a very late version, I am sure.  Verified with
no init.el, that is, with emacs -Q

https://gist.github.com/rebcabin/37f800da658f4b23ceaa

#+TITLE: Org-Babel Bug?
#+AUTHOR: Brian Beckman
#+EMAIL: bc.beckman@gmail.com

#+BEGIN_SRC emacs-lisp :exports results :results none
  (setq org-confirm-babel-evaluate nil)
  (org-babel-map-src-blocks nil (org-babel-remove-result))
#+end_src

* Mystery Number 1

The first line of the first block must be blank, or we must =C-c C-c= the block
two times. But we want to eval the entire file /via/ =C-c C-v C-b=, and we found
that the first line must be empty.

If you =C-c C-v C-b= this entire file, the python session buffer, named
=*bug-org-babel*=, contains an error message that suggests the variable =_= is
implicated in an error.

We expect the value of this first block to be 999.  Make sure that the python
session is clear by typing =quit()=, then evaluate this entire file by
=C-c C-v C-b=.

#+NAME: probe
#+BEGIN_SRC python :session bug-org-babel :exports both :results value

  999
#+END_SRC

#+RESULTS: probe
: 999

* Mystery Number 2

Now, we set the value of the variable =_= to something arbitray. In a real
scenario, this variable may be set casually in a loop or some other context. The
variable =_= is often recommended for /ad-hoc/ use, as in "don't care."

#+NAME: second-probe
#+BEGIN_SRC python :session bug-org-babel :exports both :results value
  _ = 42
  _
#+END_SRC

#+RESULTS: second-probe
: 42

But now, all blocks with =:results value= return the value of =_=. We broke
org-babel!

#+NAME: third-probe
#+BEGIN_SRC python :session bug-org-babel :exports both :results value
  999
#+END_SRC

#+RESULTS: third-probe
: 42

[-- Attachment #2: Type: text/html, Size: 2549 bytes --]

Re: Bug? Improper interaction with python variable _ ?

[Brian Beckman]

[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]

Correction: The first elisp-block should contain another command

Here is the corrected org-mode file, top-to-bottom

#+TITLE: Org-Babel Bug?
#+AUTHOR: Brian Beckman
#+EMAIL: bc.beckman@gmail.com

#+BEGIN_SRC emacs-lisp :exports results :results none
  (org-babel-do-load-languages
    'org-babel-load-languages '((python . t)))
  (setq org-confirm-babel-evaluate nil)
  (org-babel-map-src-blocks nil (org-babel-remove-result))
#+end_src

* Mystery Number 1

The first line of the first block must be blank, or we must =C-c C-c= the
block
two times. But we want to eval the entire file /via/ =C-c C-v C-b=, and we
found
that the first line must be empty.

If you =C-c C-v C-b= this entire file, the python session buffer, named
=*bug-org-babel*=, contains an error message that suggests the variable =_=
is
implicated in an error.

We expect the value of this first block to be 999.  Make sure that the
python
session is clear by typing =quit()=, then evaluate this entire file by
=C-c C-v C-b=.

#+NAME: probe
#+BEGIN_SRC python :session bug-org-babel :exports both :results value

  999
#+END_SRC

#+RESULTS: probe
: 999

* Mystery Number 2

Now, we set the value of the variable =_= to something arbitray. In a real
scenario, this variable may be set casually in a loop or some other
context. The
variable =_= is often recommended for /ad-hoc/ use, as in "don't care."

#+NAME: second-probe
#+BEGIN_SRC python :session bug-org-babel :exports both :results value
  _ = 42
  _
#+END_SRC

#+RESULTS: second-probe
: 42

But now, all blocks with =:results value= return the value of =_=. We broke
org-babel!

#+NAME: third-probe
#+BEGIN_SRC python :session bug-org-babel :exports both :results value
  999
#+END_SRC

#+RESULTS: third-probe
: 42




On Sun, Oct 4, 2015 at 10:12 PM, Brian Beckman <bc.beckman@gmail.com> wrote:

> Please see the gist below for a self-explaining example
> copied here for convenience.  Emacs 24.5.1 with org-mode
> 8 something (not sure how to get it to report its exact
> version)... a very late version, I am sure.  Verified with
> no init.el, that is, with emacs -Q
>
> https://gist.github.com/rebcabin/37f800da658f4b23ceaa
>
> #+TITLE: Org-Babel Bug?
> #+AUTHOR: Brian Beckman
> #+EMAIL: bc.beckman@gmail.com
>
> #+BEGIN_SRC emacs-lisp :exports results :results none
>   (setq org-confirm-babel-evaluate nil)
>   (org-babel-map-src-blocks nil (org-babel-remove-result))
> #+end_src
>
> * Mystery Number 1
>
> The first line of the first block must be blank, or we must =C-c C-c= the block
> two times. But we want to eval the entire file /via/ =C-c C-v C-b=, and we found
> that the first line must be empty.
>
> If you =C-c C-v C-b= this entire file, the python session buffer, named
> =*bug-org-babel*=, contains an error message that suggests the variable =_= is
> implicated in an error.
>
> We expect the value of this first block to be 999.  Make sure that the python
> session is clear by typing =quit()=, then evaluate this entire file by
> =C-c C-v C-b=.
>
> #+NAME: probe
> #+BEGIN_SRC python :session bug-org-babel :exports both :results value
>
>   999
> #+END_SRC
>
> #+RESULTS: probe
> : 999
>
> * Mystery Number 2
>
> Now, we set the value of the variable =_= to something arbitray. In a real
> scenario, this variable may be set casually in a loop or some other context. The
> variable =_= is often recommended for /ad-hoc/ use, as in "don't care."
>
> #+NAME: second-probe
> #+BEGIN_SRC python :session bug-org-babel :exports both :results value
>   _ = 42
>   _
> #+END_SRC
>
> #+RESULTS: second-probe
> : 42
>
> But now, all blocks with =:results value= return the value of =_=. We broke
> org-babel!
>
> #+NAME: third-probe
> #+BEGIN_SRC python :session bug-org-babel :exports both :results value
>   999
> #+END_SRC
>
> #+RESULTS: third-probe
> : 42
>
>
>

[-- Attachment #2: Type: text/html, Size: 5124 bytes --]

Re: Bug? Improper interaction with python variable _ ?

[Aaron Ecay]

Hi Brian,

2015ko urriak 5an, Brian Beckman-ek idatzi zuen:
> 
> Please see the gist below for a self-explaining example
> copied here for convenience.  Emacs 24.5.1 with org-mode
> 8 something (not sure how to get it to report its exact
> version)... a very late version, I am sure.  Verified with
> no init.el, that is, with emacs -Q
> 
> https://gist.github.com/rebcabin/37f800da658f4b23ceaa
> 
> #+TITLE: Org-Babel Bug?
> #+AUTHOR: Brian Beckman
> #+EMAIL: bc.beckman@gmail.com
> 
> #+BEGIN_SRC emacs-lisp :exports results :results none
>   (setq org-confirm-babel-evaluate nil)
>   (org-babel-map-src-blocks nil (org-babel-remove-result))
> #+end_src
> 
> * Mystery Number 1
> 
> The first line of the first block must be blank, or we must =C-c C-c= the block
> two times. But we want to eval the entire file /via/ =C-c C-v C-b=, and we found
> that the first line must be empty.
> 
> If you =C-c C-v C-b= this entire file, the python session buffer, named
> =*bug-org-babel*=, contains an error message that suggests the variable =_= is
> implicated in an error.
> 
> We expect the value of this first block to be 999.  Make sure that the python
> session is clear by typing =quit()=, then evaluate this entire file by
> =C-c C-v C-b=.

I’m not entirely sure what the error you are seeing is.  I tried running
the below src block both with and without the initial blank line.  In
both cases the result was 999, as expected, and no errors were reported
in the session buffer.

It would be good if you could use M-x org-version to report the exact
version of org you are using.

> 
> #+NAME: probe
> #+BEGIN_SRC python :session bug-org-babel :exports both :results value
> 
>   999
> #+END_SRC
> 
> #+RESULTS: probe
> : 999
> 
> * Mystery Number 2
> 
> Now, we set the value of the variable =_= to something arbitray. In a real
> scenario, this variable may be set casually in a loop or some other context. The
> variable =_= is often recommended for /ad-hoc/ use, as in "don't
> care."

In the python repl, _ is set to the result of the last statement.
ob-python uses that fact to extract the value from the python process.
I would expect that creating an overriding binding of _ would cause
strange problems like the one you reported.  So you should not assign to
_ in babel code.

-- 
Aaron Ecay