On Tuesday 21 October 2003 06:53 pm, Guido van Rossum wrote: ...
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
It IS common, at least in the code I write, e.g.: d = dict([ (f(a), g(a)) for a in S ]) s = sets.Set([ a*a for a in S ]) totsq = sum([ x*x for x in S ]) etc. I detest the look of those ([ ... ]), but that's the closest I get to dict comprehensions, set comprehensions, etc.
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
Well, no, but even if that last statement was "del d[key]" you'd still be right:-). Even in a situation where the list comp is only looped over once, code MIGHT still be relying on the LC having "snapshotted" and/or exhausted iterators IT uses. I was basically thinking of passing the LC as argument to something -- the typical cases where I use LC now and WISH they were lazy, as above -- rather about for loops. And even when the LC _is_ an argument there might be cases where its current strict (nonlazy) semantics are necessary. Oh well! Alex