Re: [O] odd/unexpected behavior with Python src blocks
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
Re: [O] odd/unexpected behavior with Python src blocks
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
[O] odd/unexpected behavior with Python src blocks
* 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
Re: [O] odd/unexpected behavior with Python src blocks
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
