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/)