这只是出于历史目的的好奇心：
我想知道是否有人知道为什么广泛使用的（和核心模块）logging不遵循Python的PEP-8 naming convention。
例如，在
中>>> import logging
>>> log = logging.getLogger("hello")
我希望它是get_logger，但事实并非如此。
关于function names，PEP8标准说：
只允许在已经存在的情况下使用mixedCase 主流风格（例如threading.py），向后保留 兼容性。
是这样的吗？如果是这样，那么其他logging什么东西必须保持向后兼容性？或者只是logging的开发人员感觉喜欢使用驼峰式命名？
当然，该模块已有详细记录，并不是什么大不了的事情 。我只是好奇。
答案 0 :(得分：33)
logging模块是由separate company在2001年开发的，主要基于Log4j。因此，它遵循原作者选择的命名约定，这反映了Log4j的选择;后者有一个getLogger() method too。
直到一年后，PEP 282才建议将其添加到标准库中，这时命名约定就是一成不变的。
这是known issue with the package，但它不是唯一违反PEP的程序包。来自链接的Wiki：
PEP8说 - 与这种风格指南的一致性非常重要。项目的一致性更为重要。一个模块或功能的一致性是最重要的。
- 如此正确，但由于向后兼容性，不能改变。 logging2也许吧。 - techtonik
- 现在这是一个低优先级，除非有一项倡议确保stdlib的其余部分符合PEP8。 - VinaySajip
最后但同样重要的是，styleguide itself在应用styleguides时有这个说法：
愚蠢的一致性是小思想的大地精
风格指南是关于一致性的。与此风格指南的一致性非常重要。项目的一致性更为重要。一个模块或功能的一致性是最重要的。
但最重要的是：知道何时不一致 - 有时风格指南不适用。如有疑问，请使用您的最佳判断。查看其他示例并确定最佳效果。并且毫不犹豫地问！
特别是：不要为了遵守这个PEP而破坏向后兼容性！
'修复'logging会破坏向后兼容性，这是不值得的。