Re: [PATCH] (Tiny) Tweak Python session null return value

[John Kitchin]

On Mon, Feb 17, 2020 at 3:46 PM Jack Kamm <address@hidden> wrote:

Hi John,

John Kitchin <address@hidden> 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.