[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/)