From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jack Kamm Subject: Re: ob-python newline & indentation behavior Date: Tue, 21 Nov 2017 08:28:49 +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="001a113f5fea124b2b055e79fe5c" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eH3vI-0006HB-86 for emacs-orgmode@gnu.org; Tue, 21 Nov 2017 03:28:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eH3vH-0000E4-1G for emacs-orgmode@gnu.org; Tue, 21 Nov 2017 03:28:52 -0500 Received: from mail-yb0-x22b.google.com ([2607:f8b0:4002:c09::22b]:39203) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eH3vG-0000DW-Rv for emacs-orgmode@gnu.org; Tue, 21 Nov 2017 03:28:50 -0500 Received: by mail-yb0-x22b.google.com with SMTP id n185so3890075yba.6 for ; Tue, 21 Nov 2017 00:28:50 -0800 (PST) In-Reply-To: <87r2ssp99s.fsf@kyleam.com> 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: Kyle Meyer Cc: emacs-orgmode@gnu.org --001a113f5fea124b2b055e79fe5c Content-Type: text/plain; charset="UTF-8" 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 > --001a113f5fea124b2b055e79fe5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I'm starting to see now how difficult it is to properly support &= quot;:session :results value". I would vote to remove it from ob-pytho= n...

I think the patch still improves ":session :results output&= quot; so I will simplify it and restrict to that case, leaving ":sessi= on :results value" unchanged for now.

Sorry for sending this twic= e Kyle, forgot to reply all.

On 21 Nov 2017 4:04 am, "Kyle Meyer" <<= a href=3D"mailto:kyle@kyleam.com">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 Stepping back = a bit, I think
>> it's unfortunate that python blocks handle ":results valu= e" 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 same approac= h
>> (org-babel-python-wrapper-method) for ":session :results= value", we
>> could then get the return value reliably, but the problem with thi= s
>> approach is that any variables defined in a ":results value&q= uot; block
>> wouldn't be defined in the session after executing the block b= ecause 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():
>=C2=A0 =C2=A0 =C2=A0globals()[k] =3D v

Hmm, placing that code "before return" is a problem.=C2=A0 Like w= ith
non-session ":results value" blocks, the user would be responsibl= e 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 idio= ms
> like "for _ in range(10)" are used. ("_" is used t= o inspect the last output
> of the shell, an obscure feature I hadn't known about until now).<= br>
Right.=C2=A0 Also, IIRC the built-in interactive python and ipython treat multiline blocks differently.=C2=A0 With

=C2=A0 =C2=A0 if True:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ipython ignores my existence"

the built-in shell binds "_" to the string's value, but ipyth= on doesn't.

--
Kyle
--001a113f5fea124b2b055e79fe5c--