>> 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 -- http://mail.python.org/mailman/listinfo/python-list
