PEP 3131: Supporting Non-ASCII Identifiers

Ross Ridge rridge at caffeine.csclub.uwaterloo.ca
Tue May 15 12:02:42 EDT 2007


<martin at v.loewis.de> wrote:
>So, please provide feedback, e.g. perhaps by answering these
>questions:
>- should non-ASCII identifiers be supported? why?
 
Ross Ridge wrote:
> I think the biggest argument against this PEP is how little similar
> features are used in other languages

Carsten Haese  <carsten at uniqsys.com> wrote:
>That observation is biased by your limited sample.

No.  I've actually looked hard to find examples of source code that use
non-ASCII identifiers.  While it's easy to find code where comments use
non-ASCII characters, I was never able to find a non-made up example
that used them in identifiers.

> You only see open source code that chooses to restrict itself to ASCII
>and mostly English identifiers to allow for easier code sharing. There
>could be millions of kids in China learning C# in native Mandarin and
>you'd never know about it.

No, there's tons of code written by kids learning programming languages
from all over the world scattered all over the Internet.

Regardless of what my observations are, I think that you need a better
argument than a bunch of children in China that may very well not exist.
This PEP, like similar features in other langauges is being made and
advocated by people who don't actually want to use it.  It's made on
the presumption that somehow developers in China and other places its
proponents aren't familar with desperately want this feature but are
somehow incapable of advocating for it themselves let alone implementing
it.

The burden of proof should be on this PEP's proponents to show that it
will be actually be used.  Is this PEP even justified by anyone going
to the trouble of asking for it to be implemented in the first place?

>How would a choice of identifiers interact in any way with Python's
>standard or third-party libraries?  The only things that get passed
>between an application and the libraries are objects that neither know
>nor care what identifiers, if any, are attached to them.

A number of libraries and utilities, including those included with the
standard Python distribution work with Python identifiers.  The PEP gives
one example, but it doesn't really give much though as to how much of
the standard library might be affected.

If the proponents of this PEP think it will actually be used, then the
implementation section of this PEP should be updated to include making all
aspects of the standard Python distribution, the interpreter, libraries
and utilities fully support non-ASCII identifiers.  These hypothetical
Chinese students are going to happy if IDLE doesn't highlight identifiers
correctly, or the carret in a syntax error doesn't point to the right
place.

Hmm... normalizing identifiers could cause problems with module names.
If Python searches the filesystem for the module using the normalized
version of the name different from the one that appears in the source
code it could end up surprising users.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge at csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  



More information about the Python-list mailing list