[Python-Dev] accumulator display syntax

[Guido van Rossum]

> 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.

OK, but you hve very little hope of optimizing the incarnation away by
the compiler (especially since our attempts at warning about
surreptitious changes to builtins had to be withdrawn before 2.3 went
out).

> > 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!

Yes, this is why iterator comprehensions (we need a better term!!!)
would be so cool to have (I think much cooler than conditional
expressions).

--Guido van Rossum (home page: http://www.python.org/~guido/)