[Python-Dev] LOAD_NAME & classes

[Jeremy Hylton]

There's a bug report on SF that notes there is a difference between:

def f(x):
    class Foo:
        x = x

and 

x = 1
class Foo:
    x = x

The latter works because the class namespace uses LOAD_NAME and finds
a global binding for x.  The fact that x is also a local is invisible
to LOAD_NAME.

The former fails because x is none of locals, globals, or builtins,
although it is bound in an enclosing scope.  LOAD_NAME knows nothing
about free variables, however, so it just blows up.

Do we want to do anything about this apparent inconsistency?

LOAD_NAME is obviously necessary to make stuff like exec work at all,
and after a recent bug fix, it evens works as documented for nested
scopes.  But the docs for a class namespace (there aren't any, right?)
don't suggest there is anything special going on.

I imagine it would be possible to stop using LOAD_NAME for classes,
but I'm not sure if that's a good thing.  It could presumably break
code that relies on LOAD_NAME's old fashioned search.  It also seems
like a non trivial amount of work because we'd need a new LOAD/STORE
combo that only searched a locals dict.  (Maybe that's not so hard.)

I think module namespaces also use LOAD_NAME, but it's not clear why.
Isn't a module's locals the same as its globals?  If so, LOAD_GLOBAL
could be used for all names.

Any opinion on whether this is worth fixing?  And is it a bug fix or a
new feature?

Jeremy