[Python-Dev] accumulator display syntax

[Guido van Rossum]

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

It's just a direct consequence of Python's general rule for name
lookup in all contexts: variables are looked up when used, not before.
(Note: lookup is different from scope determination, which is done
mostly at compile time.  Scope determination tells you where to look;
lookup gives you the actual value of that location.)  If n is a global
and calling f() changes n, f()+n differs from n+f(), and both are
well-defined due to the left-to-right rule.  That's not good or bad,
that's just *how it is*.  Despite having some downsides, the
simplicity of the rule is good; I'm sure we could come up with
downsides of other rules too.

Despite the good case that's been made for what would be most useful,
I'm loathe to drop the evaluation rule for convenience in one special
case.  Next people may argue that in Python 3.0 lambda should also do
this; arguably it's more useful than the current semantics there too.
And then what next -- maybe all nested functions should copy their
free variables?  Oh, and then maybe outermost functions should copy
their globals into locals too -- that will speed up a lot of code. :-)

There are other places in Python where some rule is applied to "all
free variables of a given piece of code" (the distinction between
locals and non-locals in functions is made this way).  But there are
no other places where implicit local *copies* of all those free
variables are taken.

I'd need to find a unifying principle to warrant doing that beyond
utility.

--Guido van Rossum (home page: http://www.python.org/~guido/)