[Skip]
Here's an alternate suggestion. Instead of inventing new syntax, why not change the semantics of list comprehensions to be lazy? They haven't been in use that long, and while they are popular, the semantic tweakage would probably cause minimal disruption. In situations where laziness wasn't wanted, the most that a particular use would have to change (I think) is to pass it to list().
Sorry, too late. You're hugely underestimating the backwards compatibility issues. And they have been in use at least since 2000 (they were introduced in 2.0). [Alex]
I think we should keep the user-observable semantics as now, BUT maybe an optimization IS possible if all the user code does with the LC is loop on it (or anyway just get its iter(...) and nothing else).
But that's not very common, so I don't see the point of putting in the effort, plus it's not safe. Using a LC as the sequence of a for loop is ugly, and usually for x in [y for y in S if P(y)]: ... means the same as for x in S: if P(x): ... except when it doesn't, and then making the list comprehension lazy can be a mistake: the following example for key in [k for k in d if d[k] is None]: del d[key] is *not* the same as for key in d: if d[key] is None: del d --Guido van Rossum (home page: http://www.python.org/~guido/)