[Python-Dev] Seeming unintended difference between list comprehensions and generator expressions... (original) (raw)
Josiah Carlson josiah.carlson at gmail.com
Fri Feb 20 23:40:16 CET 2009
- Previous message: [Python-Dev] Choosing a best practice solution for Python/extension modules
- Next message: [Python-Dev] Seeming unintended difference between list comprehensions and generator expressions...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 "", line 1, in File "", line 3, in foo File "", line 3, in 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 "", line 1, in File "", line 3, in foo File "", line 3, in 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 "", line 1, in File "", line 3, in foo File "", line 3, in 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
- Previous message: [Python-Dev] Choosing a best practice solution for Python/extension modules
- Next message: [Python-Dev] Seeming unintended difference between list comprehensions and generator expressions...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]