From: Jack Kamm <firstname.lastname@example.org>
To: "Matthew Lundin" <email@example.com>,
"Štěpán Němec" <firstname.lastname@example.org>,
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: <email@example.com> (raw)
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
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.
next prev parent 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 Š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
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 \
* 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).