RetroSearch Browse

Fri Feb 20 23:40:16 CET 2009 · http://mail.python.org/pipermail/python-dev/2009-February/086287.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2009-February/086287.html below:

[Python-Dev] Seeming unintended difference between list comprehensions and generator expressions...