From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Jack Kamm <jackkamm@gmail.com>
Cc: Bastien <bzg@gnu.org>, org-mode-email <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] (Tiny) Tweak Python session null return value
Date: Mon, 17 Feb 2020 17:27:45 -0500 [thread overview]
Message-ID: <CAJ51ETqVUycMg95nUNUPKp6b8gP3ek53Bd+DqwAKbaQeZeas+Q@mail.gmail.com> (raw)
In-Reply-To: <87y2t1djsz.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]
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.
>
[-- Attachment #2: Type: text/html, Size: 6289 bytes --]
prev parent reply other threads:[~2020-02-17 22:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 16:24 [PATCH] (Tiny) Tweak Python session null return value Jack Kamm
2020-02-17 17:42 ` Bastien
2020-02-17 19:07 ` Jack Kamm
2020-02-17 22:53 ` Bastien
2020-02-17 17:52 ` John Kitchin
2020-02-17 19:05 ` Jack Kamm
2020-02-17 19:45 ` John Kitchin
2020-02-17 20:45 ` Jack Kamm
2020-02-17 22:27 ` John Kitchin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ51ETqVUycMg95nUNUPKp6b8gP3ek53Bd+DqwAKbaQeZeas+Q@mail.gmail.com \
--to=jkitchin@andrew.cmu.edu \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=jackkamm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).