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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4