RetroSearch Browse

Tue Oct 21 16:02:01 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039180.html

[Skip]
> I understand all that.  Still, the "best" syntax for these so-called
> iterator comprehensions might have been the current list
> comprehension syntax.  I don't know how hard it would be to fix
> existing code, probably not a massive undertaking, but the bugs lazy
> list comprehensions introduced would probably be a bit subtle.
> 
> Let's perform a little thought experiment.  We already have the
> current list comprehension syntax and the people thinking about lazy
> list comprehensions are seem to be struggling a bit to find syntax
> for them which doesn't appear cobbled together.  Direct your
> attention to Python 3.0 where one of the things Guido has said he
> would like to do is to eliminate some bits of the language he feels
> are warts.  Given two similar language constructs implementing two
> similar sets of semantics, I'd have to think he would like to toss
> one of each.  The list comprehension syntax seems the more obvious
> (to me) syntax to keep while it would appear there are some
> advantages to the lazy list comprehension semantics (enumerate
> (parts of) infinite sequences, better memory usage, some performance
> improvements).
> 
> I don't know when 3.0 alpha will (conceptually) become the CVS
> trunk.  Guido may not know either, but it is getting nearer every
> day.

Not necessarily.  Maybe the time machine's stuck. :-)

> Unless he likes one of the proposed new syntaxes well enough to
> conclude now that he will keep both syntaxes and both sets of
> semantics in 3.0, I think we should look at other alternatives which
> don't introduce new syntax, including morphing list comprehensions
> into lazy list comprehensions or leaving lazy list comprehensions
> out of the language, at least in 2.x.  As I think people learned
> when considering ternary operators and switch statements, adding
> constructs to the language in a Pythonic way is not always possible,
> no matter how compelling the feature might be.  In those situations
> it makes sense to leave the construct out for now and see if syntax
> restructuring in
> 3.0 will make addition of such desired features possible.
> 
> Anyone for
> 
>     [x for x in S]L
> 
> ? <lazy wink>

Thanks for trying to bang some sense into this.

Personally, I still like the idea best to make

    (x for x in S)

be an iterator comprehension

and

    [x for x in S]

syntactic sugar for the common operation

    list((x for x in S))

I'm not 100% sure about requiring the double parentheses, but I
certainly want to require extra parentheses if there's a comma on
either side, so that if we want to pass a 2-argument function a list
comprehension, it will have to be parenthesized, e.g.

    foo((x for x in S), 42)
    bar(42, (x for x in S))

This makes me think that it's probably fine to also require

    sum((x for x in S))

Of course, multiple for clauses and if clauses are still supported
just like in current list comprehensions; they add no new syntactic
issues, except if we also were to introduce conditional
expressions. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039180.html below:

[Python-Dev] accumulator display syntax