From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jack Kamm Subject: Re: ob-python newline & indentation behavior Date: Sun, 26 Nov 2017 08:25:39 +0000 Message-ID: References: <87h8trtyoa.fsf@kyleam.com> <8760a5tqjo.fsf@kyleam.com> <87r2ssp99s.fsf@kyleam.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1141ca82ec85ce055ede87e7" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIsFy-0004kn-Gv for emacs-orgmode@gnu.org; Sun, 26 Nov 2017 03:25:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIsFw-0003EW-L2 for emacs-orgmode@gnu.org; Sun, 26 Nov 2017 03:25:42 -0500 Received: from mail-yw0-x22c.google.com ([2607:f8b0:4002:c05::22c]:36661) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIsFw-0003EO-En for emacs-orgmode@gnu.org; Sun, 26 Nov 2017 03:25:40 -0500 Received: by mail-yw0-x22c.google.com with SMTP id g193so594590ywe.3 for ; Sun, 26 Nov 2017 00:25:40 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Ista Zahn Cc: emacs-orgmode Mailinglist --001a1141ca82ec85ce055ede87e7 Content-Type: text/plain; charset="UTF-8" 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 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 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" wrote: > >> > >> Jack Kamm 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 > --001a1141ca82ec85ce055ede87e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ob-ipython has a bug which renders it basically unusable t= o 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=C2=A0https://github.com/gregsexton= /ob-ipython/issues/115).

However I agree that ob-ipy= thon is very promising and could lead to org-babel becoming a viable jupyte= r 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 prop= erly, regardless of ob-ipython, as I like being able to use an python sessi= on in emacs without jupyter.

On Sun, Nov 26, 2017 at 2:45 AM, Ista Zahn <istaza= hn@gmail.com> wrote:
ob-ipy= thon[1] provides a working alternative:

#+BEGIN_SRC jupyter-python :session :results output
=C2=A0 foo =3D 0
=C2=A0 for _ in range(10):
=C2=A0 =C2=A0 =C2=A0 foo +=3D 1

=C2=A0 =C2=A0 =C2=A0 foo +=3D 1

=C2=A0 print(foo)
#+END_SRC

#+RESULTS:
: 20

I've long wished that more org people would show ob-ipython some love.<= br> 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 <jackkamm@gmail.com> wrote:
> Yes, I'm starting to see now how difficult it is to properly suppo= rt
> ":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" <kyle@kyleam.com> wrote:
>>
>> Jack Kamm <jackkamm@gmail= .com> writes:
>>
>> > In response to this:
>> >
>> >> I can't think of a good solution, though.=C2=A0 Stepp= ing back a bit, I think
>> >> it's unfortunate that python blocks handle ":res= ults value" differently
>> >> depending on whether the block is hooked up to a session = or not.=C2=A0 For
>> >> non-sessions, you have to use return.=C2=A0 Using the sam= e 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 ":result= s value" block
>> >> wouldn't be defined in the session after executing th= e block because
>> >> the
>> >> code is wrapped in a function.
>> >
>> > How about if we used the "globals()" and "loca= ls()" functions in Python?
>> >
>> > Something like this at the end of the wrapper block, before r= eturn:
>> >
>> > for k, v in locals().items():
>> >=C2=A0 =C2=A0 =C2=A0globals()[k] =3D v
>>
>> Hmm, placing that code "before return" is a problem.=C2= =A0 Like with
>> non-session ":results value" blocks, the user would be r= esponsible for
>> inserting the return (or even multiple return's), so we can= 9;t know where
>> to insert the above code without parsing the block :/
>>
>> > Another bug with the current approach is that it breaks if co= mmon 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 unt= il now).
>>
>> Right.=C2=A0 Also, IIRC the built-in interactive python and ipytho= n treat
>> multiline blocks differently.=C2=A0 With
>>
>>=C2=A0 =C2=A0 =C2=A0if True:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipython ignores my existenc= e"
>>
>> the built-in shell binds "_" to the string's value, = but ipython doesn't.
>>
>> --
>> Kyle

--001a1141ca82ec85ce055ede87e7--