emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jack Kamm <jackkamm@gmail.com>
To: "Matthew Lundin" <mdl@imapmail.org>,
	"Štěpán Němec" <stepnem@gmail.com>,
Subject: Re: Bug: ob-python mangles multiline :var values [9.3.6 (release_9.3.6-397-ga089600)]
Date: Wed, 27 May 2020 14:46:39 -0700	[thread overview]
Message-ID: <87zh9t9hkw.fsf@gmail.com> (raw)
In-Reply-To: <87h7w18ca1.fsf@fastmail.fm>

Hi Matt --

> A heads up... I believe this changes the scope of the :var variables,
> since they previously were local to the main() function and now they are
> declared globally. After this change, some of my existing python source
> blocks (i.e., ones in which I attempt to assign a new value to a
> variable defined by :var) now generate the following error:
> Traceback (most recent call last):
>   File "<stdin>", line 223, in <module>
>   File "<stdin>", line 214, in main
> UnboundLocalError: local variable 'members' referenced before assignment

Thanks for noticing this and pointing it out. This was an oversight on
my end (I don't really use ":var" or non-session blocks).

Unfortunately, the fix for the original bug will have to be a bit more
complicated to avoid this error. I'll put it on my todo list, but if
anyone wants to have a crack at it, that would be very welcome.

We should also add a unit test for this regression so it doesn't happen

> I hesitate to call this a bug, since it would be fine to think of
> everything within the source block as local and the header :var
> declarations as global.

I think it's fair to call this a bug. I think it would be inconvenient
to be unable to assign to these variables. Also, I did not intend to
break any existing code with this.

> And I suppose it would be worthwhile to ask: Is this change consistent
> with other org-babel modules? Is there a canonical way that org-babel
> handles scope?

IMO everything ought to be in the same scope, and the user shouldn't
have to think about the scope of the main() function that ob-python
wraps the body in. Especially since non-session blocks are evaluated
independently of other blocks, we really shouldn't have to think about
their scope.

I'm not sure if the Org manual provides any guidance here, but from a
quick check I didn't see anything about it.

Ideally I think everything should just be in global scope; however
ob-python needs to use a wrapper function for the "return" keyword.

  reply	other threads:[~2020-05-27 21:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13 13:16 Bug: ob-python mangles multiline :var values [9.3.6 (release_9.3.6-397-ga089600)] Štěpán Němec
2020-05-24 14:51 ` Jack Kamm
2020-05-27 18:26   ` Matthew Lundin
2020-05-27 21:46     ` Jack Kamm [this message]
2020-05-28 14:39       ` Jack Kamm
2020-06-06 18:24         ` Jack Kamm
2020-06-08  4:29           ` Kyle Meyer
2020-06-10  4:05             ` Jack Kamm

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:

  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=87zh9t9hkw.fsf@gmail.com \
    --to=jackkamm@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mdl@imapmail.org \
    --cc=stepnem@gmail.com \


* 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


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).