[Python-3000] Draft PEP for outer scopes

[Ka-Ping Yee]

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