[Python-Dev] accumulator display syntax

[Alex Martelli]

On Thursday 23 October 2003 04:12 am, Phillip J. Eby wrote:
> At 02:49 PM 10/23/03 +1300, Greg Ewing wrote:
> >This would allow the current delayed-evaluation semantics
> >to be kept as the default, while eliminating any need
> >for using the default-argument hack when you don't
> >want delayed evaluation.
>
> Does anybody actually have a use case for delayed evaluation?  Why would
> you ever *want* it to be that way?  (Apart from the BDFL's desire to have
> the behavior resemble function behavior.)

I have looked far and wide over my code, present and desired, and can
only find one example that seems perhaps tangentially relevant -- and I
don't think it's a _good_ example.  Anyway, here it comes:

def smooth(N, sequence):

    def fifo(N):
        window = []
        while 1:
            if len(window) < N:
                yield None
            else:
                yield window
                window.pop(0)
            window.append(item)
    latest = iter(fifo(N)).next

    for item in sequence:
        window = latest()
        if window is None: continue
        yield sum(window) / N

as I said, I don't like it one bit; the non-transparent "argument passing" of
item from the loop "down into" the generator is truly yecchy.  There are
MUCH better ways to do this, such as

def fifo(N, sequence):
    it = iter(sequence)
    window = list(itertools.islice(it, N))
    while 1:
        yield window
        window.pop(0)
        window.append(it.next())

def smooth(N, sequence):
    for window in fifo(N, sequence):
        yield sum(window) / N

It's not clear that this would generalize to generator expressions, anyway.
But I could imagine it might, e.g. IF we had "closure semantics" rather than
"snapshot-binding" somebody COULD be tempted to such murky cases
of "surreptitious argumentpassing down into genexprs"... and we're better
off without any such possibility, IMHO.
    

> And, if there's no use case for delayed evaluation, why make people jump
> through hoops to get the immediate binding?

I understand Guido's position that simplicity and regularity of the rules
count (a LOT).  But in this case I think Tim's insistence on practicality
should count for more: the "bind everything at start time" semantics
are NOT a weird special case, and the "lookup everything each time
around the loop" ones don't seem to yield any non-weird use...


Alex