Bugs item #810714, was opened at 2003-09-22 17:05 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Jeremy Hylton (jhylton) Summary: nested variables in 'class:' statements Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2007-02-27 07:23 Message: Logged In: YES user_id=4771 Originator: YES Jeremy, you inserted many spaces instead of tabs in frameobject.c. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-26 18:45 Message: Logged In: YES user_id=31392 Originator: NO Committed revision 53954. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:36 Message: Logged In: YES user_id=31392 Originator: NO 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. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 20:35 Message: Logged In: YES user_id=31392 Originator: NO 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. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-08 17:13 Message: 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. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-24 12:47 Message: 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. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 19:16 Message: Logged In: YES user_id=80475 Do you have a proposed patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810714&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
