Recently I found the need to generate some constants inside a class
body. What I discovered was a bit unintuitive, and may not be
intended...
In 2.5 and 2.6:
>>> class foo:
... x = {}
... x.update((i, x.get(i, None)) for i in xrange(10))
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in foo
File "<stdin>", line 3, in <genexpr>
NameError: global name 'x' is not defined
>>> class foo:
... x = {}
... x.update([(i, x.get(i, None)) for i in xrange(10)])
...
>>>
In 3.0:
>>> class foo():
... x = {}
... x.update((i, x.get(i, None)) for i in range(10))
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in foo
File "<stdin>", line 3, in <genexpr>
NameError: global name 'x' is not defined
>>> class foo():
... x = {}
... x.update([(i, x.get(i, None)) for i in range(10)])
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in foo
File "<stdin>", line 3, in <listcomp>
NameError: global name 'x' is not defined
>>>
The behavior of 3.0 WRT list comprehensions behaving the same way as
generator expressions is expected, but why generator expressions
(generally) don't keep a reference to the class scope during execution
seems to be unintended.
- Josiah
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
