[Python-Dev] accumulator display syntax
Guido van Rossum
guido at python.org
Wed Oct 22 13:30:09 EDT 2003
> >> def f(x):
> >> r = [x+1 for x in range(x)]
> >> return r, x
> >>
> >> becomes even more incomprehensible (and changes in behaviour).
> >
> > Anyone who writes code like that *deserves* to have the
> > behaviour changed on them!
>
> This was not my impression of the Python way. I know I'd be pretty
> pissed if this broke my app.
>
> I have no objection to breaking the above code, just to breaking it
> silently! Having code *silently change in behaviour* (not die with an
> expection, post a warning at compile time or fail to compile at all)
> is about an evil a change as it's possible to contemplate, IMO.
>
> > If this is really a worry, an alternative would be to
> > simply forbid using a name for the loop variable that's
> > used for anything else outside the loop. That could
> > break existing code too, but at least it would break
> > it in a very obvious way by making it fail to compile.
>
> This would be infinitely preferable!
Not so fast. We introduced nested scopes, which could similarly
subtly change the meaning of code without giving an error. Instead,
we had at least one release that *warned* about situations that would
change meaning silently under the new semantics. The same release
also implemented the new semantics if you used a __future__ import.
We should do that here too (both the warning and the __future__).
I don't want this kind of code to cause an error; it's not Pythonic to
flag an error when a variable name in an inner scope shields a
variable of the same name in an outer scope.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list