[Guido]
Hm. I don't think I've seen a single example that wasn't specifically concocted by early-binding advocates (yours included -- you took random listcomps and mused on what would happen if they'd be genexprs instead).
That's a bit of a revisionist stretch: the examples I trotted out last October *made* me an early-binding advocate at the time. For example, http://mail.python.org/pipermail/python-dev/2003-October/039323.html That example doesn't have lists of generators either, which is another thing you don't remember ever seeing <wink>. It's still the case that I haven't seen a plausible example where late-binding semantics both make a difference and are desirable, or where early-binding semantics both make a difference and are undesirable -- although the magical implicitness of both schemes leaves me queasy. ...
My problem with early binding is that it intruduces a new set of behind-the-scenes semantics that you cannot always ignore -- while the examples where it doesn't DWYM are even more obscure than the examples that it is intended to save, it means that you still have to think about the new semantics when doing advanced stuff -- and these new semantics are unlike anything seen before in Python: transformations that require a definition of "free variables" are not seen anywhere else (nested scopes use a different concept).
Late-binding in genexps can't be ignored either when doing advanced stuff, and are also unlike anything seen before in Python: transforming what looks like an expression into a delayed function body is also unprecendented (in the absence of a lambda). The fact that it "looks like" an expression is exactly what's so surprising about that "the current values" of p and pipe don't get used in the above example's # add a filter over the current pipe, and call that the new pipe pipe = (e for e in pipe if p(e)) It didn't strike me as an advanced use at the time, just as an example of something that seemed like it should be natural. It sounds like, today, "the current value" of pipe will be used after all, but the evaluation of p will get delayed? If so, that's not notably easy to explain either (or so it seems to me).