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 <jkitc...@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 <aarone...@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
