# PEP 289: Generator Expressions (please comment)

Skip Montanaro skip at pobox.com
Fri Oct 24 15:42:29 CEST 2003

```    >> sum(x*x for x in roots)
>> min(d.temperature()*9/5 + 32 for d in days)
>> Set(word.lower() for word in text.split() if len(word) < 5)
>> dict( (k, somefunc(k)) for k in keylist )
>> dotproduct = sum(x*y for x,y in itertools.izip(xvec, yvec))
>> bestplayer, bestscore = max( (p.score, p.name) for p in players )

Holger> Although most people on python-dev and here seems to like this
Holger> PEP I think it generally decreases readability.  The above
Holger> constructs seem heavy and difficult to parse and thus i am
Holger> afraid that they interfere with the perceived simplicity of
Holger> Python's syntax.

Of course, you can do all of these things today by just turning the args
into list comprehensions:

sum([x*x for x in roots])
min([d.temperature()*9/5 + 32 for d in days])
Set([word.lower() for word in text.split() if len(word) < 5])
dict([(k, somefunc(k)) for k in keylist])
dotproduct = sum([x*y for x,y in itertools.izip(xvec, yvec)])
bestplayer, bestscore = max([(p.score, p.name) for p in players])

[regarding the proposed generator expressions, not my listcomp examples]
>> Each of the above runs without creating a full list in memory, which
>> saves allocation time, conserves resources, and exploits cache
>> locality.

Which can be a sticking point for using list comprehensions.  With generator
expressions in place, list comprehensions become just syntactic sugar for

list(generator expression)

Alex Martelli demonstrated some performance improvements (about 2-to-1 I
think) of generator expressions over the equivalent list comprehensions.

Holger> At least I hope that generator expressions will only be
Holger> introduced via a __future__ statement in Python 2.4 much like it
Holger> happened with 'yield' and generators.  Maybe the PEP should have
Holger> an "implementation plan" chapter mentioning such details?

I think the plan is to make them available in 2.4.  I don't think there's
any plan for a __future__ import because they won't change the semantics of
any existing constructs.

Skip

```