* odd/unexpected behavior with Python src blocks
@ 2014-09-28 22:11 John Kitchin
2014-09-29 1:27 ` Aaron Ecay
0 siblings, 1 reply; 4+ messages in thread
From: John Kitchin @ 2014-09-28 22:11 UTC (permalink / raw)
To: emacs-orgmode
* Odd behavior in python src-blocks in org-mode
I found that some code blocks in Python execute due to apparently silent
errors! here is how to reproduce it with a vanilla emacs -q.
#+BEGIN_SRC emacs-lisp
(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . t)
(python . t)))
(setq org-confirm-babel-evaluate nil)
#+END_SRC
#+RESULTS:
This block should raise an error (and does) because k is not defined.
#+BEGIN_SRC python
def f(y, x):
return k * y
print(f(1, 0))
#+END_SRC
#+RESULTS:
It raises this error.
#+BEGIN_EXAMPLE
Traceback (most recent call last):
File "<stdin>", line 4, in <module>
File "<stdin>", line 2, in f
NameError: global name 'k' is not defined
#+END_EXAMPLE
However, this code block actually executes, and gives the wrong answer! If I open the source block in Python mode, it does not run without error.
#+BEGIN_SRC python :results output
from scipy.integrate import odeint
def f(y, x):
return k * y
print(odeint(f, 1, [0, 1]))
#+END_SRC
#+RESULTS:
: [[ 1.]
: [ 1.]]
Here is the correct answer.
#+BEGIN_SRC python :results output
from scipy.integrate import odeint
k = -1
def f(y, x):
return k * y
print(odeint(f, 1, [0, 1]))
#+END_SRC
#+RESULTS:
: [[ 1. ]
: [ 0.36787947]]
I am not sure why this happens, but it seems like incorrect behavior to
me.
--
-----------------------------------
John Kitchin
http://kitchingroup.cheme.cmu.edu
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: odd/unexpected behavior with Python src blocks
2014-09-28 22:11 odd/unexpected behavior with Python src blocks John Kitchin
@ 2014-09-29 1:27 ` Aaron Ecay
2014-09-29 15:56 ` Instructor account
0 siblings, 1 reply; 4+ messages in thread
From: Aaron Ecay @ 2014-09-29 1:27 UTC (permalink / raw)
To: John Kitchin, emacs-orgmode
Hi John,
2014ko irailak 28an, John Kitchin-ek idatzi zuen:
[...]
> I am not sure why this happens, but it seems like incorrect behavior to
> me.
In the first case, python exits with a non-zero exit code, whereas in
the second it exits with a zero code (i.e. successful exit), and prints
the matrix-thing [[1.], [1.]] to stdout. It looks like scipy traps the
NameErrors and prints them to stderr, but continues its computation
regardless.
I’d say babel is performing as desired here, but scipy sadly isn’t
reporting its errors in the standard way (by a nonzero exit, which I
think would happen automatically if the NameErrors made it to the top
level of the stack without being caught).
--
Aaron Ecay
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: odd/unexpected behavior with Python src blocks
2014-09-29 1:27 ` Aaron Ecay
@ 2014-09-29 15:56 ` Instructor account
2014-09-29 18:03 ` John Kitchin
0 siblings, 1 reply; 4+ messages in thread
From: Instructor account @ 2014-09-29 15:56 UTC (permalink / raw)
To: emacs-orgmode
Indeed, this passes by org-babel because stderr is not captured, and
scipy does what you suggest. I guess this happens inside compiled
c/Fortran code since there is nothing catching it in the odeint
python function doing that.
Thanks, I will try to bring it up on the scipy list.
Aaron Ecay <aaronecay@gmail.com> writes:
> Hi John,
>
> 2014ko irailak 28an, John Kitchin-ek idatzi zuen:
>
> [...]
>
>> I am not sure why this happens, but it seems like incorrect behavior to
>> me.
>
> In the first case, python exits with a non-zero exit code, whereas in
> the second it exits with a zero code (i.e. successful exit), and prints
> the matrix-thing [[1.], [1.]] to stdout. It looks like scipy traps the
> NameErrors and prints them to stderr, but continues its computation
> regardless.
>
> I’d say babel is performing as desired here, but scipy sadly isn’t
> reporting its errors in the standard way (by a nonzero exit, which I
> think would happen automatically if the NameErrors made it to the top
> level of the stack without being caught).
--
-----------------------------------
John Kitchin
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: odd/unexpected behavior with Python src blocks
2014-09-29 15:56 ` Instructor account
@ 2014-09-29 18:03 ` John Kitchin
0 siblings, 0 replies; 4+ messages in thread
From: John Kitchin @ 2014-09-29 18:03 UTC (permalink / raw)
To: emacs-orgmode
In case anyone else is interested, here is a workaround of sorts to
capture stderr in a python block:
https://github.com/jkitchin/pycse/blob/master/pycse/sandbox.py
You use this module to redefine stdout and stderr. You basically run
python like this:
#+BEGIN_SRC emacs-lisp
(setq org-babel-python-command "python -m pycse.sandbox")
#+END_SRC
Then you get this output.
#+BEGIN_SRC python :results output
from scipy.integrate import odeint
#k = -1
def f(y, x):
return -k * y
print(odeint(f, 1, [0, 1]))
#+END_SRC
#+RESULTS:
#+begin_example
sandbox:
---stdout-----------------------------------------------------------
[[ 1.]
[ 1.]]
---stderr-----------------------------------------------------------
Traceback (most recent call last):
File "<string>", line 6, in f
NameError: global name 'k' is not defined
Traceback (most recent call last):
File "<string>", line 6, in f
NameError: global name 'k' is not defined
Traceback (most recent call last):
File "<string>", line 6, in f
NameError: global name 'k' is not defined
Traceback (most recent call last):
File "<string>", line 6, in f
NameError: global name 'k' is not defined
#+end_example
At least until babel captures stderr, this is a way to capture it. It does break the nice behavior of making tables output, since it
prints a string. The string could be orgified somewhat, eg
#+STDOUT:
#+STDERR:
I am not sure I will use this routinely, so I am not sure how much I
will put into furhter development.
Instructor account <jkitchin@andrew.cmu.edu> writes:
> Indeed, this passes by org-babel because stderr is not captured, and
> scipy does what you suggest. I guess this happens inside compiled
> c/Fortran code since there is nothing catching it in the odeint
> python function doing that.
>
> Thanks, I will try to bring it up on the scipy list.
>
> Aaron Ecay <aaronecay@gmail.com> writes:
>
>> Hi John,
>>
>> 2014ko irailak 28an, John Kitchin-ek idatzi zuen:
>>
>> [...]
>>
>>> I am not sure why this happens, but it seems like incorrect behavior to
>>> me.
>>
>> In the first case, python exits with a non-zero exit code, whereas in
>> the second it exits with a zero code (i.e. successful exit), and prints
>> the matrix-thing [[1.], [1.]] to stdout. It looks like scipy traps the
>> NameErrors and prints them to stderr, but continues its computation
>> regardless.
>>
>> I’d say babel is performing as desired here, but scipy sadly isn’t
>> reporting its errors in the standard way (by a nonzero exit, which I
>> think would happen automatically if the NameErrors made it to the top
>> level of the stack without being caught).
--
-----------------------------------
John Kitchin
Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-09-29 18:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-28 22:11 odd/unexpected behavior with Python src blocks John Kitchin
2014-09-29 1:27 ` Aaron Ecay
2014-09-29 15:56 ` Instructor account
2014-09-29 18:03 ` John Kitchin
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).