[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