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.

Logged In: YES 
user_id=80475

Do you have a proposed patch?

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.

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.

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.

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.

Committed revision 53954.

Jeremy, you inserted many spaces instead of tabs
in frameobject.c.