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 建议使用下划线作为默认选择，但通常出于以下两个原因之一将其保留下来:

• 与其他一些 API(例如当前模块或标准接口(interface))的一致性
• 因为将它们排除在外并不会影响可读性(甚至可以提高可读性)

针对您引用的具体示例:

• 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 发布模块，通常不值得尝试和纠正它们(这样做是为了去 Java 化 Python 2 和 Python 之间的 threading 模块接口(interface)) Python 3，这个过程非常烦人，以至于没有人自愿“修复”任何其他受类似风格问题困扰的 API。