31.5. importlib — import の実装¶
バージョン 3.1 で追加.
ソースコード: Lib/importlib/__init__.py
31.5.1. はじめに¶
importlib パッケージの目的は2つあります。1つ目は Python ソースコード中にある import 文の(そして、拡張として、 __import__() 関数の)実装を提供することです。このパッケージは import 文の、どの Python インタープリターでも動作する実装を提供します。また、 Python 以外の言語で実装されたどの実装よりも把握しやすい実装を提供します。
2つ目の目的は、このパッケージが公開している import を実装するための要素を利用して、(インポーター として知られる) インポートプロセスで動作するカスタムのオブジェクトを実装しやすくすることです。
参考
- import 文
import文の言語リファレンス。- パッケージ仕様
パッケージの元の仕様。幾つかの動作はこの仕様が書かれた頃から変更されています (例:
sys.modulesでNoneに基づくリダイレクト)。__import__()関数import文はこの関数のシンタックスシュガーです。- PEP 235
大文字小文字を区別しないプラットフォームでのインポート
- PEP 263
Python のソースコードのエンコーディング
- PEP 302
新しいインポートフック
- PEP 328
複数行のインポートと、絶対/相対インポート
- PEP 366
main モジュールの明示的な相対インポート
- PEP 420
暗黙的な名前空間パッケージ
- PEP 451
インポートシステムのための ModuleSpec 型
- PEP 488
PYO ファイルの撤廃
- PEP 489
複数フェーズでの拡張モジュールの初期化
- PEP 3120
デフォルトのソースエンコーディングとして UTF-8 を使用
- PEP 3147
PYC リポジトリディレクトリ
31.5.2. 関数¶
-
importlib.__import__(name, globals=None, locals=None, fromlist=(), level=0)¶ 組み込みの
__import__()関数の実装です。注釈
プログラムからモジュールをインポートする場合はこの関数の代わりに
import_module()を使ってください。
-
importlib.import_module(name, package=None)¶ モジュールをインポートします。name 引数は、インポートするモジュールを絶対または相対表現 (例えば
pkg.modまたは..mod) で指定します。name が相対表現で与えられたら、package 引数を、パッケージ名を解決するためのアンカーとなるパッケージの名前に設定する必要があります (例えばimport_module('..mod', 'pkg.subpkg')はpkg.modをインポートします)。import_module()関数はimportlib.__import__()を単純化するラッパーとして働きます。つまり、この関数のすべての意味はimportlib.__import__()から受け継いでいます。これらの2つの関数の最も重要な違いは、import_module()が指定されたパッケージやモジュール (例えばpkg.mod) を返すのに対し、__import__()はトップレベルのパッケージやモジュール (例えばpkg) を返すことです。もしモジュールを動的にインポートしていて、インタープリタの実行開始後にモジュールが作成された (例えば、 Python ソースファイルを作成した) 場合、インポートシステムが新しいモジュールを見つけられるように、
invalidate_caches()を呼ぶ必要があるでしょう。バージョン 3.3 で変更: 親パッケージは自動的にインポートされます。
-
importlib.find_loader(name, path=None)¶ モジュールのローダーを、オプションで指定された path 内から、検索します。モジュールが
sys.modulesにあれば、sys.modules[name].__loader__が返されます (ただしローダーがNoneであるか設定されていなければValueErrorが送出されます)。なければ、sys.meta_pathを使った検索がなされます。ローダーが見つからなければNoneが返ります。ドットのついた名前表記は、親モジュールのロードが必要なときに暗黙にインポートしないので、望ましくありません。 サブモジュールを適切にインポートするには、そのサブモジュールの全ての親パッケージをインポートし、 path に正しい引数を使ってください。
バージョン 3.3 で追加.
バージョン 3.4 で変更:
__loader__が set でない場合、Noneに設定されているときと同様にValueErrorを送出します。バージョン 3.4 で撤廃: 代わりに
importlib.util.find_spec()を使用してください。
-
importlib.invalidate_caches()¶ sys.meta_pathに保存されたファインダーの内部キャッシュを無効にします。ファインダーがinvalidate_caches()を実装していれば、無効化を行うためにそれが呼び出されます。すべてのファインダーが新しいモジュールの存在に気づくことを保証しているプログラムの実行中に、モジュールが作成またはインストールされたなら、この関数が呼び出されるべきです。バージョン 3.3 で追加.
-
importlib.reload(module)¶ 以前にインポートされた module をリロードします。引数はモジュールオブジェクトでなければならず、したがってそれ以前に必ずインポートに成功していなければなりません。この関数は、モジュールのソースファイルを外部エディタで編集していて Python インタープリタから離れることなく新しいバージョンを試したい際に便利です。戻り値はモジュールオブジェクトです。 (もし再インポートが異なるオブジェクトを
sys.modulesに配置したら、元の module とは異なるかもしれません。)reload()が実行された場合:Python モジュールのコードは再コンパイルされ、モジュールレベルのコードが再度実行されます。モジュールの辞書中にある何らかの名前に結び付けられたオブジェクトは、そのモジュールを最初にロードしたときの ローダー を再利用して新たに定義されます。拡張モジュールの
init関数が二度呼び出されることはありません。Python における他のオブジェクトと同様、以前のオブジェクトのメモリ領域は、参照カウントがゼロにならないかぎり再利用されません。
モジュール名前空間内の名前は新しいオブジェクト (または更新されたオブジェクト) を指すよう更新されます。
以前のオブジェクトが (外部の他のモジュールなどからの) 参照を受けている場合、それらを新たなオブジェクトに再束縛し直すことはないので、必要なら自分で名前空間を更新しなければなりません。
いくつか補足説明があります:
モジュールが再ロードされた際、その辞書 (モジュールのグローバル変数を含みます) はそのまま残ります。名前の再定義を行うと、以前の定義を上書きするので、一般的には問題はありません。新たなバージョンのモジュールが古いバージョンで定義された名前を定義していない場合、古い定義がそのまま残ります。辞書がグローバルテーブルやオブジェクトのキャッシュを維持していれば、この機能をモジュールを有効性を引き出すために使うことができます — つまり、
try文を使えば、必要に応じてテーブルがあるかどうかをテストし、その初期化を飛ばすことができます:try: cache except NameError: cache = {}
組み込みモジュールや動的にロードされるモジュールを再ロードすることは、一般的にそれほど便利ではありません。
sys,__main__,builtinsやその他重要なモジュールの再ロードはお勧め出来ません。多くの場合、拡張モジュールは 1 度以上初期化されるようには設計されておらず、再ロードされた場合には何らかの理由で失敗するかもしれません。一方のモジュールが
from...import... を使って、オブジェクトを他方のモジュールからインポートしているなら、他方のモジュールをreload()で呼び出しても、そのモジュールからインポートされたオブジェクトを再定義することはできません — この問題を回避する一つの方法は、from文を再度実行することで、もう一つの方法はfrom文の代わりにimportと限定的な名前 (module.name) を使うことです。あるモジュールがクラスのインスタンスを生成している場合、そのクラスを定義しているモジュールの再ロードはそれらインスタンスのメソッド定義に影響しません — それらは古いクラス定義を使い続けます。これは派生クラスの場合でも同じです。
バージョン 3.4 で追加.
31.5.3. importlib.abc – インポートに関連する抽象基底クラス¶
ソースコード: Lib/importlib/abc.py
importlib.abc モジュールは、 import に使われるすべてのコア抽象基底クラス含みます。コア抽象基底クラスの実装を助けるために、コア抽象基底クラスのサブクラスもいくつか提供されています。
抽象基底クラス階層:
object
+-- Finder (deprecated)
| +-- MetaPathFinder
| +-- PathEntryFinder
+-- Loader
+-- ResourceLoader --------+
+-- InspectLoader |
+-- ExecutionLoader --+
+-- FileLoader
+-- SourceLoader
-
class
importlib.abc.Finder¶ finder を表す抽象基底クラスです。
バージョン 3.3 で撤廃: 代わりに
MetaPathFinderまたはPathEntryFinderを使ってください。-
abstractmethod
find_module(fullname, path=None)¶ 指定されたモジュールの ローダー を検索するための抽象メソッドです。もとは PEP 302 で仕様が定められ、このメソッドは
sys.meta_pathの中およびパスに基づくインポートサブシステムの中で使用することを意図されています。バージョン 3.4 で変更: 呼び出されたときに
NotImplementedErrorを送出する代わりにNoneを返します。
-
abstractmethod
-
class
importlib.abc.MetaPathFinder¶ meta path finder を表す抽象基底クラスです。互換性のため、これは
Finderのサブクラスです。バージョン 3.3 で追加.
-
find_spec(fullname, path, target=None)¶ 指定されたモジュールに対応する スペック を検索する抽象メソッド。もしこれがトップレベルのインポートなら、 path は
Noneです。そうでなければ、これはサブパッケージまたはモジュールのための検索で、 path は親パッケージの__path__の値です。スペックが見つからなければNoneが返されます。targetは、もし渡された場合はモジュールオブジェクトです。ファインダーがどのようなスペックを返せばよいかについての情報を得るために使用します。バージョン 3.4 で追加.
-
find_module(fullname, path)¶ 指定されたモジュールの ローダー を検索するためのレガシーなメソッドです。これがトップレベルのインポートなら、 path は
Noneになります。そうでなければ、これはサブパッケージまたはモジュールの検索で、 path は親パッケージの__path__の値になります。ローダーが見つからなければ、Noneが返されます。find_spec()が定義された場合、後方互換な機能が提供されます。バージョン 3.4 で変更: このメソッドが呼ばれた場合
NotImplementedErrorを投げる代わりにNoneを返します。この機能を提供するのにfind_spec()を使用できます。バージョン 3.4 で撤廃: 代わりに
find_spec()を使用してください。
-
invalidate_caches()¶ このファインダーで使われている内部キャッシュがあれば無効にするオプションのメソッドです。
sys.meta_path上のすべてのファインダーのキャッシュを無効化する際、importlib.invalidate_caches()によって使われます。バージョン 3.4 で変更: 呼び出されたときに
NotImplementedを送出する代わりにNoneを返します。
-
-
class
importlib.abc.PathEntryFinder¶ パスエントリ・ファインダー を表す抽象基底クラスです。
MetaPathFinderと似ているところがありますが、PathEntryFinderはPathFinderの与えるパスに基づくインポートサブシステムの中でのみ使うことが意図されています。この抽象基底クラスは互換性の理由だけのために、Finderのサブクラスにしてあります。バージョン 3.3 で追加.
-
find_spec(fullname, target=None)¶ 指定されたモジュールに対応する スペック を検索する抽象メソッド。ファインダーは、割り当てられている パスエントリ 内のモジュールだけを検索します。スペックが見つからなければ
Noneが返されます。targetは、もし渡された場合はモジュールオブジェクトです。ファインダーがどのようなスペックを返せばよいかについての情報を得るために使用します。バージョン 3.4 で追加.
-
find_loader(fullname)¶ 指定されたモジュールの ローダー を検索する抽象メソッドです。
(loader, portion)の 2-タプルを返します。ただしportionは名前空間パッケージの部分に寄与するファイルシステム上の場所のシーケンスです。 loader は名前空間パッケージへのファイルシステム上の場所の寄与を表すportionを明記するときNoneにできます。loader が名前空間パッケージの一部ではないことを明記するときportionに空のリストが使えます。loaderがNoneでportionが空のリストなら、名前空間パッケージのローダーや場所が見つかりませんでした (すなわち、モジュールの何も見つかりませんでした)。find_spec()が定義された場合、後方互換な機能が提供されます。バージョン 3.4 で変更:
NotImplementedErrorを送出する代わりに(None, [])を返します。機能を提供できる場合find_spec()を使用します。バージョン 3.4 で撤廃: 代わりに
find_spec()を使用してください。
-
find_module(fullname)¶ Finder.find_module()の具象実装で、self.find_loader(fullname)[0]と等価です。バージョン 3.4 で撤廃: 代わりに
find_spec()を使用してください。
-
invalidate_caches()¶ このファインダーで使われている内部キャッシュがあれば無効にするオプションのメソッドです。キャッシュされたすべてのファインダーの無効化する際、
PathFinder.invalidate_caches()によって使われます。
-
-
class
importlib.abc.Loader¶ loader の抽象基底クラスです。ローダーの厳密な定義は PEP 302 を参照してください。
-
create_module(spec)¶ モジュールをインポートする際に使用されるモジュールオブジェクトを返すメソッド。このメソッドは
Noneを戻すことができ、その場合はデフォルトのモジュール作成のセマンティクスが適用されることを示します。バージョン 3.4 で追加.
バージョン 3.5 で変更: Python 3.6 からは、
exec_module()が定義されている場合は、このメソッドはオプションではなくなります。
-
exec_module(module)¶ モジュールがインポートまたはリロードされる際に、そのモジュールをモジュール自身の名前空間の中で実行する抽象的なメソッド。 exec_module() が呼ばれる時点で、モジュールはすでに初期設定されている必要があります。
バージョン 3.4 で追加.
-
load_module(fullname)¶ モジュールをロードするためのレガシーなメソッドです。モジュールがロードできなければ
ImportErrorを送出し、ロードできればロードされたモジュールを返します。要求されたモジュールが既に
sys.modulesに存在したなら、そのモジュールが使われリロードされる必要があります。存在しなければ、インポートからの再帰を防ぐため、ローダーはロードが始まる前に新しいモジュールを作成してsys.modulesに挿入する必要があります。ローダーがモジュールを挿入した後にロードが失敗したなら、ローダーはそのモジュールをsys.modulesから削除する必要があります。ローダーが実行を始める前に既にsys.modulesにあったモジュールは、そのままにします (importlib.util.module_for_loader()を参照してください)。ローダーはモジュールにいくつかの属性を設定する必要があります。(なお、これらの属性には、モジュールがリロードされた際に変化するものがあります):
__name__モジュールの名前です。
__file__モジュールのデータが保存されている場所へのパスです (組み込みモジュールには設定されません)。
__cached__モジュールのコンパイルされた版が保存されている (べき) 場所へのパスです (この属性が適切でないときには設定されません)。
__path__パッケージ内の検索パスを指定する文字列のリストです。この属性はモジュールには設定されません。
__package__モジュールやパッケージの親パッケージです。そのモジュールがトップレベルなら、空文字列の値をとります。
importlib.util.module_for_loader()デコレータで、__package__の詳細を扱えます。
__loader__モジュールをロードするのに使われたローダーです。
importlib.util.module_for_loader()デコレータで、__package__の詳細を扱えます。
exec_module()が利用可能な場合、後方互換な機能が提供されます。バージョン 3.4 で変更: このメソッドが呼ばれた時に、
NotImplementedErrorの代わりにImportErrorを送出します。exec_module()が利用可能な時は、この機能は提供されます。バージョン 3.4 で撤廃: モジュールをロードするための推奨される API は、
exec_module()(およびcreate_module()) です。ローダーは load_module() の代わりにそれを実装するべきです。 exec_module() が実装されている場合、インポート機構は load_module() の他のすべての責任を肩代わりします。
-
module_repr(module)¶ 実装されていた場合、与えられたモジュールの repr を計算して文字列として返すためのレガシーなメソッドです。モジュール型のデフォルトの repr() は、必要に応じてこのメソッドの結果を使います。
バージョン 3.3 で追加.
バージョン 3.4 で変更: 抽象メソッドではなくオプショナルになりました。
バージョン 3.4 で撤廃: インポート機構はこれを自動的に考慮するようになりました。
-
-
class
importlib.abc.ResourceLoader¶ loader の抽象基底クラスで、ストレージバックエンドから任意のリソースをロードするオプションの PEP 302 プロトコルを実装します。
-
abstractmethod
get_data(path)¶ path に割り当てられたデータのバイト列を返す抽象メソッドです。任意のデータを保管できるファイル的なストレージバックエンドをもつローダーは、この抽象メソッドを実装して、保管されたデータに直接アクセスさせるようにできます。 path が見つからなければ
OSErrorを送出する必要があります。 path は、モジュールの__file__属性を使って、またはパッケージの__path__の要素を使って、構成されることが期待されます。バージョン 3.4 で変更:
NotImplementedErrorの代わりにOSErrorを送出します。
-
abstractmethod
-
class
importlib.abc.InspectLoader¶ loader の抽象基底クラスで、ローダーがモジュールを検査するためのオプションの PEP 302 プロトコルを実装します。
-
get_code(fullname)¶ モジュールの
codeオブジェクトを返すか、 (例えば組み込みモジュールの場合に) モジュールがコードオブジェクトを持たなければNoneを返します。要求されたモジュールをローダーが見つけられなかった場合はImportErrorを送出します。注釈
このメソッドにはデフォルト実装がありますが、とはいえパフォーマンスのために、可能ならばオーバライドしたほうが良いです。
バージョン 3.4 で変更: このメソッドはもはや抽象メソッドではなく、具象実装が提供されます。
-
abstractmethod
get_source(fullname)¶ モジュールのソースを返す抽象メソッドです。これは認識されたすべての行セパレータを
'\n'文字に変換し、 universal newlines を使ったテキスト文字列として返されます。利用できるソースがなければ (例えば組み込みモジュール)、Noneを返します。指定されたモジュールが見つからなければ、ImportErrorを送出します。バージョン 3.4 で変更:
NotImplementedErrorの代わりにImportErrorを送出します。
-
is_package(fullname)¶ モジュールがパッケージであれば True を返し、そうでなければ False を返す抽象メソッドです。 ローダー がモジュールを見つけられなかったなら
ImportErrorが送出されます。バージョン 3.4 で変更:
NotImplementedErrorの代わりにImportErrorを送出します。
-
static
source_to_code(data, path='<string>')¶ Python のソースからコードオブジェクトを作ります。
data 引数は
compile()関数がサポートするもの (すなわち文字列かバイト) なら何でも構いません。path 引数はソースコードの元々の場所への “パス” でなければなりませんが、抽象概念 (例えば zip ファイル内の場所) でも構いません。結果のコードオブジェクトを使って、
exec(code, module.__dict__)を呼ぶことでモジュール内でコードを実行できます。バージョン 3.4 で追加.
バージョン 3.5 で変更: スタティックメソッドになりました。
-
exec_module(module)¶ Loader.exec_module()の実装です。バージョン 3.4 で追加.
-
load_module(fullname)¶ Loader.load_module()の実装です。バージョン 3.4 で撤廃: 代わりに
exec_module()を使用してください。
-
-
class
importlib.abc.ExecutionLoader¶ InspectLoaderから継承された抽象基底クラスで、実装されていれば、モジュールをスクリプトとして実行する助けになります。この抽象基底クラスはオプションの PEP 302 プロトコルを表します。-
abstractmethod
get_filename(fullname)¶ 指定されたモジュールの
__file__の値を返す抽象メソッドです。利用できるパスがなければ、ImportErrorが送出されます。ソースコードが利用できるなら、そのモジュールのロードにバイトコードが使われたかにかかわらず、このメソッドはそのソースファイルへのパスを返す必要があります。
バージョン 3.4 で変更:
NotImplementedErrorの代わりにImportErrorを送出します。
-
abstractmethod
-
class
importlib.abc.FileLoader(fullname, path)¶ ResourceLoaderとExecutionLoaderから継承された抽象基底クラスで、ResourceLoader.get_data()およびExecutionLoader.get_filename()の具象実装を提供します。fullname 引数は、ローダーが解決しようとするモジュールの、完全に解決された名前です。path 引数は、モジュールのファイルへのパスです。
バージョン 3.3 で追加.
-
name¶ ローダーが扱えるモジュールの名前です。
-
path¶ モジュールのファイルへのパスです。
-
load_module(fullname)¶ 親クラスの
load_module()を呼び出します。バージョン 3.4 で撤廃: 代わりに
Loader.exec_module()を使用してください。
-
abstractmethod
get_data(path)¶ path をバイナリファイルとして読み込み、そのバイト列を返します。
-
-
class
importlib.abc.SourceLoader¶ ソース (オプションでバイトコード) ファイルのロードを実装する抽象基底クラスです。このクラスは、
ResourceLoaderとExecutionLoaderの両方を継承し、以下の実装が必要です:ResourceLoader.get_data()ExecutionLoader.get_filename()ソースファイルへのパスのみを返す必要があります。ソースなしのロードはサポートされていません。
このクラスでこれらの抽象メソッドを定義することで、バイトコードファイルを追加でサポートします。これらのメソッドを定義しなければ (またはそのモジュールが
NotImplementedErrorを送出すれば)、このローダーはソースコードに対してのみ働きます。これらのメソッドを実装することで、ローダーはソースとバイトコードファイル の組み合わせ に対して働きます。バイトコードのみを与えた ソースのない ロードは認められません。バイトコードファイルは、 Python コンパイラによる解析の工程をなくして速度を上げる最適化です。ですから、バイトコード特有の API は公開されていません。-
path_stats(path)¶ 指定されたパスについてのメタデータを含む
dictを返す、オプションの抽象メソッドです。サポートされる辞書のキーは:'mtime'(必須): ソースコードの更新時刻を表す整数または浮動小数点数です。'size'(任意): バイト数で表したソースコードのサイズです。
未来の拡張のため、辞書内の他のキーは無視されます。パスが扱えなければ、
OSErrorが送出されます。バージョン 3.3 で追加.
バージョン 3.4 で変更:
NotImplementedErrorの代わりにOSErrorを送出します。
-
path_mtime(path)¶ 指定されたパスの更新時刻を返す、オプションの抽象メソッドです。
バージョン 3.3 で撤廃: このメソッドは廃止され、
path_stats()が推奨されます。このモジュールを実装する必要はありませんが、互換性のため現在も利用できます。パスが扱えなければ、OSErrorが送出されます。バージョン 3.4 で変更:
NotImplementedErrorの代わりにOSErrorを送出します。
-
set_data(path, data)¶ ファイルパスに指定されたバイト列を書き込むオプションの抽象メソッドです。存在しない中間ディレクトリがあれば、自動で作成されます。
パスへの書き込みが読み取り専用のために失敗したとき (
errno.EACCES/PermissionError) 、その例外を伝播させません。バージョン 3.4 で変更: 呼ばれたときに
NotImplementedErrorを送出することは最早ありません。
-
get_code(fullname)¶ InspectLoader.get_code()の具象実装です。
-
exec_module(module)¶ Loader.exec_module()の具象実装です。バージョン 3.4 で追加.
-
load_module(fullname)¶ Loader.load_module()の具象実装です。バージョン 3.4 で撤廃: 代わりに
exec_module()を使用してください。
-
get_source(fullname)¶ InspectLoader.get_source()の具象実装です。
-
is_package(fullname)¶ InspectLoader.is_package()の具象実装です。モジュールは、次の 両方 を満たすならパッケージであると決定されます。モジュールの (ExecutionLoader.get_filename()で与えられる) ファイルパスが、ファイル拡張子を除くと__init__という名のファイルであること。モジュール名自体が__init__で終わらないこと。
31.5.4. importlib.machinery – インポータおよびパスフック¶
ソースコード: Lib/importlib/machinery.py
このモジュールには、 import がモジュールを検索してロードするのに役立つ様々なオブジェクトがあります。
-
importlib.machinery.SOURCE_SUFFIXES¶ 認識されているソースモジュールのファイル接尾辞を表す文字列のリストです。
バージョン 3.3 で追加.
-
importlib.machinery.DEBUG_BYTECODE_SUFFIXES¶ 最適化されていないバイトコードモジュールのファイル接尾辞を表す文字列のリストです。
バージョン 3.3 で追加.
バージョン 3.5 で撤廃: 代わりに
BYTECODE_SUFFIXESを使ってください。
-
importlib.machinery.OPTIMIZED_BYTECODE_SUFFIXES¶ 最適化されたバイトコードモジュールのファイル接尾辞を表す文字列のリストです。
バージョン 3.3 で追加.
バージョン 3.5 で撤廃: 代わりに
BYTECODE_SUFFIXESを使ってください。
-
importlib.machinery.BYTECODE_SUFFIXES¶ 認識されているバイトコードモジュールのファイル接尾辞を表す文字列のリストです (先頭のドットを含みます)。
バージョン 3.3 で追加.
バージョン 3.5 で変更: この値は
__debug__に依存しなくなりました。
-
importlib.machinery.EXTENSION_SUFFIXES¶ 認識されている最適化された拡張モジュールのファイル接尾辞を表す文字列のリストです。
バージョン 3.3 で追加.
-
importlib.machinery.all_suffixes()¶ 標準のインポート機構によって認識されているすべてのファイル接尾辞を表す文字列の組み合わせられたリストを返します。これが役立つのは、あるファイルシステムパスがモジュールを参照する可能性があるかだけを知りたくて、そのモジュールの種類を詳しく知る必要はないコード (例えば
inspect.getmodulename()) です。バージョン 3.3 で追加.
-
class
importlib.machinery.BuiltinImporter¶ 組み込みモジュールの importer です。すべての既知のモジュールは
sys.builtin_module_namesに列挙されています。このクラスはimportlib.abc.MetaPathFinderおよびimportlib.abc.InspectLoader抽象基底クラスを実装します。インスタンス化を容易にするため、クラスメソッドだけがこのクラスによって定義されます。
バージョン 3.5 で変更: PEP 489 の一環として、ビルトインインポーターは
Loader.create_module()とLoader.exec_module()を実装しています。
-
class
importlib.machinery.FrozenImporter¶ フリーズされたモジュールの インポーター です。このクラスは
importlib.abc.MetaPathFinderおよびimportlib.abc.InspectLoader抽象基底クラスを実装します。インスタンス化を容易にするため、クラスメソッドだけがこのクラスによって定義されます。
-
class
importlib.machinery.WindowsRegistryFinder¶ Windows レジストリで宣言されたモジュールの Finder です。このクラスは
importlib.abc.Finder抽象基底クラスを実装します。インスタンス化を容易にするため、クラスメソッドだけがこのクラスによって定義されます。
バージョン 3.3 で追加.
-
class
importlib.machinery.PathFinder¶ sys.pathおよびパッケージの__path__属性の Finder です。このクラスはimportlib.abc.MetaPathFinder抽象基底クラスを実装します。インスタンス化を容易にするため、クラスメソッドだけがこのクラスによって定義されます。
-
classmethod
find_spec(fullname, path=None, target=None)¶ sys.pathまたは定義されていれば path から、 fullname で指定されたモジュールの スペック の検索を試みるクラスメソッドです。検索されるそれぞれのパスエントリに対してsys.path_importer_cacheが検査されます。偽でないオブジェクトが見つかれば、それが目的のモジュールを検索するための パスエントリ・ファインダー として使われます。sys.path_importer_cacheに目的のエントリが見つからなければ、パスエントリに対するファインダーがsys.path_hooksから検索され、見つかれば、それがsys.path_importer_cacheに保管されるとともに、モジュールについて問い合わせられます。それでもファインダーが見つからなければNoneが保管され、また返されます。バージョン 3.4 で追加.
バージョン 3.5 で変更: もしカレントワーキングディレクトリ – 空の文字列によって表されている – がすでに有効でなければ、
Noneが返されますが値はsys.path_importer_cacheにキャッシュされません。
-
classmethod
find_module(fullname, path=None)¶ find_spec()まわりのレガシーなラッパです。バージョン 3.4 で撤廃: 代わりに
find_spec()を使用してください。
-
classmethod
invalidate_caches()¶ sys.path_importer_cacheに保管されているすべてのファインダーに対してimportlib.abc.PathEntryFinder.invalidate_caches()を呼び出します。
バージョン 3.4 で変更:
''(すなわち空の文字列) に対してはカレントワーキングディレクトリとともにsys.path_hooksのオブジェクトを呼び出します。-
classmethod
-
class
importlib.machinery.FileFinder(path, *loader_details)¶ ファイルシステムからの結果をキャッシュする
importlib.abc.PathEntryFinderの具象実装です。path 引数は検索を担当するファインダーのディレクトリです。
loader_details 引数は、可変個の 2 要素タプルで、それぞれがローダーとローダーが認識するファイル接尾辞のシーケンスとを含みます。ローダーは、呼び出し可能でモジュール名と見つかったファイルのパスとの 2 引数を受け付けることを期待されます。
ファインダーはモジュール検索のたびに stat を呼び出し、必要に応じてディレクトリの内容をキャッシュすることで、コードキャッシュが古くなっていないことを確かめます。キャッシュの古さはオペレーティングシステムのファイルシステムのステート情報の粒度に依存しますから、モジュールを検索し、新しいファイルを作成し、その後に新しいファイルが表すモジュールを検索する、という競合状態の可能性があります。この操作が stat の呼び出しの粒度に収まるほど速く起こると、モジュールの検索が失敗します。これを防ぐためには、モジュールを動的に作成する際に、必ず
importlib.invalidate_caches()を呼び出してください。バージョン 3.3 で追加.
-
path¶ ファインダーが検索されるパスです。
-
invalidate_caches()¶ 内部キャッシュを完全に消去します。
-
classmethod
path_hook(*loader_details)¶ sys.path_hooksで使用するクロージャを返すクラスメソッドです。クロージャに直接渡された path 引数を直接的に、 loader_details を間接的に使って、FileFinderのインスタンスが返されます。クロージャへの引数が存在するディレクトリでなければ、
ImportErrorが送出されます。
-
-
class
importlib.machinery.SourceFileLoader(fullname, path)¶ importlib.abc.FileLoaderを継承し、その他いくつかのメソッドの具象実装を提供する、importlib.abc.SourceLoaderの具象実装です。バージョン 3.3 で追加.
-
name¶ このローダーが扱うモジュールの名前です。
-
path¶ ソースファイルへのパスです。
-
path_stats(path)¶
-
set_data(path, data)¶
-
load_module(name=None)¶ ロードするモジュールの名前指定がオプションの、
importlib.abc.Loader.load_module()の具象実装です。
-
-
class
importlib.machinery.SourcelessFileLoader(fullname, path)¶ バイトコードファイル (すなわちソースコードファイルが存在しない) をインポートできる
importlib.abc.FileLoaderの具象実装です。注意として、バイトコードを直接使う (つまりソースコードファイルがない) と、そのモジュールはすべての Python 実装では使用できないし、新しいバージョンの Python ではバイトコードフォーマットが変更されていたら使用できません。
バージョン 3.3 で追加.
-
name¶ ローダーが扱うモジュールの名前です。
-
path¶ バイトコードファイルへのパスです。
-
get_source(fullname)¶ このローダーが使われたとき、バイトコードファイルのソースがなければ
Noneを返します。
-
load_module(name=None)¶
ロードするモジュールの名前指定がオプションの、
importlib.abc.Loader.load_module()の具象実装です。-
-
class
importlib.machinery.ExtensionFileLoader(fullname, path)¶ 拡張モジュールのための
importlib.abc.ExecutionLoaderの具象実装です。fullname 引数はローダーがサポートするモジュールの名前を指定します。path 引数は拡張モジュールのファイルへのパスです。
バージョン 3.3 で追加.
-
name¶ ローダーがサポートするモジュールの名前です。
-
path¶ 拡張モジュールへのパスです。
-
is_package(fullname)¶ EXTENSION_SUFFIXESに基づいて、ファイルパスがパッケージの__init__モジュールを指していればTrueを返します。
-
get_code(fullname)¶ 拡張モジュールにコードオブジェクトがなければ
Noneを返します。
-
get_source(fullname)¶ 拡張モジュールにソースコードがなければ
Noneを返します。
-
-
class
importlib.machinery.ModuleSpec(name, loader, *, origin=None, loader_state=None, is_package=None)¶ モジュールのインポートシステム関連の状態の仕様です。
バージョン 3.4 で追加.
-
name¶
(
__name__)モジュールの完全修飾名を表す文字列です。
-
loader¶
(
__loader__)ロードに使うローダです。名前空間パッケージの場合
Noneに設定しなければなりません。-
origin¶
(
__file__)モジュールがロードされた場所の名前です。 例えば、組み込みのモジュールでは “builtin”、ソースからロードされたモジュールではファイル名です。 通常 “origin” は設定されるべきですが、未指定を示す
None(デフォルト) でもよいです。-
submodule_search_locations¶
(
__path__)パッケージの場合サブモジュールを見付けるべき場所を表す文字列のリスト (そうでない場合は
None) です。-
loader_state¶
ロード中に使う拡張モジュール指定のデータのコンテナ (または
None) です。-
cached¶
(
__cached__)コンパイルされたモジュールを保存すべき場所を表す文字列 (または
None) です。-
parent¶
(
__package__)(読み込み専用) サブモジュールとしてモジュールが属するパッケージの完全修飾名 (または
None) です。-
has_location¶
モジュールの “origin” 属性がロード可能な場所を参照しているかどうかを示すブール値です。
-
31.5.5. importlib.util – インポータのためのユーティリティコード¶
ソースコード: Lib/importlib/util.py
このモジュールには、 インポーター の構築を助ける様々なオブジェクトがあります。
-
importlib.util.MAGIC_NUMBER¶ バイトコードバージョン番号を表しているバイト列。バイトコードのロード/書き込みについてヘルプが必要なら
importlib.abc.SourceLoaderを参照してください。バージョン 3.4 で追加.
-
importlib.util.cache_from_source(path, debug_override=None, *, optimization=None)¶ ソース path に関連付けられたバイトコンパイルされたファイルの PEP 3147/PEP 488 パスを返します。例えば、 path が
/foo/bar/baz.pyなら、 Python 3.2 の場合返り値は/foo/bar/__pycache__/baz.cpython-32.pycになります。cpython-32という文字列は、現在のマジックタグから得られます (マジックタグについてはget_tag()を参照;sys.implementation.cache_tagが未定義ならNotImplementedErrorが送出されます。)optimization パラメータは、バイトコードファイルの最適化レベルを指定するために使われます。空文字列は最適化しないことを表します。したがって、 optimization が
''のとき/foo/bar/baz.pyに対して/foo/bar/__pycache__/baz.cpython-32.pycというバイトコードパスが返ります。Noneにするとインタープリタの最適化レベルが使われます。それ以外では値の文字列表現が使われます。したがって、 optimization が2のとき/foo/bar/baz.pyに対して/foo/bar/__pycache__/baz.cpython-32.opt-2.pycというバイトコードパスが返ります。 optimization の文字列表現は英数字だけが可能で、そうでなければValueErrorが上げられます。debug_override パラメータは deprecated で、システムの
__debug__値をオーバーライドするために使用できます。True値は optimization を空文字列に設定するのと等価です。False値は optimization を1に設定するのと同等です。もし debug_override と optimization のどちらもNone以外であればTypeErrorが上げられます。バージョン 3.4 で追加.
バージョン 3.5 で変更: optimization パラメータが追加され、 debug_override パラメータは deprecated になりました。
-
importlib.util.source_from_cache(path)¶ PEP 3147 ファイル名への path が与えられると、関連するソースコードのファイルパスを返します。例えば、 path が
/foo/bar/__pycache__/baz.cpython-32.pycなら、返されるパスは/foo/bar/baz.pyになります。 path は存在する必要はありませんが、 PEP 3147 または PEP 488 フォーマットに一致しない場合はValueErrorが送出されます。sys.implementation.cache_tagが定義されていない場合、NotImplementedErrorが送出されます。バージョン 3.4 で追加.
-
importlib.util.decode_source(source_bytes)¶ 与えられたソースコードを表すバイト列をデコードして、文字列としてそれを一般的な改行形式 (universal newlines) で返します (
importlib.abc.InspectLoader.get_source()で要求されるように)。バージョン 3.4 で追加.
-
importlib.util.resolve_name(name, package)¶ 相対的なモジュール名を解決して絶対的なものにします。
name の先頭にドットがなければ、単に name が返されます。これにより、例えば
importlib.util.resolve_name('sys', __package__)を使うときに package 変数が必要かどうかを確認する必要がなくなります。name が相対的なモジュール名であるにもかかわらず package が偽値 (例えば
Noneや空文字列) ならば、ValueErrorが送出されます。相対的な名前がそれを含むパッケージから抜け出る (例えばspamパッケージ内から..baconを要求する) 場合にもValueErrorが送出されます。バージョン 3.3 で追加.
-
importlib.util.find_spec(name, package=None)¶ モジュールの spec を、オプションで指定された package 名に対する相対で検索します。モジュールが
sys.modulesにあれば、sys.modules[name].__spec__が返されます (ただしスペックがNoneであるか設定されていなければValueErrorが送出されます)。なければ、sys.meta_pathを使った検索がなされます。スペックが見つからなければNoneが返ります。name がサブモジュールを示している (ドットを含む) 場合、親モジュールは自動的にインポートされます。
name と package は
import_module()に対するものと同じように機能します。バージョン 3.4 で追加.
-
importlib.util.module_from_spec(spec)¶ spec と
spec.loader.create_module()にもとづいて新しいモジュールを作ります。もし
spec.loader.create_module()がNoneを返さなければ、すでに存在するすべての属性はリセットされません。また、 spec にアクセスしたり属性をモジュールに設定したりする際にAttributeError例外が起きても例外は送出されません。この関数は、新しいモジュールを作る方法として
types.ModuleTypeよりも推奨されます。なぜなら、できるだけ多くのインポートコントロールされた属性をモジュールに設定するために spec が使用されるからです。バージョン 3.5 で追加.
-
@importlib.util.module_for_loader¶ ロードに使う適切なモジュールオブジェクトの選択を扱うための、
importlib.abc.Loader.load_module()への decorator です。このデコレータメソッドのシグニチャは、2 つの位置引数をとることを期待されます (例えばload_module(self, module)) 。第二引数はローダーによって使われるモジュール object になります。なお、このデコレータは 2 つの引数を想定するため、スタティックメソッドには働きません。デコレートされたメソッドは、 loader がロードしようとするモジュールの name を受け取ります。そのモジュールが
sys.modulesに見つからなければ新しいモジュールが構築されます。モジュールの出所に関わらず、__loader__は self に設定され、 (もし利用可能なら)__package__はimportlib.abc.InspectLoader.is_package()の戻り値に基づいて設定されます。これらの属性は、リロードをサポートするために無条件に設定されます。デコレートされたメソッドによって例外が送出されたとき、モジュールが
sys.modulesに加えられていたら、部分的に初期化されたモジュールがsys.modulesに残らないよう、そのモジュールは取り除かれます。モジュールが既にsys.modulesにあったなら、それは残されます。バージョン 3.3 で変更:
__loader__および__package__は (可能なら) 自動的に設定されます。バージョン 3.4 で変更: リロードをサポートするために
__name____loader____package__は無条件に設定されます。バージョン 3.4 で撤廃: インポート機構はこの関数が提供する全機能を直接実行するようになりました。
-
@importlib.util.set_loader¶ 返されたモジュールの
__loader__属性を設定する、importlib.abc.Loader.load_module()への decorator です。属性が既に設定されていたら、このデコレータは何もしません。ラップされたメソッド (すなわちself) への第一位置引数は__loader__に設定される値であると仮定されます。バージョン 3.4 で変更: もし
__loader__属性がNoneに設定されていれば、属性が存在しないかのように__loader__を設定します。バージョン 3.4 で撤廃: インポート機構はこれを自動的に考慮するようになりました。
-
@importlib.util.set_package¶ __package__属性を戻り値のモジュールに設定するための、importlib.abc.Loader.load_module()への decorator です。もし__package__が設定されていてNone以外の値を持っているなら、それは変更されません。バージョン 3.4 で撤廃: インポート機構はこれを自動的に考慮するようになりました。
-
importlib.util.spec_from_loader(name, loader, *, origin=None, is_package=None)¶ この関数は、スペックに不足している情報を埋めるために
InspectLoader.is_package()のような利用可能な loader API を使います。バージョン 3.4 で追加.
-
importlib.util.spec_from_file_location(name, location, *, loader=None, submodule_search_locations=None)¶ ファイルへのパスにもとづいて
ModuleSpecインスタンスを生成するためのファクトリー関数。不足している情報は、ローダー API を利用してスペックから得られる情報と、モジュールがファイルベースであるという暗黙的な情報によって埋められます。バージョン 3.4 で追加.
-
class
importlib.util.LazyLoader(loader)¶ モジュールが属性アクセスできるようになるまで、モジュールのローダーの実行を遅延するクラス。
このクラスは
exec_module()を定義しているローダに対して のみ 動作します。これは、モジュールに対してどのモジュールタイプが使われるかに関するコントロールが必要なためです。同様の理由で、ローダのcreate_module()メソッドは無視されます (つまり、ローダのメソッドはNoneだけを返すべきです;これはBuiltinImporterとExtensionFileLoaderを除きます)。最後に、sys.modulesにオブジェクトを代入するようなモジュールは、インタプリタ全体で安全性を保ちながらモジュール参照を適切に置き換える方法がないので、動作しないでしょう。もしそのような代入が検出されたらValueErrorが上げられます。注釈
起動時間が重要なプロジェクトでは、もし決して使われないモジュールがあれば、このクラスを使ってモジュールをロードするコストを最小化できるかもしれません。スタートアップ時間が重要でないプロジェクトでは、遅延されたロードの際に発生して文脈の外で起こるエラーメッセージのため、このクラスの使用は 著しく 推奨されません。
バージョン 3.5 で追加.
-
classmethod
factory(loader)¶ 遅延ローダを生成する callable を返すスタティックメソッド。これは、ローダーをインスタンスとしてではなくクラスとして渡すような状況において使われることを意図しています。
suffixes = importlib.machinery.SOURCE_SUFFIXES loader = importlib.machinery.SourceFileLoader lazy_loader = importlib.util.LazyLoader.factory(loader) finder = importlib.machinery.FileFinder(path, (lazy_loader, suffixes))
-
classmethod
