From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kyle Meyer Subject: Re: Proposal and RFC for improving ob-python Date: Thu, 10 Dec 2015 02:22:13 -0500 Message-ID: <87y4d2py3e.fsf@kyleam.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6vYV-0003aC-FC for emacs-orgmode@gnu.org; Thu, 10 Dec 2015 02:22:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6vYS-0001wA-9J for emacs-orgmode@gnu.org; Thu, 10 Dec 2015 02:22:23 -0500 Received: from pb-smtp0.int.icgroup.com ([208.72.237.35]:52244 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6vYS-0001vw-5i for emacs-orgmode@gnu.org; Thu, 10 Dec 2015 02:22:20 -0500 In-Reply-To: (=?utf-8?Q?=22Ond=C5=99ej?= Grover"'s message of "Sat, 5 Dec 2015 18:17:15 +0100") 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.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?utf-8?Q?Ond=C5=99ej?= Grover Cc: emacs-orgmode@gnu.org Ond=C5=99ej Grover writes: [...] > The ob-ipython project tries to solve this hackiness in a different way by > using the client-server infrastructure of IPython/Jupyter. That works qui= te > well too, but my hope is that improving ob-python.el would also make it > simpler to use IPython as the python REPL, relying only on the core of the > Python language. As I understand it (and if I'm remembering correctly), there are at least three issues with ob-python sessions: 1. Shell prompt markers leak into the output. 2. Whitespace at the beginning of the output is swallowed. 3. Valid code that has indentation and spaces cannot be sent. I think the first one is the race conditions that ob-ipython.el's README refers to. > It essentially boils down to implementing progn-like eval() function in > Python which would return the result of the last statement if it is an > expression. [...] > My proposal is to implement an equivalent of the following bash pseudo co= de > for non session mode > > python -i << HEREDOC_END > ret =3D block_eval(""" > > """) > open().write(str(ret)) > HEREDOC_END So for non-session code and value results, the main idea is to get rid of the need for "return" at the end? This seems useful to me. Requiring a trailing "return", which is a syntax error when the code is taken by itself, is a quirk of the implementation (the code ends up being wrapped in a function to get the return value). Also, it would allow switching from ":results value" to ":results output" without needing to remove "return" in order to avoid a syntax error. > For session mode it would be even simpler, lines containing HEREDOC above > would be dropped and the rest piped directly into the Python REPL. > > This also means that the 'org_babel_python_eoe' string indicator may not = be > necessary anymore because end of evaluation would be simply shown by a new > line with the primary prompt appearing. But what about when :results !=3D value? Doesn't your proposal only handle returning the last value? -- Kyle