>> Here's an alternate suggestion. Instead of inventing new syntax, why >> not change the semantics of list comprehensions to be lazy?
Alex> Well, yes, the _most_ one could ever have to change is move from [ Alex> ... ] to list[ ... ]) to get back today's semantics. But any use Alex> NOT so changed may break, in general; any perfectly correct Alex> program coded with Python 2.1 to Python 2.3 -- several years' Alex> worth of "current Python", by the time 2.4 comes out -- might Alex> break.
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. 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.
[x for x in S]L
? <lazy wink>