emacs-orgmode
[Top][All Lists]
Advanced

[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



reply via email to

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