ob-ipython has a bug which renders it basically unusable to me -- it crashes when trying to interrupt the kernel with C-c C-c, which is something I often find myself needing to do (see https://github.com/gregsexton/ob-ipython/issues/115).
However I agree that ob-ipython is very promising and could lead to org-babel becoming a viable jupyter notebook alternative in the future. Having :async execution is especially cool, if somewhat buggy right now. I hope ob-ipython continues to improve. Nevertheless, I would like ob-python to work properly, regardless of ob-ipython, as I like being able to use an python session in emacs without jupyter. On Sun, Nov 26, 2017 at 2:45 AM, Ista Zahn <istaz...@gmail.com> wrote: > ob-ipython[1] provides a working alternative: > > #+BEGIN_SRC jupyter-python :session :results output > foo = 0 > for _ in range(10): > foo += 1 > > foo += 1 > > print(foo) > #+END_SRC > > #+RESULTS: > : 20 > > I've long wished that more org people would show ob-ipython some love. > Letting jupyter handle things on the backend seems like it should > simplifly things considerably. > > [1] https://github.com/gregsexton/ob-ipython > > Best, > Ista > > On Tue, Nov 21, 2017 at 3:28 AM, Jack Kamm <jackk...@gmail.com> wrote: > > Yes, I'm starting to see now how difficult it is to properly support > > ":session :results value". I would vote to remove it from ob-python... > > > > I think the patch still improves ":session :results output" so I will > > simplify it and restrict to that case, leaving ":session :results value" > > unchanged for now. > > > > Sorry for sending this twice Kyle, forgot to reply all. > > > > On 21 Nov 2017 4:04 am, "Kyle Meyer" <k...@kyleam.com> wrote: > >> > >> Jack Kamm <jackk...@gmail.com> writes: > >> > >> > In response to this: > >> > > >> >> I can't think of a good solution, though. Stepping back a bit, I > think > >> >> it's unfortunate that python blocks handle ":results value" > differently > >> >> depending on whether the block is hooked up to a session or not. For > >> >> non-sessions, you have to use return. Using the same approach > >> >> (org-babel-python-wrapper-method) for ":session :results value", we > >> >> could then get the return value reliably, but the problem with this > >> >> approach is that any variables defined in a ":results value" block > >> >> wouldn't be defined in the session after executing the block because > >> >> the > >> >> code is wrapped in a function. > >> > > >> > How about if we used the "globals()" and "locals()" functions in > Python? > >> > > >> > Something like this at the end of the wrapper block, before return: > >> > > >> > for k, v in locals().items(): > >> > globals()[k] = v > >> > >> Hmm, placing that code "before return" is a problem. Like with > >> non-session ":results value" blocks, the user would be responsible for > >> inserting the return (or even multiple return's), so we can't know where > >> to insert the above code without parsing the block :/ > >> > >> > Another bug with the current approach is that it breaks if common > idioms > >> > like "for _ in range(10)" are used. ("_" is used to inspect the last > >> > output > >> > of the shell, an obscure feature I hadn't known about until now). > >> > >> Right. Also, IIRC the built-in interactive python and ipython treat > >> multiline blocks differently. With > >> > >> if True: > >> "ipython ignores my existence" > >> > >> the built-in shell binds "_" to the string's value, but ipython doesn't. > >> > >> -- > >> Kyle >
