[Guido]
Urgh, we need this sorted out before Raymond can rewrite PEP 289 and present it to c.l.py...
That would be good <wink>. I don't feel a sense of urgency, though, and will be out of town the rest of the week. I sure *expect* that most generator expressions will "get consumed" immediately, at their definition site, so that there's no meaningful question to answer then (as in, e.g., the endless sum(generator_expression) examples, assuming the builtin sum). That means people have to think of plausible use cases where evaluation is delayed. There are some good examples of lists-of-generators in test_generators.py, and I'll just note that they use the default-arg mechanism to force a particular loop-variant non-local value, or use an instance variable, and/or use lexical scoping but know darned well that the up-level binding will never change over the life of each generator. That's all the concrete stuff I have to stare at now (& recalling that the question can't be asked in Icon -- no "divorce" possible there, and no lexical nesting even if it were possible to delay generation).
... So, do you want *all* free variables to be passed using the default-argument trick (even globals and builtins), or only those that correspond to variables in the immediately outer scope, or only those corresponding to function scopes (as opposed to globals)?
All or none make sense to me, as semantic models (not ruling out that a clever implementation may take shortcuts). I'm not having a hard time imagining that "all" will be useful; I haven't yet managed to dream up a plausible use case where "none" actually helps.
n = 0 def f(): global n n += 1 return n print list(n+f() for x in range(10))
Like I just said <wink>. There's no question that semantics can differ between "all" and "none" (and at several points between to boot). Stick a "global f" inside f() and rebind f based on the current value of n too, if you like. I'm having a hard time imagining something *useful* coming out of such tricks combined with "none". Under "all", I look at the print and think "f is f, and n is 0, and that's it". I'm not sure it's "a feature" that print [n+f() for x in range(10)] looks up n and f anew on each iteration -- if I saw a listcomp that actually relied on this, I'd be eager to avoid inheriting any of author's code.