[Python-Dev] accumulator display syntax

[Tim Peters]

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