[Python-Dev] Allowing non-ASCII identifiers

François Pinard pinard at iro.umontreal.ca
Mon Feb 9 11:27:04 EST 2004


[Guido van Rossum]

> Since [non-ASCII identifiers] could create a serious burden for code
> portability, I'd like to see a serious section on motivation and
> discussion on how to keep Unicode out of the standard library and out
> of most 3rd party distributions.  Without that I'm strongly -1.

There are two matters here.  One is the technical portability, the other
is more related to human issues.

The technical portability burden is fairly limited to the `coding:'
magic, and not very different from it.  As long as the coding is known
to Python, various modules in a single application could use each their
coding and consequently, each their lexical behaviour for identifiers.
It should not be much of a problem in practice.  For the standard
library, say, it is a matter of ruling out `coding:' within developers.

The human issues are another thing, and I would guess -- without being
fully sure -- that this is where your reluctance stands.  There is a
fear that people would not only comment in German (I'm using German
as an example, of course), or use German strings, but also choose
identifiers based on German words instead of English words, making
programs less easy to read by English people, or relieving a bit of this
constant pressure all programmers on this planet have to learn English,
pressure which is probably deemed useful towards this uniformity.

Almost all "foreigners" already know that if they aim the international
community while programming, English is likely the best way to
communicate, and they consequently comment in English, and choose their
identifiers for being meaningful to English readers.  But, the same as
not all software is meant to be free (whatever that word means), not all
software is meant for international distribution.

Some English readers might not really imagine, but it is a constant
misery, having to mangle identifiers while documenting and thinking
in languages other than English, merely because the Python notion of
letter is limited to the English subset.  Granted, keywords and standard
library use English, this is Python, and this is not at stake here!
However, there is a good part of code in local (or in-house) programs
which is thought as our crafted code, and even the linguistic change is
useful (to us) for segregating between what comes from the language and
what comes from us.  The idea is extremely appealing of being able to
craft and polish our code (comments, strings, identifiers) to make it as
nice as it could get, while thinking in our native, natural language.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard



More information about the Python-Dev mailing list