On Mon, Feb 17, 2020 at 3:46 PM Jack Kamm <jackk...@gmail.com> wrote:
> Hi John, > > John Kitchin <jkitc...@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. >
