list comprehensions put non-names into namespaces!

[Lonnie Princehouse]

List comprehensions appear to store their temporary result in a
variable named "_[1]" (or presumably "_[2]", "_[3]" etc for nested
comprehensions)

In other words, there are variables being put into the namespace with
illegal names (names can't contain brackets). Can't someone come up
with a better hack than this? How about using "_1", "_2", etc, or
actually making "_" a list of lists and using the real first, second,
third elements? This is an unexpected wrench in the works for people
trying to implement custom global namespaces.

Illustration:

class custom_namespace(dict):
def __getitem__(self, i):
print "GET", i
return dict.__getitem__(self, i)

eval("[x for x in range(10)]", custom_namespace())

 

[skip]

Lonnie> List comprehensions appear to store their temporary result in a
Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
Lonnie> nested comprehensions)

Known issue. Fixed in generator comprehensions. Dunno about plans to fix
it in list comprehensions. I believe at some point in the future they may
just go away or become syntactic sugar for a gen comp wrapped in a list()
call.

Skip

 

[Ben Cartwright]

Lonnie> List comprehensions appear to store their temporary result in a
Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
Lonnie> nested comprehensions)

Known issue. Fixed in generator comprehensions. Dunno about plans to fix
it in list comprehensions. I believe at some point in the future they may
just go away or become syntactic sugar for a gen comp wrapped in a list()
call.

The latter, starting in Python 3.0. It won't be fixed before Python
3.0 because it has the potential to break existing 2.x code. From PEP
289:

"""List comprehensions also "leak" their loop variable into the
surrounding scope. This will also change in Python 3.0, so that the
semantic definition of a list comprehension in Python 3.0 will be
equivalent to list(<generator expression>). Python 2.4 and beyond
should issue a deprecation warning if a list comprehension's loop
variable has the same name as a variable used in the immediately
surrounding scope."""

Source: http://www.python.org/dev/peps/pep-0289/

Also mentioned in PEP 3100.

Doesn't look like the deprecation warning was ever implemented for 2.4,
though. On my 2.4.3:
[x for x in range(10)]
print x
2.5 is in alpha now, hopefully the warning will be added.

--Ben

 

[Diez B. Roggisch]

Lonnie> List comprehensions appear to store their temporary result in a
Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
Lonnie> nested comprehensions)

Known issue. Fixed in generator comprehensions. Dunno about plans to fix
it in list comprehensions. I believe at some point in the future they may
just go away or become syntactic sugar for a gen comp wrapped in a list()
call.

The latter, starting in Python 3.0. It won't be fixed before Python
3.0 because it has the potential to break existing 2.x code. From PEP
289:

That is a different beast. Lonnie is after the temporary list variables
created, with otherwise illegal names in python.

Diez

 

[Mel Wilson]

Lonnie> List comprehensions appear to store their temporary result in a
Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
Lonnie> nested comprehensions)

Known issue. Fixed in generator comprehensions. Dunno about plans to fix
it in list comprehensions. I believe at some point in the future they may
just go away or become syntactic sugar for a gen comp wrapped in a list()
call.

Point of information, would this be the interpreter putting
the result of its last calculation in _ ?

Python 2.4.2 (#1, Jan 23 2006, 21:24:54)
[GCC 3.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more
information.

>>> [2*x for x in range(5)] [0, 2, 4, 6, 8]
>>> _[4]

8



Mel.

 

[Terry Reedy]

Point of information, would this be the interpreter putting
the result of its last calculation in _ ?

Yes, in interactive mode (but not in batch mode) it binds the valid name
'_' to the result of statement expressions.

[2*x for x in range(5)] [0, 2, 4, 6, 8]
_[4]

8

which here is the list.

Terry Jan Reedy

 

[Just]

Point of information, would this be the interpreter putting
the result of its last calculation in _ ?

Yes, [ ... ]

No, actually. It's an implementation detail of list comps.