[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] odd/unexpected behavior with Python src blocks
From: |
John Kitchin |
Subject: |
Re: [O] odd/unexpected behavior with Python src blocks |
Date: |
Mon, 29 Sep 2014 14:03:16 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (darwin) |
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 <address@hidden> 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 <address@hidden> 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