[Python-3000] Support for PEP 3131
"Martin v. Löwis"
martin at v.loewis.de
Thu May 24 07:38:48 CEST 2007
> You've got this backwards, and I suspect that's part of the root of
> the disagreement. It's not that "when humans enter the loop they
> cause problems." The purpose of the language is to *serve humans*.
> Without humans, we would just use machine code instead of Python.
> If it doesn't work for humans, it's not because the humans are broken,
> the language is broken.
> The grammar has to be something a human can understand.
Indeed, it is easy for a human to still understand the Py3k grammar.
An identifier starts with a letter, followed by letters and digits.
It's really the same rule that was in use all the time.
It's not easy for a single human to memorize the entire *language*,
and never was. The language is not just about the syntax: it's
also about the library. While there are many details of the library
that you can memorize, I bet nobody could enumerate all classes,
functions, methods, symbolic constants etc in the entire library;
this causes no concern for people.
> If we are going to allow Unicode identifiers at all, then I would
> recommend only allowing identifiers that are already normalized
> (in NFC).
In what way would that be an improvement compared to what the PEP
> 2. "python" allows only ASCII identifiers. "python -U" allows
> Unicode identifiers that are in NFC and use a conservative,
> *fixed* subset of the available characters. Support for
> "-U" is a compile-time option, preferably not compiled into
> official binary releases of Python.
> 3. "python" and "python -U" are as above. "python -UU" allows
> all Unicode identifier characters (which may grow over time
> as the Unicode standard changes). Support for "-UU" is a
> compile-time option, never on in official binary releases of
> Python, and discouraged with "here be dragons" warnings, etc.
This would cripple the feature, so I'm -1.
More information about the Python-3000