On Mon, Feb 17, 2020 at 3:46 PM Jack 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
> 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.
>