From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Ond=C5=99ej_Grover?= Subject: Re: Proposal and RFC for improving ob-python Date: Thu, 10 Dec 2015 08:47:47 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3440e6f3b550526866d13 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6vxR-0006vZ-Tl for emacs-orgmode@gnu.org; Thu, 10 Dec 2015 02:48:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6vxQ-0000V2-TZ for emacs-orgmode@gnu.org; Thu, 10 Dec 2015 02:48:09 -0500 Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:36450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6vxQ-0000Ul-J2 for emacs-orgmode@gnu.org; Thu, 10 Dec 2015 02:48:08 -0500 Received: by lbblt2 with SMTP id lt2so44778712lbb.3 for ; Wed, 09 Dec 2015 23:48:07 -0800 (PST) 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: emacs-orgmode@gnu.org --001a11c3440e6f3b550526866d13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the feedback Kyle. > As I understand it (and if I'm remembering correctly), there are at > least three issues with ob-python sessions: 4. session and non-session code differs significantly as you have already mentioned > So for non-session code and value results, the main idea is to get rid > of the need for "return" at the end? > Yes, that's the greatest offense to the Python code. > > 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. > Yes, these would be the obvious benefits. > But what about when :results !=3D value? Doesn't your proposal only > handle returning the last value? > You mean :results output ? In that case it could just omit the "open(...).write(...) " part and capture anything the console prints before the primary prompt appears again. Or it could capture stdout into a file, but I think that's needlessly complicated: python -i << HEREDOC_END import sys sys.stdout =3D open() # replace stdout with some file _ =3D block_eval(""" """) sys.stdout.close() sys.stdout =3D sys.__stdout__ # restore stdout HEREDOC_END After thinking about this, perhaps it is better to capture the block result into "_" instead of "ret", because a) it prevents name clashes b) it is more in line with what "_" is used for Kind regards, Ond=C5=99ej Grover --001a11c3440e6f3b550526866d13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the feedback Kyl= e.=C2=A0
As I understand it (and if = I'm remembering correctly), there are at
least three issues with ob-python sessions:
4. sess= ion and non-session code differs significantly as you have already mentione= d=C2=A0
So for non-session code and = value results, the main idea is to get rid
of the need for "return" at the end?
= Yes, that's the greatest offense to the Python code.=C2=A0

This seems useful to me.=C2=A0 Requiring a trailing "return", whi= ch 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).=C2=A0 Also, it would allow switching from ":results val= ue" to
":results output" without needing to remove "return" in= order to avoid a
syntax error.
Yes, these would be the obvious b= enefits.=C2=A0
But what about when := results !=3D value?=C2=A0 Doesn't your proposal only
handle returning the last value?
You mean :resu= lts output ? In that case it could just omit the "open(...).write(...)= " part and capture anything the console prints before the primary pro= mpt appears again.
Or it could capture stdout into a file, but I = think that's needlessly complicated:
python -i << = HEREDOC_END
import sys
sys.stdout =3D=C2=A0open(<TMP= FILE or PIPE>) =C2=A0 # replace stdout with some file
_ =3D b= lock_eval("""
<CODE BLOCK BODY>
&q= uot;"")
sys.stdout.close()
sys.stdout =3D sys= .__stdout__ =C2=A0# restore stdout
HEREDOC_END
After thinking about this, perhaps it is better to capture the= block result into "_" instead of "ret", because
<= div>a) it prevents name clashes
b) it is more in line with what &= quot;_" is used for

Kind regards,
O= nd=C5=99ej Grover

--001a11c3440e6f3b550526866d13--