原文在: PEP 3131 -- Supporting Non-ASCII Identifiers.

Python2并不支持非ASCII码标识符. PEP的全称是Python Enhancement Proposal, 即Python增强提案. 这个3131提案创建于2007年5月. Python3于2008年12月发布.

SRE实战 互联网时代守护先锋,助力企业售后服务体系运筹帷幄!一键直达领取阿里云限量特价优惠。

Rationale一节开篇明义, 指出用母语命名标识符对代码清晰度和可维护性的提高.

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.

下面列出了一些质疑和回应. 其中:

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
designers.

简要翻译:

有人表示库如果是其他语言命名, 不懂这一语言的使用者就不会输入API名了. 回应是库开发者有权根据需要进行设计, 这与其他制约因素(版权,文档是外文等等)类似. 开发者如果想要库被最广泛地使用, 自然会考虑到所有这些因素. 而这, 应该是开发者的决定, 而不是语言设计者的.

扫码关注我们
微信号:SRE实战
拒绝背锅 运筹帷幄