PEP 3131: Supporting Non-ASCII Identifiers

["Martin v. Löwis"]

>> So, please provide feedback, e.g. perhaps by answering these
>> questions:
>> - should non-ASCII identifiers be supported? why?
> 
> I think the biggest argument against this PEP is how little similar
> features are used in other languages and how poorly they are supported
> by third party utilities.  Your PEP gives very little thought to how
> the change would affect the standard Python library.  Are non-ASCII
> identifiers going to be poorly supported in Python's own library and
> utilities?

For other languages (in particular Java), one challenge is that
you don't know the source encoding - it's neither fixed, nor is
it given in the source code file itself.

Instead, the environment has to provide the source encoding, and that
makes it difficult to use. The JDK javac uses the encoding from the
locale, which is non-sensical if you check-out source from a
repository. Eclipse has solved the problem: you can specify source
encoding on a per-project basis, and it uses that encoding
consistently in the editor and when running the compiler.

For Python, this problem was solved long ago: PEP 263 allows to
specify the source encoding within the file, and there was
always a default encoding. The default encoding will change to
UTF-8 in Python 3.

IDLE has been supporting PEP 263 from the beginning, and several
other editors support it as well. Not sure what other tools
you have in mind, and what problems you expect.

Regards,
Martin