[Python-bugs-list] [ 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: 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