| msg18249 - (view) |
Author: Armin Rigo (arigo) *  |
Date: 2003-09-22 17:05 |
| from the user's point of view, variables originating from nested scopes could erratically become bound in the 'class' statement. The 'class:' statements works by capturing all locals() after executing the body; however, this is not exactly the same as what an explicit call to locals() would return because of the missing PyFrame_FastToLocals() call in the implementation of LOAD_LOCALS in ceval.c. It was thought that PyFrame_FastToLocals() was unnecessary at that point because the class body bytecode only uses LOAD_NAME/STORE_NAME and not fast locals -- but this is no longer true with nested scopes. See attached examples. |
|
|
| msg18250 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2003-09-22 19:16 |
| Logged In: YES user_id=80475 Do you have a proposed patch? |
|
|
| msg18251 - (view) |
Author: Armin Rigo (arigo) * |
Date: 2003-09-24 12:47 |
| Logged In: YES user_id=4771 I'm not sure how to solve this. I could make a patch to LOAD_LOCALS to prevent free variables from showing up in the class.__dict__. For the 2nd problem I'm not familiar enough with compile.c to know how to make the binding 'b="foo"' sufficient to prevent 'b' from also being considered free in the class definition (which is what occurs). Note also that bare 'exec' statements should then be forbidden in class definitions in the presence of free variables, for the same reason as it is forbidden in functions: you cannot tell whether a variable is free or local. As an example of this, if in the attached example we replace b="foo" with exec 'b="foo"' then the last print correctly outputs 'foo' instead of 6 but what actually occurs is that the value of the argument b in f(a,b) was modified by the class definition -- it is a way to change the binding of a variable in an enclosing frame, which should not be possible. |
|
|
| msg18252 - (view) |
Author: Armin Rigo (arigo) * |
Date: 2004-01-08 17:13 |
| Logged In: YES user_id=4771 Attached is a draft. I am not sure that I understand all the implications of nested variables in the presence of class bodies, so please don't check in this patch. |
|
|
| msg18253 - (view) |
Author: Jeremy Hylton (jhylton)  |
Date: 2007-02-25 20:35 |
| I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. |
|
|
| msg18254 - (view) |
Author: Jeremy Hylton (jhylton) |
Date: 2007-02-25 20:36 |
| I'm not sure I understand all the implications of nested variables, either. The current behavior of locals() is to return the names of all free variables that are being passed through the class body so that they can be used by methods. Is the behavior correct? I see that IronPython implements locals() that way, but does not bind them as class variables (good). Should we change the "spec" of locals() and cause IronPython to be incompatible, or should we fix CPython and PyPy to behave the same way? The fix for CPython will be somewhat involved. |
|
|
| msg18255 - (view) |
Author: Jeremy Hylton (jhylton) |
Date: 2007-02-26 18:45 |
| Committed revision 53954. |
|
|
| msg18256 - (view) |
Author: Armin Rigo (arigo) * |
Date: 2007-02-27 07:23 |
| Jeremy, you inserted many spaces instead of tabs in frameobject.c. |
|
|