From: Jack Kamm <email@example.com> To: "Matthew Lundin" <firstname.lastname@example.org>, "Štěpán Němec" <email@example.com>, firstname.lastname@example.org 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: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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. Best, Jack Jack Kamm <email@example.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.
next prev parent 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 Š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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Bug: ob-python mangles multiline :var values [9.3.6 (release_9.3.6-397-ga089600)]' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).