5

我试图理解为什么 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，即使是新功能？

4

3 回答 3

10

PEP 8 建议使用下划线作为默认选项，但通常出于以下两个原因之一将其省略：

  • 与其他 API 的一致性（例如当前模块或标准接口）
  • 因为将它们排除在外不会损害可读性（甚至提高可读性）

要解决您引用的具体示例：

  • 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 之间的模块接口进行去 Java 化，这个过程非常烦人，以至于没有人else 自愿“修复”任何其他受类似风格问题困扰的 API）。

于 2011-03-01T00:58:59.420 回答
4

来自 PEP8：

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

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

于 2011-02-28T23:28:23.767 回答
2

Python 标准库并没有像它应该的那样严格控制，并且模块的样式也各不相同。我不确定您的示例是要说明什么，但确实 Python 的库没有像 Java 那样或 Win32 那样的单一声音。该语言（和图书馆）是由全志愿人员构建的，没有公司向致力于该语言的人支付薪水，而且有时会显示出来。

当然，我相信其他因素超过了这个负面因素，但它仍然是负面的。

于 2011-02-28T23:23:07.640 回答