Pythonの「PEP-302新しいインポートフック」の経験[非公開]

私はRuby（CRuby）の開発者の一人です。Ruby 2.0のリリースに取り組んでいます（2012年2月のリリースを予定しています）。

Pythonには「PEP302：New Import Hooks」（2003）があります：

このPEPは、Pythonインポートメカニズムのより良いカスタマイズを提供するインポートフックの新しいセットを追加することを提案しています。現在のインポートフックとは異なり、新しいスタイルのフックを既存のスキームに挿入して、モジュールの検索方法とロード方法をより詳細に制御できます。

PEP302に類似した機能をRuby 2.0（CRuby 2.0）に導入することを検討しています。マッツを説得できる提案をしたい。現在、CRubyは標準的な方法でファイルシステムからのみスクリプトをロードできます。

PEP 302についての経験や考慮事項がある場合は、共有してください。

例：

1. それは素晴らしい仕様です。変更する必要はありません。
2. それはほとんど良いですが、この問題があります...
3. 2003年に戻ることができたら、仕様を...

私はPythonのrunpyモジュールのメンテナーであり、現在のインポートシステムのメンテナーの1人です。インポートシステムは非常に柔軟性がありますが、いくつかの調整を行わずに卸売りを採用することはお勧めしません。

PythonのPEP 302で痛いのは、コアインポートシステムを使用に変換するのにどれくらい時間がかかったかです。10年の大部分において、インポートフックで複雑なことをしている人は誰でも、2つの部分を実装するために立ち往生しています。PEP 302ローダーの処理が標準ファイルシステムインポートメカニズムを介してインポートされたモジュールの処理も行うのは、今後の3.3のみです。おそらくそれを回避できる場合は、その間違いを繰り返さないようにしてください。

PEP 420（Python 3.3用に実装）は、インポーターが名前空間パッケージに一部を提供できるように、プロトコルにいくつかの追加を行います。また、Finder API定義の名前の問題も修正します（誤った名前の "find_module"をより正確な "find_loader"に効果的に置き換えます）。これは、数週間後に3.3rc1がロールバックするまでに、すべて言語仕様でより明確に文書化されるはずです。

もう1つの注目すべき問題は、PEP 302に具体的に記載されているアプローチのプロセスグローバル状態が多すぎることです。その経路をたどらないでください-他のモジュールを選択してインポートするのが少し簡単になるように、より一貫性のあるオブジェクトモデルに状態をカプセル化してみてください役立つことがあります）。

PEP 406（http://www.python.org/dev/peps/pep-0406/）では、状態のカプセル化を改善した、Pythonのアプローチの後方互換性のある進化について説明しています。ただし、最初からカプセル化された状態モデルがある場合は、それに応じてAPIを定義し、インポーターとローダーがグローバル状態にアクセスすることをまったく回避できます（代わりにアクティブエンジンへの参照が渡されます）。

PEP 302で欠けているもう1つの要素は、インポーターが提供するモジュールのイテレーターをインポーターに要求する機能です（これは、docstringを抽出するフリーズユーティリティや自動ドキュメントユーティリティなどに必要です）。信じられないほど便利なので、おそらくget goから標準化する方が良いでしょう：http : //docs.python.org/dev/library/pkgutil#pkgutil.iter_modules（おそらく最終的に正式に指定されたものに引き上げるでしょう） Python 3.4のAPI）

最後のコメントは、インポートシステムとローダーオブジェクトの責任分担をよく見る必要があるということです。特に、「load_module」APIを個別の「init_module」および「exec_module」ステップに分割することを検討してください。これにより、ローダーがインポート状態と直接対話する必要がある程度を最小限に抑えることができます。

PEP 302とimportlibは、より柔軟なインポートシステムの優れた出発点ですが、回避する価値のある間違いは間違いなくあります。

ncoghlanの次は、Pythonのインポートシステムの他のメンテナーであり、現在の実装importlib（http://docs.python.org/dev/py3k/library/importlib.html）の作成者です。ニックが言ったことはすべて同意するので、追加情報を追加したいだけです。

まず、PEP 302に直接依存しすぎるのではなく、抽象基本クラスなどの点でimportlibが提供するものを見てください。後方互換性のために、PEP 302と互換性がなければなりませんでしたが、 APIを所有して、真の柔軟性のサポートを具体化します。

もう1つの重要な点は、開発者に2つの柔軟性を与えることです。1つは、個別のファイルとしてファイルシステムに直接保存する以外の方法でコードを保存する機能です（インポート用にストレージバックエンドと呼びます）。たとえば、これはコードをzipファイル、sqliteデータベースなどに保存できます他のサポートは、Quixote（https://www.mems-exchange.org/software/quixote/）などの何らかの方法でコードの前処理または後処理を制御できるようにすることと、割り当てられていない文字列リテラルの代替使用です。変数をサポートする方がはるかに簡単です。

後者はほとんど必要ありませんが、前者はサポートについて心配する必要がある場所です。そして、ここで実際にファイルシステムの相互作用APIを再定義します。一部の人々はコードとともにファイルとして保存されたアセットを必要とするため、ファイルの読み取り、ファイルの検出などを行うための良い方法を提供する必要があります。 。

ただし、コード固有のAPIも必要になります。Nickが述べたように、パッケージに含まれるモジュールなどを発見するためには、ファイル固有ではないAPIが必要になります。ファイルの概念を抽出したモジュールを処理するためのAPIを持つという奇妙な二重性がありますが、ファイルのようなアセットデータにアクセスするためのAPIを提供する必要があります。そして、重複を避けるために一方を他方に関して実装しようとするとすぐに、水は本当に暗くなります（つまり、人々は、パスが本当のパスではないかもしれないという事実に注意を払わずに、予想されるファイルパスの構造化などに頼ることになります）これは、ファイルだけでなくコードを含むzipファイル用です）。IOWでは、2つの同様のAPIを実装する必要がありますが、長期的にはより良いものになります。

ニックが言ったように、私たちのソリューションは良い出発点ですが、APIをゼロから設計する場合、今日のやり方ではありません。

PEP 302では、Pythonインポートメカニズムにフックできます。つまり、データベース、zipファイルなどの他のソースからコードをインポートできます。

インポートのPython実装には、インポートのPython実装の導入によってすぐに簡素化される複雑さの長い歴史があります。

コーナーケースについて、長く真剣に考えることをお勧めします。次に、有用な実装を取得する可能性があります。