[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4