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