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？

- Szymon Lipiński

---

检查核心库中的unittest模块...全部使用驼峰式命名！ - wim

Answer 1

PEP 8建议使用下划线作为默认选择，但通常会因以下两个原因之一而省略它们：

- 与某些其他API（例如当前模块或标准接口）保持一致性。 - 因为省略它们不会损害可读性（甚至可以提高可读性）。

针对您提到的具体示例：

- popitem是dict对象上的一个长期存在的方法。采用它的其他API保留该拼写（即没有下划线）。 - move_to_end是全新的。尽管对象上的其他方法省略了下划线，但它遵循推荐的PEP 8惯例使用下划线，因为movetoend难以阅读（主要是因为toe是一个词，所以大多数人的大脑在注意到nd后将不得不回退和重新解析）。 - set_debuglevel（以及更新的set_tunnel）可能应该省略下划线，以保持与HTTPConnection API的其余部分一致。然而，最初的作者可能只是更喜欢set_debuglevel而不是setdebuglevel（请注意，debuglevel也是HTTPConnection构造函数的参数，这解释了为什么没有第二个下划线），然后set_tunnel的作者只是遵循了这个例子。 - set_tunnel实际上是另一个省略下划线可能会影响可读性的情况。settunnel中两个“t”的并置不利于易于解析。

一旦这些不一致性进入Python发布模块，通常没有必要费力去纠正它们（这是在Python 2和Python 3之间的线程模块接口中去除Java风格的过程中完成的，该过程非常麻烦，以至于没有人自愿“修复”任何其他受类似风格问题困扰的API）。

- ncoghlan

Answer 2

来自PEP8的内容：

但最重要的是：知道何时不一致 - 有时样式指南并不适用。如果有疑问，请根据您的最佳判断力使用。查看其他示例，决定哪个看起来最好。不要犹豫，提出问题！

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

- rob

Answer 3

Python标准库的控制程度并不像它本可以做到的那样严格，模块的风格也各不相同。虽然我不确定你的例子想要说明什么，但是Python的库确实没有像Java或Win32那样统一的声音。语言和库都是由全志愿团队构建的，没有任何公司为致力于该语言的人支付工资，这有时会表现出来。

当然，我相信其他因素可以抵消这个负面因素，但这仍然是一个负面因素。

- Ned Batchelder