Python のロギングモジュールが PEP8 規則に従わないのはなぜですか? 質問する

Python のロギングモジュールが PEP8 規則に従わないのはなぜですか? 質問する

これは歴史的な目的を持った単なる好奇心です:

非常に広く使用されている(コアモジュール)がなぜログ記録PythonのPEP-8 命名規則

例えば、

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

そうなるだろうと予想していましたget_loggerが、そうではありませんでした。

となると関数名PEP8 標準では次のように述べられています。

下位互換性を維持するために、mixedCase は、それがすでに一般的なスタイルであるコンテキスト (例: threading.py) でのみ許可されます。

そうだったのですか? もしそうなら、logging下位互換性を維持するために他に何をしなければならなかったのですか? それとも、開発者がloggingキャメルケースの命名法を使いたかっただけでしょうか?

もちろん、モジュールは十分に文書化されており、大した問題ではありませんまったくただ興味があるだけです。

ベストアンサー1

このloggingモジュールは、別の会社2001年に開発され、Log4jをベースにしています。そのため、オリジナルの作者が選んだ命名規則に従っており、これはLog4jの選択を反映しています。後者はgetLogger()方法も

1年後になってようやくペップ282それを標準ライブラリに追加することを提案し、その時点で命名規則は確定しました。

それはパッケージの既知の問題ただし、PEP に違反するパッケージはこれだけではありません。リンク先の Wiki から引用:

PEP8 には、「このスタイル ガイドとの一貫性は重要です。プロジェクト内の一貫性はさらに重要です。1 つのモジュールまたは関数内の一貫性が最も重要です。」と書かれています。

  • 確かにそうですが、下位互換性のため変更できません。おそらくlogging2でしょう。 -- techtonik
    • 残りの stdlib が PEP8 に準拠するようにする取り組みがない限り、現時点では優先度は低いです。 -- VinaySajip

最後になりましたが、スタイルガイド自体スタイルガイドの適用については次のように述べています。

愚かな一貫性は小さな心の悪魔である

スタイル ガイドは一貫性に関するものです。このスタイル ガイドとの一貫性は重要です。プロジェクト内の一貫性はさらに重要です。1 つのモジュールまたは機能内の一貫性が最も重要です。

しかし、最も重要なのは、一貫性を欠くべきときを知ることです。スタイル ガイドが適用されない場合もあります。疑問がある場合は、最善の判断を下してください。他の例を見て、最も見栄えが良いものを決めてください。そして、遠慮なく質問してください。

特に、この PEP に準拠するためだけに下位互換性を破壊しないでください。

「修正」するとlogging下位互換性が失われるため、それだけの価値はありません。

おすすめ記事