[Python-3000] Draft PEP for outer scopes
ntoronto at cs.byu.edu
Mon Nov 6 19:16:15 CET 2006
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
>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
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
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."
More information about the Python-3000