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 <jackk...@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.
