Greg Ewing wrote: > > Paul Prescod <paulp@ActiveState.com>: > > > We could say that a local can only shadow a global > > if the local is formally declared. > > How do you intend to enforce that? Seems like it would > require a test on every assignment to a local, to make > sure nobody has snuck in a new global since the function > was compiled. I would expect that all of the checks would be at compile-time. Except for __dict__ hackery, I think it is doable. Python already keeps track of all assignments to locals and all assignments to globals in a function scope. The only addition is keeping track of assignments at a global scope. > > Actually, one could argue that there is no good reason to > > even *allow* the shadowing of globals. > > If shadowing were completely disallowed, it would make it > impossible to write a completely self-contained function > whose source could be moved from one environment to another > without danger of it breaking. I wouldn't like the language > to have a characteristic like that. That seems like a very esoteric requirement. How often do you have functions that do not rely *at all* on their environment (other functions, import statements, global variables). When you move code you have to do some rewriting or customizing of the environment in 94% of the cases. How much effort do you want to spend on the other 6%? Also, there are tools that are designed to help you move code without breaking programs (refactoring editors). They can just as easily handle renaming local variables as adding import statements and fixing up function calls. Paul Prescod
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