From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jack Kamm Subject: Re: [PATCH] (Tiny) Tweak Python session null return value Date: Mon, 17 Feb 2020 12:45:48 -0800 Message-ID: <87y2t1djsz.fsf@gmail.com> References: <87a75hfah9.fsf@gmail.com> <877e0lf307.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:38007) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3nI9-0004ar-42 for emacs-orgmode@gnu.org; Mon, 17 Feb 2020 15:46:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3nI8-0006VR-2n for emacs-orgmode@gnu.org; Mon, 17 Feb 2020 15:46:57 -0500 In-Reply-To: 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: John Kitchin Cc: Bastien , org-mode-email 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. > 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.