[Guido]
It gives outer scopes (some) control over inner scopes. One of the guidelines is that a name defined in an inner scope should always shadow the same name in an outer scope, to allow evolution of the outer scope without affecting local details of inner scope. (IOW if an inner function defines a local variable 'x', the outer scope shouldn't be able to change that.)
[Alex]
I must be missing something, because I don't understand the value of that guideline. I see outer and inner functions as tightly coupled anyway; it's not as if they could be developed independently -- not even lexically, surely not semantically.
It's the same as the reason why name lookup (whether at compile time or at run-time) always goes from inner scope to outer. While you and I see nested functions as small amounts of closely-knit code, some people will go overboard and write functions of hundred lines long containing dozens of inner functions, which may be categorized into several functional groups. A decision to share a variable 'foo' between one group of inner functions shouldn't mean that none of the other inner functions can have a local variable 'foo'. Anyway, I hope you'll have a look at my reasons for why the compiler needs to know about rebinding variables in outer scopes from inside an inner scope. --Guido van Rossum (home page: http://www.python.org/~guido/)