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: Thu, 28 May 2020 07:39:29 -0700	[thread overview]
Message-ID: <87tv009l9a.fsf@gmail.com> (raw)
In-Reply-To: <87zh9t9hkw.fsf@gmail.com>

An update on this -- I decided to revert my fix for multiline Python
variables. I left the unit test I added for this, but marked it as
expected to fail.

I'll try to submit a proper fix for this soon. However I've been swamped
at work so I can't promise when (hopefully a couple weeks). In the
meantime, I think it better to leave the original bug in place, rather
than break any existing ob-python use cases.

When I do get to this, I'll submit it as a patch to the list first, to
make sure I don't accidentally cause a new bug.


Jack Kamm <jackkamm@gmail.com> writes:

> 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
> again.
>> 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-28 14:40 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
2020-05-28 14:39       ` Jack Kamm [this message]
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=87tv009l9a.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).