[ python-Bugs-810714 ] nested variables in 'class:' statements

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
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: 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