PEP 289: Generator Expressions (please comment)

[Skip Montanaro]

    >> 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