GeezerVison

> 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.

Can we cut this out please?  Paul is misguided.  There's no reason to
forbid a local shadowing a global.  All languages with nested scopes
allow this.

--Guido van Rossum (home page: http://www.python.org/~guido/)