On Mon, 6 Nov 2006, Andrew McNamara wrote: > >Python, C/C++, JavaScript, Ruby, and Perl all have this in common: > > > > A "global variable" is visible to the entire file and does > > not belong to any particular function. > > I note that you didn't say "a global variable is visible to the entire > application" - you've deliberately narrowed the definition to suit > your argument.
Let's be clear that we're discussing the same topic here. If we're trying to assess whether a particular meaning of "global" in Python will be familiar, surprising, easy to understand, etc. then we have to compare it to what "global" means in other contexts. That requires talking about what is in common among the other contexts. Are you trying to assert that most of the other languages have a common meaning for "global", from which Python has already diverged enough that it doesn't matter for Python to diverge further? But i think we agree it is not always true in programming languages that "global" means "visible to the entire application" -- you provided some good examples, in fact. So this cannot be part of the common meaning. Or are you trying to show that other languages have meanings for "global" that are all so different that there *is* no common meaning for Python to follow? That's the reason i offered, above, a statement of something that is clearly common among them. This is not intended to be the complete definition of "global" in all these contexts, as each language has its own way of integrating multiple modules. But because at least this much is common, this is part of the common meaning that people have come to expect. This is a meaning that Python conforms to now, and that Python would no longer fit if we redefined "global" to mean "belonging to any parent scope of the current scope". > Introducing new keywords is rude. Changing the behaviour of existing > language constructs is rude. To implement this proposal, we need to do one > or the other. Of the two, I lean very slightly in favour of making the > semantics of "global" slightly more complex, on the basis that they're > already slightly more complex than most other languages and people cope > with that. I am trying to warn the participants in this discussion that the cost of redefining "global" in this manner is rather higher than may seem initially apparent. The effect will be to confuse the meaning of "global" not just as a language keyword but as a programming concept: "global namespace" will not just have a different meaning -- it will come to have no meaning at all (or, alternatively, the language itself will be at odds with its own semantics), as i've explained [1]. This would be quite a bit more painful than introducing a keyword in a new version of Python that has been specifically designated as potentially backward incompatible, with time still remaining between now and then for gradual migration. -- ?!ng [1] http://mail.python.org/pipermail/python-3000/2006-November/004215.html _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
