Why Python 3 chooses to support non ASCII identifiers

The original text is: PEP 3131 -- Supporting Non-ASCII Identifiers.

Python 2 does not support non ASCII identifiers. The full name of PEP is Python Enhancement Proposal, or Python Enhancement Proposal. The 3131 proposal was created in May 2007. Python 3 was released in December 2008

The rational e section begins with a clear idea of how naming identifiers in native language improves code clarity and maintainability

Python code is written by many people in the world who are not
familiar with the English language, or even well-acquainted with the
Latin writing system. Such developers often desire to define classes
and functions with names in their native languages, rather than having
to come up with an (often incorrect) English translation of the
concept they want to name. By using identifiers in their native
language, code clarity and maintainability of the code among
speakers of that language improves.

Some queries and responses are listed below

People claim that they will not be able to use a library if to do so they have
to use characters they cannot type on their keyboards. However, it is the
choice of the designer of the library to decide on various constraints for using
the library: people may not be able to use the library because they cannot get
physical access to the source code (because it is not published), or because
licensing prohibits usage, or because the documentation is in a language they
cannot understand. A developer wishing to make a library widely available needs
to make a number of explicit choices (such as publication, licensing, language
of documentation, and language of identifiers). It should always be the choice
of the author to make these decisions - not the choice of the language

Brief translation:

Some people say that if the library is named in another language, users who do not understand the language will not enter the API name. The response is that the library developers have the right to design according to their needs, which is similar to other constraints (copyright, document is foreign language, etc.). If the developers want the library to be widely used, they will naturally take all these factors into account. This should be the decision of the developers, not the language Say designer's

Tags: Python ascii

Posted on Tue, 03 Dec 2019 18:06:44 -0500 by Darkwoods