[Python-3000] Draft PEP for outer scopes

[Neil Toronto]

Josiah Carlson wrote:

>"Michael Urman" <murman at gmail.com> wrote:
>  
>
>>I personally expect that while there is a theoretical clash between
>>variable names in nested scopes, that's already a poor coding
>>decision. The module level globals should not unintentionally collide
>>with function-local non-local access. Thus reusing the global keyword
>>is not a practical limitation.
>>    
>>
>
>Just saying that they shouldn't be colliding doesn't mean that they
>won't.  I've seen horrendous code from some otherwise smart people where
>locals shadow globals, even in closures.  I don't have a link for you
>because I've tried to block out the experience.  However, in my opinion,
>relying on good coding practices (never shadow variables) to guarantee
>correctness of the use of the global keyword in Python seems to me to be
>silly.
>
>I hope we can all at least agree that *requiring* good coding practices
>to make a feature work may be a bit more anal retentive than we want
>Python to be.  While I personally don't want the feature in the first
>place, if I'm going to be seeing it in code, I would very much rather
>that a second keyword were introduced.  If only because then I wouldn't
>tear out my hair trying to figure out whether a variable was really in
>the module globals, or in just another containing scope.
>  
>

And that's the most important implication of this decision: the health 
of Josiah's hair.

Um, yeah - I agree, actually. This is my biggest beef with reusing 
"global" as well: code using it doesn't say what most people would think 
it says. (My second beef is that there would be no chance of seeing it 
in 2.x.)

There's *always* going to be some mismatch between what the programmer 
believes the code says and what it actually does say. That doesn't mean 
we need to exacerbate the problem. The weirdest thing I've seen in this 
discussion is arguments along the lines of, "Well, it's ambiguous in the 
first place, so why not make it worse?" I honestly can't fathom that 
kind of reasoning, especially given that Python is supposed to be a 
language that's partly designed to be a good user interface.

(Michael, I know you were talking about whether there was any technical 
reason it couldn't be done. My comment is aimed laterally along the 
discussion tree.)

It'd be like saying, "You know, a checkbox is technically a toggle 
button, so why not call this color wheel a button, too? I mean, it has a 
discrete state, and you click on it. It's not that different."

Neil