Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)

Christopher Subich spam.csubich+block at block.subich.spam.com
Sat Aug 6 14:08:58 EDT 2005


John Roth wrote:
> 
> "Mike Meyer" <mwm at mired.org> wrote in message 
> news:861x57wrui.fsf at bhuda.mired.org...
>>
>> So the only way to remove the global statement would be to have some
>> way to mark the other interpretation, with say a "local"
>> decleration. I thik that would be much worse than "global". For one
>> thing, most variables would be local whether or not they are
>> declared. Second, having an indication that you need to check module
>> globals in the function is a better than not having that clue there.
> 
> 
> You've got half of the answer. The other half is to have the editor/ide
> translate the lexical cues into color coding and hide the lexical cues.

Yes... let's make color a syntactically important feature of the 
language; Python can follow the massive success of colorForth.

There are three principles that together mandate the use of a 'global' 
keyword:
1) Implicit variable definition:  If all variables had to be declared 
ahead of time, then "var x" versus "global var x" wouldn't be an issue 
at all.  Even though you'd still want to make the latter red and the 
former blue or something.  Removing this from Python would also forbid 
things like locals()['a'] = 1, and it would also have great impact on 
the class syntax (namely instance variables).
2) Lexical scoping: If variable references didn't go beyond the 
immediate scope, then there would be no global variables and thus no 
need for a global keyword.  Lexical scoping, though, is a fundamental 
feature of Python and every other block-scoping procedural language that 
I know of, so no-can-do there.
3) Default local scroping: Changing this, as already pointed out, would 
just require replacing a 'global' keyword with a 'local' one.  In 
procedural languages that derive in spirit from Algol-likes, local 
variables are the far more common case than global ones, and so by 
Huffman/Morse principles should have the shorter syntax.  (As a side 
note, the 'local first' assumption isn't universal; see some FORTRAN and 
BASICs.)

Personally, I don't consider the global keyword a misfeature or even a 
wart; for Py3k I'd rather see more explicit namespacing (which would 
make it clear that namespaces end at the module-level) rather than 
changing even the name of the keyword.



More information about the Python-list mailing list