From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jack Kamm Subject: Re: ob-python newline & indentation behavior Date: Mon, 20 Nov 2017 21:31:02 +0000 Message-ID: References: <87h8trtyoa.fsf@kyleam.com> <8760a5tqjo.fsf@kyleam.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c19024aa203a3055e70cd4c" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGtej-0004Gb-9G for emacs-orgmode@gnu.org; Mon, 20 Nov 2017 16:31:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGtei-0006GY-7j for emacs-orgmode@gnu.org; Mon, 20 Nov 2017 16:31:05 -0500 Received: from mail-yb0-x236.google.com ([2607:f8b0:4002:c09::236]:33238) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eGteh-0006CL-Uq for emacs-orgmode@gnu.org; Mon, 20 Nov 2017 16:31:04 -0500 Received: by mail-yb0-x236.google.com with SMTP id y14so3619528ybi.0 for ; Mon, 20 Nov 2017 13:31:03 -0800 (PST) In-Reply-To: <8760a5tqjo.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 --94eb2c19024aa203a3055e70cd4c Content-Type: text/plain; charset="UTF-8" Hi Kyle, 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 I think this would work a lot better than the current approach. 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). Thanks for reviewing my suggested changes. Might be a few days until I can submit a new patch but I will incorporate your other suggestions. Waiting for the FSF forms anyways. Jack --94eb2c19024aa203a3055e70cd4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kyle,
=C2=A0
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 value" d= ifferently
depending on whether the block is hooked up to a session or not.=C2=A0 For<= br> non-sessions, you have to use return.=C2=A0 Using the same approach
(org-babel-python-wrapper-method) for ":session :results value&qu= ot;, we
could then get the return value reliably, but the problem with this
approach is that any variables defined in a ":results value" bloc= k
wouldn't be defined in the session after executing the block because th= e
code is wrapped in a function.

How a= bout if we used the "globals()" and "locals()" function= s in Python?

Something like this at the end of the wrapper block, before return:<= /div>

for k,= v in locals().items():
=C2=A0 =C2=A0 globa= ls()[k] =3D v


I think this would work a lot = better than the current approach.

Another bug with the current approach is that i= t breaks if common idioms like "for _ in range(10)" are used. (&q= uot;_" is used to inspect the last output of the shell, an obscure fea= ture I hadn't known about until now).
<= br>
Thanks for reviewing my suggested chang= es. Might be a few days until I can submit a new patch but I will incorpora= te your other suggestions. Waiting for the FSF forms anyways.

Jack

--94eb2c19024aa203a3055e70cd4c--