Python的日志记录模块为什么不遵循PEP8规范？

Question

这只是一个带有历史目的的好奇心：

我想知道是否有人知道为什么广泛使用的（和核心模块）logging没有遵循Python的PEP-8 命名规范。

例如，在

>>> import logging
>>> log = logging.getLogger("hello")

我本来以为它应该是get_logger，但实际上并不是。

关于函数名称，PEP8标准规定：

混合大小写只允许在已经存在这种风格的情况下使用（例如：threading.py），以保持向后兼容性。

那么这是否是这种情况呢？如果是，那么它还需要与哪些其他的logging工具保持向后兼容呢？还是说logging的开发人员只是想使用驼峰命名法呢？

当然，这个模块有很好的文档，这并不是什么大问题。我只是好奇。

- BorrajaX

---

由于历史原因，并非所有模块都是在 Python 标准库内开发的，也并非所有作者都遵循指南。 - Martijn Pieters

Answer 1

logging模块是由一个独立的公司于2001年开发的，其基础非常依赖于Log4j。因此，它遵循了原始作者选择的命名约定，这与Log4j的选择相似；后者也有getLogger()方法。

直到一年后，PEP 282才提议将其添加到标准库中，此时命名约定已经确定。

这是该包已知的问题，但它并不是唯一违反PEP的包。来自链接维基的信息：

PEP8指出-遵循此样式指南的一致性非常重要。项目内的一致性更为重要。模块或函数内的一致性最为重要。

• 如此正确，但由于向后兼容性，不能改变。也许可以使用logging2。--techtonik
  • 现在它不是首要任务，除非有倡议确保其余的stdlib符合PEP8。--VinaySajip

最后，样式指南本身对应用样式指南有以下建议：

愚蠢的一致性是小心灵的妖怪

风格指南是关于一致性的。与这个风格指南的一致性非常重要。在项目中保持一致更为重要。在一个模块或函数内保持一致最为重要。

但最重要的是：知道何时不一致 - 有时风格指南并不适用。如果有疑问，请根据自己的判断力来决定。查看其他示例并决定哪个看起来最好。并且不要犹豫询问！

特别是：不要为了遵守此PEP而破坏向后兼容性！

'修复' logging 将破坏向后兼容性，这只是不值得的。

- Martijn Pieters

---

许多模块都提供API的两个版本（uglyCase和python_case），目的是为了向后兼容。 - Mischa Arefiev

PHP 仍然受到嘲笑的原因是“未修复” logging（和其他问题），即不提供合理的别名而保持向后兼容性。 - rr-

除了命名不一致之外，嘲笑 PHP 的原因还有很多。 - Martijn Pieters