From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ista Zahn Subject: Re: ob-python newline & indentation behavior Date: Sat, 25 Nov 2017 21:45:17 -0500 Message-ID: References: <87h8trtyoa.fsf@kyleam.com> <8760a5tqjo.fsf@kyleam.com> <87r2ssp99s.fsf@kyleam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eImww-0004el-1R for emacs-orgmode@gnu.org; Sat, 25 Nov 2017 21:45:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eImwu-0004V2-Nt for emacs-orgmode@gnu.org; Sat, 25 Nov 2017 21:45:42 -0500 Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:44159) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eImwu-0004UO-F3 for emacs-orgmode@gnu.org; Sat, 25 Nov 2017 21:45:40 -0500 Received: by mail-lf0-x232.google.com with SMTP id w23so29045058lfd.11 for ; Sat, 25 Nov 2017 18:45:39 -0800 (PST) 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.org@gnu.org Sender: "Emacs-orgmode" To: Jack Kamm Cc: emacs-orgmode Mailinglist ob-ipython[1] provides a working alternative: #+BEGIN_SRC jupyter-python :session :results output foo = 0 for _ in range(10): foo += 1 foo += 1 print(foo) #+END_SRC #+RESULTS: : 20 I've long wished that more org people would show ob-ipython some love. Letting jupyter handle things on the backend seems like it should simplifly things considerably. [1] https://github.com/gregsexton/ob-ipython Best, Ista On Tue, Nov 21, 2017 at 3:28 AM, Jack Kamm wrote: > Yes, I'm starting to see now how difficult it is to properly support > ":session :results value". I would vote to remove it from ob-python... > > I think the patch still improves ":session :results output" so I will > simplify it and restrict to that case, leaving ":session :results value" > unchanged for now. > > Sorry for sending this twice Kyle, forgot to reply all. > > On 21 Nov 2017 4:04 am, "Kyle Meyer" wrote: >> >> Jack Kamm writes: >> >> > In response to this: >> > >> >> I can't think of a good solution, though. Stepping back a bit, I think >> >> it's unfortunate that python blocks handle ":results value" differently >> >> depending on whether the block is hooked up to a session or not. For >> >> non-sessions, you have to use return. Using the same approach >> >> (org-babel-python-wrapper-method) for ":session :results value", we >> >> could then get the return value reliably, but the problem with this >> >> approach is that any variables defined in a ":results value" block >> >> wouldn't be defined in the session after executing the block because >> >> the >> >> code is wrapped in a function. >> > >> > How about if we used the "globals()" and "locals()" functions in Python? >> > >> > Something like this at the end of the wrapper block, before return: >> > >> > for k, v in locals().items(): >> > globals()[k] = v >> >> Hmm, placing that code "before return" is a problem. Like with >> non-session ":results value" blocks, the user would be responsible for >> inserting the return (or even multiple return's), so we can't know where >> to insert the above code without parsing the block :/ >> >> > Another bug with the current approach is that it breaks if common idioms >> > like "for _ in range(10)" are used. ("_" is used to inspect the last >> > output >> > of the shell, an obscure feature I hadn't known about until now). >> >> Right. Also, IIRC the built-in interactive python and ipython treat >> multiline blocks differently. With >> >> if True: >> "ipython ignores my existence" >> >> the built-in shell binds "_" to the string's value, but ipython doesn't. >> >> -- >> Kyle