-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document scoping of assignment of locals in continuations #82
Comments
Maybe not worth it, after all; much simpler, and more robust, to just document that introducing a continuation introduces a scope boundary.
Turns out this is not as straightforward as initially envisioned. 2c7477c implements propagation of the scope of variable definitions from the parent scope into the continuation, recursively. But:
So it may be better to abandon the experiment, and just document that introducing a continuation introduces a scope boundary. This is how it has always worked up to 0.15.1, though the fact was never documented. The behavior is no worse than how, in standard Python, comprehensions and generator expressions introduce a scope boundary. The code of the experiment itself is sufficiently nontrivial to be worth keeping as a commented-out section, with a "don't do this, it's a bad idea" (for the above reasons) warning. |
Thought about it a while; yes, let's abandon the experiment. Thus, we need to update the documentation, particularly the section on continuations in There are updated examples in |
Currently, if you assign to a local variable in a continuation, this always creates a new name local to the continuation.
If the parent function whose continuation it is has a local variable with the same name, the standard Python semantics is to update (overwrite) that name - because looking at the unexpanded user source code, we are still inside the same function.
In actuality, we of course are not. The continuation is a closure defined inside the parent function, thus causing this bug.
This is particularly insidious because in the user code, there is no hint of another scope being introduced. For least surprise, we should maintain the illusion that the standard scoping rules apply to the unexpanded source code.
To fix this, we should be able to just
nonlocal
any local variables of the parent function when we generate the code for the continuation closure.For where and how to do this, see the comment in the function
split_at_callcc
, inunpythonic/syntax/tailtools.py
.The text was updated successfully, but these errors were encountered: