John Roth wrote: > > "Mike Meyer" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> >> 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. -- http://mail.python.org/mailman/listinfo/python-list
