Home Original page

[Python-Dev] accumulator display syntax

Tim Peters tim_one at email.msn.com
Fri Oct 24 00:46:59 EDT 2003 
[Tim]
>> This is easy to explain, and trivial to explain for people familiar
>> with the default-argument trick.

[Guido]
> Phillip Eby already recommended not bothering with that; the
> default-argument rule is actually confusing for newbies (they think
> the defaults are evaluated at call time) so it's best not to bring
> this into the picture.

Of course it works equally well to pass regular (non-default) arguments, it
just makes a precise explanation a little longer to type (because the
arglist needs to be typed out in two places).

> ..
> OK, I got it now.  I hope we can find another real-life example; but
> there were some other early toy examples that also looked quite
> convincing.

I expect we will find more, although I haven't had more time to think about
it (and today was devoted to puzzling over excessive rates of ZODB conflict
errors, where generator expressions didn't seem immediately applicable
<wink>).

I do think it's related to non-reiterablity.  If generator expressions were
reiterable, then a case could be made for them capturing a parameterized
computation, reusable for different things by varying the bindings of the
free variables.  Like, say, you wanted to plot the squares of various
functions at a set of points, and then:

    squares = (f(x)**2 for x in inputs)  # assuming reiterability here

    for f in math.sin, math.cos, math.tan:
        plot(squares)

But that doesn't make sense for a one-shot (not reiterable) generator, and
even if it were reiterable I can't think of a real example that would want
the bindings of free variables to change *during* a single pass over the
results.  For that matter, if it were reiterable, the "control by obscure
side effect" style of the example is hard to like anyway.
More information about the Python-Dev mailing list