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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com