私は Java で企業の仕事をしたことはありませんが、逆ドメイン名のパッケージ命名規則をよく目にします。たとえば、Stack Overflow Java パッケージの場合、コードを package の下に置きますcom.stackoverflow。
Java のような規則を使用する Python パッケージに出くわしましたが、それに対する賛成意見と反対意見が何であるか、またはそれらが Java と同じように Python に適用されるかどうかがわかりませんでした。どちらかを優先する理由は何ですか? これらの理由はどの言語にも当てはまりますか?
問題が発生するため、Python はこれを行いません。他のほとんどすべてがサブパッケージである「com」パッケージの所有者は誰ですか? パッケージ階層を (ファイルシステム階層を介して) 確立する Python の方法は、この慣習とはまったくうまくいきません。パッケージ階層は「package」ステートメントに供給される文字列リテラルの構造によって定義されるため、Java はそれを回避できます。そのため、どこにも明示的な「com」パッケージが存在する必要はありません。
パッケージを公にリリースしたいが、パッケージ名に固執するのに適したドメイン名を所有していない場合、または何らかの理由でドメイン名を変更 (または紛失) した場合にどうするかという問題もあります。(後の更新では別のパッケージ名が必要ですか? com.nifty_consultants.nifty_utility が com.joe_blow_software.nifty_utility の新しいバージョンであることをどのように知ることができますか? 逆に、それが新しいバージョンではないことをどのように知ることができますか?ドメインの更新時にその名前がドメイン キャンパーに乗っ取られ、他の誰かが彼らから名前を購入し、ソフトウェア パッケージを公開したいと考えている場合、彼らはあなたが既に使用していたのと同じ名前を使用する必要がありますか?)
ドメイン名とソフトウェア パッケージ名は、2 つのまったく異なる問題に対処し、まったく異なる複雑な要因を持っているように私には思えます。(IMHO) 関心の分離に違反しているため、私は個人的に Java の規則が嫌いです。名前空間の衝突を回避することは素晴らしいことですが、私は自分のソフトウェアの名前空間がマーケティング部門とサードパーティの官僚機構とのやり取りによって定義される (そしてそれに依存する) という考えが嫌いです。
__init__.py私の主張をさらに明確にするために、JeeBee のコメントに応じて: Python では、パッケージはファイル (およびおそらく 1 つ以上のモジュール ファイル)を含むディレクトリです。パッケージ階層では、各上位レベルのパッケージが完全で正当なパッケージである必要があります。2 つのパッケージ (特に異なるベンダーからのものであるが、同じベンダーからの直接関係のないパッケージであっても) がトップレベルのパッケージ名を共有している場合、その名前が「com」、「web」、「utils」などであるかどうかに関係なく、それぞれその最上位パッケージに を提供する必要があります。__init__.pyまた、これらのパッケージはディレクトリ ツリーの同じ場所、つまり site-packages/[pkg]/[subpkg] にインストールされる可能性が高いと想定する必要があります。したがって、ファイルシステムは、1 つだけであることを強制します。 [pkg]/__init__.py――さて、勝つのはどっち？その質問に対する一般的なケースの正しい答えはありません (ありえません)。また、2 つのファイルを合理的にマージすることもできません。その中で別のパッケージが何をする必要があるのか わからないため__init__.py、トップレベルパッケージを共有するサブパッケージは、相互に互換性があるように特に書かれていない限り（少なくともこの1つのファイルで）、両方がインストールされている場合に機能すると想定できません）。これは配布の悪夢であり、パッケージをネストするという点全体がほとんど無効になります。これは逆ドメイン名パッケージ階層に固有のものではありませんが、それらは最も明白な悪い例を提供し、(IMO) 哲学的に疑わしいものです.ここで私の主な関心事。
(一方、サブパッケージを使用してそれ自体をよりよく整理するために単一の大きなパッケージを使用することは素晴らしいアイデアです。これらのサブパッケージは、連携して機能するように特別に設計されているためです。ただし、これは Python ではあまり一般的ではありません。組織の層を追加するために十分な数のファイルが必要になる傾向があります。)
Guido 自身がリバース ドメイン規則に従うべきだと発表した場合import、Python の実装に大幅な変更がない限り、それは採用されないでしょう。
考慮してください: Python は実行時にフェイルファスト アルゴリズムを使用してインポート パスを検索します。java は、コンパイル時と実行時の両方で徹底的なアルゴリズムを使用してパスを検索します。次のようにディレクトリを配置してみてください。
folder_on_path/
com/
__init__.py
domain1/
module.py
__init__.py
other_folder_on_path/
com/
__init__.py
domain2/
module.py
__init__.py
次に試してください：
from com.domain1 import module
from com.domain2 import module
これらのステートメントの 1 つだけが成功します。なんで？どちらかfolder_on_pathまたはどちらかother_folder_on_pathが検索パスの上位にくるからです。python は、取得できるfrom com.最初のcomパッケージを取得したことを確認します。たまたま が含まれている場合domain1は、最初のものimportが成功します。そうでない場合は、をスローしImportErrorてあきらめます。なんで？import実行時に発生する必要があるため、コードの流れの任意の時点で発生する可能性があります (ただし、ほとんどの場合は最初です)。一致する可能性がないことを確認するために、その時点で徹底的なツリー ウォークを行う必要はありません。comという名前のパッケージが見つかった場合、それがその パッケージであると想定しcomます。
さらに、python は次のステートメントを区別しません。
from com import domain1
from com.domain1 import module
from com.domain1.module import variable
それを検証する概念はcom、ケース comごとに異なります。Java では、実際には 2 番目のケースのみを処理する必要があり、それはファイル システムをウォークスルーすることで実現できます (クラスとファイルに同じ名前を付ける利点があると思います)。Python では、ファイル システムの支援だけでインポートを実行しようとすると、最初のケースは (ほぼ) 透過的に同じになり ( init .py は実行されません)、2 番目のケースは実行できますが、最初のファイルは失われます。 module.py を実行していますが、3 番目のケースはまったく達成できません。コードを使用可能にするには、実行するvariable必要があります。これはもう 1 つの要点importです。名前空間を解決するだけでなく、コードを実行します。
これまでに配布されたすべての python パッケージで、フォルダー、次に などを検索するインストール プロセスが必要な場合は、これを回避できますが、これによりパッケージ化がかなり難しくなり、ドラッグ アンド ドロップ機能が破壊されます。そして、パッケージングと全面的な迷惑になります。comdomain
Joel on Softwareのどこかで、Joelは、会社を成長させる2つの方法を比較しています。ベン＆ジェリーズの方法は小さく始まり、有機的に成長します。Amazonの方法は、最初から多額の資金を調達し、非常に幅広い請求を行う方法です。 。
SunがJavaを導入したとき、それはファンファーレと誇大宣伝でした。Javaが引き継ぐことになっていた。将来の関連するソフトウェア開発のほとんどは、Webで配信されるJavaアプレットで行われます。ブラスバンドやポニーもあります。この文脈では、インターネットベースで、企業にやさしく、惑星規模の命名規則を前もって確立することが賢明でした。
OK、Sunが望んでいたようにはうまくいきませんでしたが、彼らは成功するかのように計画しました。個人的には、成功によって損なわれる可能性のあるプロジェクトを軽蔑しています。
Pythonは当初GuidovanRossumによるプロジェクトでしたが、van Rossumがバスにぶつかった場合にコミュニティが生き残ると確信するまでには、かなりの時間がかかりました。私の知る限り、世界を引き継ぐ最初の計画はなく、Webアプレット言語として意図されていませんでした。
したがって、言語の形成段階では、命名スキームに広大な階層が必要になる理由はありませんでした。そのより非公式なコミュニティでは、多かれ少なかれ気まぐれなプロジェクト名を選択し、他の誰かがすでにそれを使用しているかどうかを確認しました。（英国のコメディショーの後にコンピューター言語に名前を付けることは、始めたばかりでは気まぐれであると見なされるかもしれません。）大きくても想像を絶する不器用な名前付けスキームに対応する必要性は認識されていませんでした。
「どちらかを優先する理由は何ですか?」
Python のスタイルはより単純です。Java のスタイルでは、異なる組織の同名の製品を使用できます。
「それらの理由はどの言語にも当てはまりますか?」
はい。「com」、「org」、「mil」、「net」、「edu」、「gov」という名前の最上位の Python パッケージを簡単に作成し、パッケージをこれらのサブパッケージとして配置できます。
編集します。誰もが協力しなければならず、これらのトップレベルのパッケージを自分の粗悪品で汚染しないよう にする必要があるため、これを行うと多少複雑になります。
名前空間の衝突は (実際問題として) かなりまれであることが判明したため、Python はそれを開始しませんでした。
Java を開発した人々が、多くの人が無知にパッケージに同じ名前を選択し、衝突と所有権の問題を整理する必要があることを予見したため、Java はそれを始めました。
Java 関係者は、名前の衝突を避けるために、オープン ソース コミュニティが奇妙なユニークな名前を選ぶとは予想していませんでした。興味深いことに、xml パーサーを作成する人は、それを「パーサー」とは呼びません。彼らはそれを「Saxon」または「Xalan」またはまったく奇妙なものと呼んでいるようです.
これは、名前の競合を防ぐ優れた方法であり、既存のドメイン ネーム システムを最大限に活用するため、追加の官僚制度や登録は必要ありません。シンプルで素晴らしいです。
ドメイン名を逆にすることで、階層構造にもなるので便利です。したがって、最後にサブパッケージを含めることができます。
唯一の欠点は名前の長さですが、私にとってそれはまったく欠点ではありません。それをサポートするどの言語にとっても、それはかなり良い考えだと思います。
たとえば、JavaScript ライブラリがそれを行わないのはなぜですか? それらのグローバル名前空間は大きな問題ですが、Javascript ライブラリは「$」のような単純なグローバル識別子を使用しており、他の Javascript ライブラリと衝突します。
The idea is to keep name spaces conflict free. Instead of unreadable UUIDs or the like, the reverse domain name is unlikely to get in someone else's way. Very simple, but pragmatic. Moreover when using 3rd party libs it might give you a clue as to where they came from (for updates, support etc.)
Pythonにはそれがあります。これは、よりフラットな階層です。os.pathたとえば、 を見てください。そして、ライブラリ設計者が Django などのより深いものを作成するのを止めるものは何もありません。
基本的に、Python は、事前にあまり指定したり入力したりせずに作業を完了したいという考えに基づいて設計されていると思います。これは、スクリプト作成とコマンドラインの使用に非常に役立ちます。この理由を説明する「The Zen of Python」のいくつかの部分があります。
一方、次のようなものがあります。
Java は、推奨される Java 標準のプラクティスであり、Java コミュニティによってほぼ普遍的に受け入れられているため、このようにすることができます。Python にはこの規則がありません。