[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4