[Python-Dev] accumulator display syntax
Guido van Rossum
guido at python.org
Tue Oct 21 16:02:01 EDT 2003
[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/)
More information about the Python-Dev
mailing list