From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: [PATCH] (Tiny) Tweak Python session null return value Date: Mon, 17 Feb 2020 17:27:45 -0500 Message-ID: References: <87a75hfah9.fsf@gmail.com> <877e0lf307.fsf@gmail.com> <87y2t1djsz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000039b8e5059ecd112b" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:52425) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3orx-0003hc-63 for emacs-orgmode@gnu.org; Mon, 17 Feb 2020 17:28:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3orv-0002L4-OU for emacs-orgmode@gnu.org; Mon, 17 Feb 2020 17:28:01 -0500 In-Reply-To: <87y2t1djsz.fsf@gmail.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-mx.org@gnu.org Sender: "Emacs-orgmode" To: Jack Kamm Cc: Bastien , org-mode-email --00000000000039b8e5059ecd112b Content-Type: text/plain; charset="UTF-8" On Mon, Feb 17, 2020 at 3:46 PM Jack Kamm wrote: > Hi John, > > John Kitchin writes: > > > I can see why you would want to see True/False there, but to get the > value, > > you need to specifically return what you want because AFAIK the body is > > wrapped in a function that is evaluated to get the value, it is not > simply > > the last thing that gets evaluated. > > This is true for non-session blocks, which require explicitly calling > "return". However, session blocks aren't wrapped in functions and don't > use "return" (even before the most recent patches). The problem is that > variables created in a function have local scope, so session blocks > can't be wrapped in functions. > Fair point, I am not a python session user (I have used the ob-ipython for a long time, or stand-alone python blocks), and I had forgotten or not known of this. Indeed in a REPL, you get something closer to what you originally suggested. >>> a = 1 >>> if a: ... True ... else: ... False ... True I guess I would expect something like that if I was using a Python session in org-mode. It is like a REPL that is easier to edit. My earlier concern is mostly related to consistency of what an org Python block does compared to what you might do at a REPL or from a script. I also note that I almost never use :results value, and almost always prefer :results output. That reflects the kind of stuff we usually do here though, and may not be representative of others. > > Your example clarified to me at least why it would be tricky to figure > > it out, you can't rely on the last line, for example. > > Since the recent patches, we do extract the last line, using the Python > ast module, however this only works if the last line is a top-level > statement like "f()" or "1+1", not an assignment (like "x = 1+1") or an > indented block (like "if:...else:..."). > > > I don't know if there is some special Python variable that contains > > that. > > There actually is -- in most Python interpreters, the variable "_" > (underscore) refers to the last statement, unless it's been explicitly > assigned to. This is what was previously relied on. Unfortunately, using > "_" for a dummy variable is a common Python idiom (e.g. "for _ in > range(10)"), and if used would break all subsequent Python session > blocks. So we no longer rely on "_". > In the standard Python interpreter, we can also use "__builtins__._", > but this doesn't work in IPython. Furthermore, this only works for code explicitly entered in the shell, it won't work for code executed in > "exec()" or "eval()", which we now rely on, because it handles > indentation much more robustly. In particular, ob-python sessions have > had longstanding issues with multiline indented blocks, which are now > solved in the recent patches. > --00000000000039b8e5059ecd112b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 17, 2020 at 3:46 PM Jac= k Kamm <jackkamm@gmail.com>= wrote:
Hi John,=

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> I can see why you would want to see True/False there, but to get the v= alue,
> you need to specifically return what you want because AFAIK the body i= s
> wrapped in a function that is evaluated to get the value, it is not si= mply
> the last thing that gets evaluated.

This is true for non-session blocks, which require explicitly calling
"return". However, session blocks aren't wrapped in functions= and don't
use "return" (even before the most recent patches). The problem i= s that
variables created in a function have local scope, so session blocks
can't be wrapped in functions.

Fair= point, I am not a python session user (I have used the ob-ipython for a lo= ng time, or stand-alone python blocks), and I had forgotten or not known of= this. Indeed in a REPL, you get something closer to what you originally su= ggested.

>>> a =3D 1

>>> if a:

... =C2=A0 =C2=A0 True

... else:

... =C2=A0 =C2=A0 False

...=C2=A0

True

=C2= =A0
I guess I would expect something like that if I was using a P= ython session in org-mode. It is like a REPL that is easier to edit.
<= div>
My earlier concern is mostly related to consistency of w= hat an org Python block does compared to what you might do at a REPL or fro= m a script. I also note that I almost never use :results value, and almost = always prefer :results output. That reflects the kind of stuff we usually d= o here though, and may not be representative of others.



> Your example clarified to me at least why it would be tricky to figure=
> it out, you can't rely on the last line, for example.

Since the recent patches, we do extract the last line, using the Python
ast module, however this only works if the last line is a top-level
statement like "f()" or "1+1", not an assignment (like = "x =3D 1+1") or an
indented block (like "if:...else:...").

>=C2=A0 I don't know if there is some special Python variable that c= ontains
> that.

There actually is -- in most Python interpreters, the variable "_"= ;
(underscore) refers to the last statement, unless it's been explicitly<= br> assigned to. This is what was previously relied on. Unfortunately, using "_" for a dummy variable is a common Python idiom (e.g. "for= _ in
range(10)"), and if used would break all subsequent Python session
blocks. So we no longer rely on "_".=C2=A0

In the standard Python interpreter, we can also use "__builtins__._&qu= ot;,
but this doesn't work in IPython. Furthermore, this only works for code=
explicitly entered in the shell, it won't work for code executed in
"exec()" or "eval()", which we now rely on, because it = handles
indentation much more robustly. In particular, ob-python sessions have
had longstanding issues with multiline indented blocks, which are now
solved in the recent patches.
--00000000000039b8e5059ecd112b--