Python核心库和PEP8

Question

我试图理解为什么Python被认为是一种美丽的语言.我被引导到PEP 8的美丽......这很奇怪.实际上它说你可以使用你想要的任何约定,只是保持一致......然后突然我在核心库中发现了一些奇怪的东西:

request()
getresponse()
set_debuglevel()
endheaders()
http://docs.python.org/py3k/library/http.client.html

以下函数是Python 3.1中的新功能.这里使用PEP 8约定的哪一部分？

popitem()
move_to_end()
http://docs.python.org/py3k/library/collections.html

所以我的问题是:PEP 8是否在核心库中使用？为什么会那样？
是否存在与PHP相同的情况,我不能只记住函数的名称,因为有可能编写名称的所有方法？

为什么即使是新功能,PEP 8也不会在核心库中使用？

Answer 1

PEP 8建议使用下划线作为默认选择,但通常将其排除在外有两个原因:

为了解决您引用的具体示例:

popitem对dict物体来说是一种长期的方法.采用它的其他API保留拼写(即没有下划线).
move_to_end是全新的.尽管该对象省略了下划线的其他方法,但它遵循推荐的使用下划线的PEP 8惯例,因为movetoend难以阅读(主要是因为toe是一个单词,所以大多数人的大脑一旦注意到它们就必须备份和重新分析nd)
set_debuglevel(和更新的set_tunnel)应该留下下划线以与HTTPConnectionAPI 的其余部分保持一致.然而,原始作者可以简单地具有优选set_debuglevel至setdebuglevel(注意debuglevel也是参数传递给HTTPConnection构造函数,说明缺乏第二个下划线的),然后的作者set_tunnel简单地遵循的例子.
set_tunnel实际上是另一种情况下,下划线可能会伤害可读性.两个"t"的并置settunnel不利于易于解析.

一旦这些不一致使它成为一个Python发布模块,通常不值得麻烦尝试和纠正它们(这是为了解密threadingPython 2和Python 3之间的模块接口,这个过程很烦人,没有人否则自愿"修复"任何其他受类似风格问题折磨的API.

Answer 2

来自 PEP8：

但最重要的是：知道何时要不一致——有时风格指南并不适用。如有疑问，请运用您的最佳判断。查看其他示例并决定哪个看起来最好。请随时询问！

您在这里提到的内容与 PEP8 指南有些一致；实际上，主要的不一致是在其他部分，通常是 CamelCase。