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.
