5. 模組引入系統
***************

一個 *module* 中的 Python 程式碼透過 *importing* 的過程來存取另一個模
組中的程式碼。"import" 陳述式是叫用 (invoke) 引入機制最常見的方法，但
這不是唯一的方法。函式如 "importlib.import_module()" 以及內建函式
"__import__()" 也可以用來叫用引入機制。

"import" 陳述式結合了兩個操作：首先搜尋指定的模組，然後將搜尋結果繫結
到本地作用域中的一個名稱。"import" 陳述式的搜尋操作被定義為一個對
"__import__()" 函式的呼叫，並帶有相應的引數。"__import__()" 的回傳值用
於執行 "import" 陳述式的名稱繫結操作。有關名稱繫結操作的詳細資訊，請參
見 "import" 陳述式。

直接呼叫 "__import__()" 只會執行模組搜尋操作，以及在找到時執行模組的建
立操作。雖然某些副作用可能會發生，例如引入父套件 (parent package)，以
及更新各種快取（包括 "sys.modules"），但只有 "import" 陳述式會執行名稱
繫結操作。

當執行 "import" 陳述式時，會呼叫內建的 "__import__()" 函式。其他叫用引
入系統的機制（如 "importlib.import_module()"）可以選擇略過
"__import__()"，並使用它們自己的解決方案來實作引入語意。

當模組首次被引入時，Python 會搜尋該模組，若找到則會建立一個模組物件
[1]，並對其進行初始化。如果找不到指定的模組，則會引發
"ModuleNotFoundError"。當引入機制被叫用時，Python 會實作各種策略來搜尋
指定的模組。這些策略可以透過使用以下章節描述的各種 hook（掛鉤）來修改
和擴展。

在 3.3 版的變更: 引入系統已被更新，以完全實作 **PEP 302** 的第二階段。
不再有隱式引入機制——完整的引入系統已透過 "sys.meta_path" 公開。此外，
原生命名空間套件支援（請參閱 **PEP 420**）也已被實作。


5.1. "importlib"
================

"importlib" 模組提供了豐富的 API 來與引入系統互動。例如，
"importlib.import_module()" 提供了一個比內建的 "__import__()" 更推薦且
更簡單的 API 來叫用引入機制。更多詳細資訊請參閱 "importlib" 函式庫文件
。


5.2. 套件
=========

Python 只有一種類型的模組物件，且所有模組，無論其是使用 Python、C 還是
其他語言實作，都是這種類型。為了幫助組織模組並提供命名階層，Python 導
入了*套件*的概念。

你可以將套件視為檔案系統中的目錄，模組則是目錄中的檔案，但不要過於字面
地理解這個比喻，因為套件和模組不一定來自檔案系統。為了方便解釋，我們將
使用這個目錄和檔案的比喻。就像檔案系統目錄一樣，套件是分層組織的，套件
本身可以包含子套件以及一般模組。

請記住，所有的套件都是模組，但並非所有模組都是套件。換句話說，套件只是
一種特殊的模組。具體來說，任何包含 "__path__" 屬性的模組都被視為套件。

所有模組都有一個名稱。子套件的名稱與其父套件名稱之間用一個點來分隔，類
似於 Python 的標準屬性存取語法。因此，你可能會有一個名為 "email" 的套
件，該套件又有一個名為 "email.mime" 的子套件，並且該子套件中有一個名為
"email.mime.text" 的模組。


5.2.1. 一般套件
---------------

Python 定義了兩種類型的套件，*一般套件*和*命名空間套件*。一般套件是
Python 3.2 及更早版本中存在的傳統套件。一般套件通常實作成一個包含
"__init__.py" 檔案的目錄。當引入一般套件時，該 "__init__.py" 檔案會被
隱式執行，其定義的物件會繫結到該套件的命名空間中的名稱。"__init__.py"
檔案可以包含與任何其他模組相同的 Python 程式碼，並且 Python 會在引入時
為該模組增加一些額外的屬性。

例如，以下檔案系統布置定義了一個頂層的 "parent" 套件，該套件包含三個子
套件：

   parent/
       __init__.py
       one/
           __init__.py
       two/
           __init__.py
       three/
           __init__.py

引入 "parent.one" 將隱式執行 "parent/__init__.py" 和
"parent/one/__init__.py"。隨後引入 "parent.two" 或 "parent.three" 將分
別執行 "parent/two/__init__.py" 和 "parent/three/__init__.py"。


5.2.2. 命名空間套件
-------------------

命名空間套件是由不同的*部分* 組成的，每個部分都為父套件提供一個子套件
。這些部分可以位於檔案系統上的不同位置。部分可能也存在於壓縮檔案中、網
路上，或 Python 在引入時搜尋的任何其他地方。命名空間套件不一定直接對應
於檔案系統中的對象；它們可能是沒有具體表示的虛擬模組。

命名空間套件的 "__path__" 屬性不使用普通的串列。它們使用自訂的可疊代型
別，當父套件的路徑（或頂層套件的 "sys.path"）發生變化時，會在下一次引
入嘗試時自動執行新一輪的套件部分搜尋。

在命名空間套件中，不存在 "parent/__init__.py" 檔案。實際上，在引入搜尋
過程中可能會找到多個 "parent" 目錄，每個目錄由不同的部分提供。因此，
"parent/one" 可能與 "parent/two" 不會實際位於一起。在這種情況下，每當
引入頂層 "parent" 套件或其子套件之一時，Python 會為頂層 "parent" 套件
建立一個命名空間套件。

有關命名空間套件的規範，請參見 **PEP 420**。


5.3. 搜尋
=========

在開始搜尋之前，Python 需要被引入模組（或套件，但在本討論中，兩者的區
別無關緊要）的完整*限定名稱 (qualified name)*。此名稱可能來自 "import"
陳述式的各種引數，或來自 "importlib.import_module()" 或 "__import__()"
函式的參數。

此名稱將在引入搜尋的各個階段中使用，並且它可能是指向子模組的點分隔路徑
，例如 "foo.bar.baz"。在這種情況下，Python 會首先嘗試引入 "foo"，然後
是 "foo.bar"，最後是 "foo.bar.baz"。如果任何中間引入失敗，則會引發
"ModuleNotFoundError"。


5.3.1. 模組快取
---------------

在引入搜尋過程中首先檢查的地方是 "sys.modules"。此對映用作所有先前引入
過的模組的快取，包括中間路徑。因此，如果 "foo.bar.baz" 之前已被引入，
"sys.modules" 將包含 "foo"、"foo.bar" 和 "foo.bar.baz" 的條目。每個鍵
的值都是相應的模組物件。

在引入過程中，會在 "sys.modules" 中查找模組名稱，如果存在，則相關的值
為滿足此引入的模組，此引入過程即完成。然而，如果值是 "None"，則會引發
"ModuleNotFoundError"。如果模組名稱不存在，Python 會繼續搜尋該模組。

"sys.modules" 是可寫入的。刪除一個鍵可能不會銷毀相關聯的模組（因為其他
模組可能持有對它的參照），但會使指定的模組的快取條目失效，導致 Python
在下一次引入該模組時重新搜尋。也可以將鍵賦值為 "None"，這會強制下一次
引入該模組時引發 "ModuleNotFoundError"。

但請注意，如果你保留了對模組物件的參照，並在 "sys.modules" 中使其快取
條目失效，然後重新引入指定的模組，這兩個模組物件將*不會*相同。相比之下
，"importlib.reload()" 會重用*相同的*模組物件，並透過重新執行模組的程
式碼來簡單地重新初始化模組內容。


5.3.2. 尋檢器 (Finder) 與載入器 (Loader)
----------------------------------------

如果在 "sys.modules" 中找不到指定的模組，則會叫用 Python 的引入協定來
尋找並載入該模組。這個協定由兩個概念性物件組成，*尋檢器* 和*載入器*。
尋檢器的任務是使用其已知的策略來確定是否能找到命名模組。實作這兩個介面
的物件稱為*引入器 (importer)* ——當它們發現可以載入所請求的模組時，會回
傳它們自己。

Python 包含多個預設的尋檢器和引入器。第一個尋檢器知道如何定位內建模組
，第二個尋檢器知道如何定位凍結模組。第三個預設尋檢器會在 *import path*
中搜尋模組。*import path* 是一個位置的列表，這些位置可能是檔案系統路徑
或壓縮檔案，也可以擴展以搜尋任何可定位的資源，例如由 URL 識別的資源。

引入機制是可擴展的，因此可以增加新的尋檢器來擴展模組搜尋的範圍和作用域
。

尋檢器實際上不會載入模組。如果它們能找到指定的模組，它們會回傳一個*模
組規格*，這是一個模組的引入相關資訊的封裝，引入機制會在載入模組時使用
這些資訊。

以下各節將更詳細地描述尋檢器和載入器的協定，包括如何建立和註冊新的尋檢
器和載入器來擴展引入機制。

在 3.4 版的變更: Python 在之前的版本中，尋檢器會直接回傳*載入器*，而現
在它們回傳的是*包含*載入器的模組規格。載入器仍在引入過程中使用，但其責
任減少了。


5.3.3. 引入掛鉤 (Import hooks)
------------------------------

引入機制的設計是可擴展的；其主要機制是*引入掛鉤*。引入掛鉤有兩種類型：
*元掛鉤 (meta hooks)* 和*引入路徑掛鉤*。

元掛鉤會在引入處理的開始階段被呼叫，除了查找 "sys.modules" 快取外，其
他引入處理還未發生時就會呼叫。這允許元掛鉤覆蓋 "sys.path" 的處理、凍結
模組，甚至是內建模組。元掛鉤透過將新的尋檢器物件添加到 "sys.meta_path"
中來註冊，具體描述請參閱以下段落。

引入路徑掛鉤被視為 "sys.path"（或 "package.__path__"）處理過程的一部分
來呼叫，當遇到與其相關聯的路徑項目時就會被觸發。引入路徑掛鉤透過將新的
可呼叫對象增加到 "sys.path_hooks" 中來註冊，具體描述請參閱以下段落。


5.3.4. 元路徑
-------------

當在 "sys.modules" 中找不到命名模組時，Python 接下來會搜尋
"sys.meta_path"，其中包含一個元路徑尋檢器物件串列。這些尋檢器會依次被
查詢，看它們是否知道如何處理命名模組。元路徑尋檢器必須實作一個名為
"find_spec()" 的方法，該方法接收三個引數：名稱、引入路徑和（可選的）目
標模組。元路徑尋檢器可以使用任何策略來確定它是否能處理命名模組。

如果元路徑尋檢器知道如何處理命名模組，它會回傳一個規格物件。如果它無法
處理命名模組，則回傳 "None"。如果 "sys.meta_path" 的處理到達串列的末尾
仍未回傳規格，則會引發 "ModuleNotFoundError"。任何其他引發的例外將直接
向上傳播，並中止引入過程。

元路徑尋檢器的 "find_spec()" 方法會以兩個或三個引數來呼叫。第一個是被
引入模組的完全限定名稱，例如 "foo.bar.baz"。第二個引數是用於模組搜尋的
路徑條目。對於頂層模組，第二個引數是 "None"，但對於子模組或子套件，第
二個引數是父套件的 "__path__" 屬性的值。如果無法存取相應的 "__path__"
屬性，將引發 "ModuleNotFoundError"。第三個引數是一個現有的模組物件，該
物件將成為後續載入的目標。引入系統只會在重新載入時傳入目標模組。

對於一個引入請求，元路徑可能會被遍歷多次。例如，假設參與的模組都沒有被
快取，則引入 "foo.bar.baz" 將首先執行頂層引入，對每個元路徑尋檢器（
"mpf"）呼叫 "mpf.find_spec("foo", None, None)"。當 "foo" 被引入後，將
再次藉由遍歷元路徑引入 "foo.bar"，並呼叫 "mpf.find_spec("foo.bar",
foo.__path__, None)"。當 "foo.bar" 被引入後，最後一次遍歷會呼叫
"mpf.find_spec("foo.bar.baz", foo.bar.__path__, None)"。

一些元路徑尋檢器僅支援頂層引入。當第二個引數傳入 "None" 以外的值時，這
些引入器將始終回傳 "None"。

Python 的預設 "sys.meta_path" 有三個元路徑尋檢器，一個知道如何引入內建
模組，一個知道如何引入凍結模組，還有一個知道如何從 *import path* 引入
模組（即 *path based finder*）。

在 3.4 版的變更: 元路徑尋檢器的 "find_spec()" 方法取代了
"find_module()"，後者現在已被棄用。雖然它將繼續正常工作，但引入機制僅
在尋檢器未實作 "find_spec()" 時才會嘗試使用它。

在 3.10 版的變更: 引入系統現在使用 "find_module()" 時將引發
"ImportWarning"。

在 3.12 版的變更: "find_module()" 已被移除。請改用 "find_spec()"。


5.4. 載入
=========

如果找到模組規格，引入機制會在載入模組時使用該規格（以及它包含的載入器
）。以下是引入過程中載入部分的大致情況：

   module = None
   if spec.loader is not None and hasattr(spec.loader, 'create_module'):
       # 這裡假設載入器上也會定義 'exec_module'
       module = spec.loader.create_module(spec)
   if module is None:
       module = ModuleType(spec.name)
   # 與引入相關的模組屬性會在此處設定：
   _init_module_attrs(spec, module)

   if spec.loader is None:
       # 不支援
       raise ImportError
   if spec.origin is None and spec.submodule_search_locations is not None:
       # 命名空間套件
       sys.modules[spec.name] = module
   elif not hasattr(spec.loader, 'exec_module'):
       module = spec.loader.load_module(spec.name)
   else:
       sys.modules[spec.name] = module
       try:
           spec.loader.exec_module(module)
       except BaseException:
           try:
               del sys.modules[spec.name]
           except KeyError:
               pass
           raise
   return sys.modules[spec.name]

請注意下列細節：

* 如果 "sys.modules" 中已存在具有給定名稱的模組物件，引入會已回傳該物
  件。

* 在載入器執行模組程式碼之前，模組將已存在於 "sys.modules" 中。這一點
  至關重要，因為模組程式碼可能會（直接或間接）引入自己；事先將其增加到
  "sys.modules" 可以預防類似無限遞迴以及多次重複載入等情形。

* 如果載入失敗，只有載入失敗的模組會從 "sys.modules" 中刪除。任何已存
  在於 "sys.modules" 快取中的模組，以及任何在載入失敗前成功載入的模組
  ，都必須保留在快取中。此情形與重新載入不同，在重新載入時，即使載入失
  敗的模組也會保留在 "sys.modules" 中。

* 模組建立後、在執行之前，引入機制會設置與引入相關的模組屬性（在上面的
  偽程式碼範例中為 "_init_module_attrs"），具體內容在之後的段落會總結
  。

* 模組執行是載入過程中的關鍵時刻，此時模組的命名空間會被新增名稱。執行
  過程完全交由載入器處理，由其決定如何新增以及新增什麼。

* 在載入過程中建立並傳遞給 exec_module() 的模組，可能不會是引入結束時
  回傳的模組 [2]。

在 3.4 版的變更: 引入系統已接管載入器的模板 (boilerplate) 責任。之前是
由 "importlib.abc.Loader.load_module()" 方法執行的。


5.4.1. 載入器
-------------

模組載入器提供了載入的關鍵功能：模組執行。引入機制會以單一引數（即要執
行的模組物件）呼叫 "importlib.abc.Loader.exec_module()" 方法。任何從
"exec_module()" 回傳的值都會被忽略。

載入器必須滿足以下要求：

* 如果模組是 Python 模組（而非內建模組或動態載入的擴充），載入器應在模
  組的全域命名空間 ("module.__dict__") 中執行該模組的程式碼。

* 如果載入器無法執行該模組，應引發 "ImportError"。不過，在
  "exec_module()" 中引發的任何其他例外也會被傳播。

在許多情況下，尋檢器和載入器可以是同一個物件；在這種情況下，
"find_spec()" 方法只需回傳一個載入器設為 "self" 的規格即可。

模組載入器可以選擇透過實作 "create_module()" 方法，在載入過程中建立模
組物件。該方法接受一個引數，即模組規格，並回傳在載入過程中要使用的新的
模組物件。"create_module()" 不需要在模組物件上設定任何屬性。如果該方法
回傳 "None"，引入機制將自行建立新的模組。

在 3.4 版被加入: 載入器的 "create_module()" 方法。

在 3.4 版的變更: "load_module()" 方法已被 "exec_module()" 取代，引入機
制已承擔所有載入的模板責任。為了與現有的載入器相容，引入機制會在載入器
未實作 "exec_module()" 且存在 "load_module()" 方法時使用該方法。然而，
"load_module()" 已被棄用，載入器應改為實作 "exec_module()"。
"load_module()" 方法除了執行模組外，還必須實作上述全部的模板載入功能。
所有相同的限制依然適用，並且還有一些額外的說明：

* 如果 "sys.modules" 中已存在具有給定名稱的模組物件，載入器必須使用該
  模組（否則 "importlib.reload()" 將無法正常運作）。如果命名模組不存在
  於 "sys.modules" 中，載入器必須建立一個新的模組物件並將其新增至
  "sys.modules"。

* 在載入器執行模組程式碼之前，該模組*必須*已存在於 "sys.modules" 中，
  以防止無限遞迴或多次載入。

* 如果載入失敗，載入器必須移除已經插入到 "sys.modules" 中的任何模組，
  但**只能**移除失敗的模組（們），且僅在載入器本身明確載入這些模組時才
  需移除。

在 3.5 版的變更: 當 "exec_module()" 已定義但未定義 "create_module()"
時，將引發 "DeprecationWarning"。

在 3.6 版的變更: 當 "exec_module()" 已定義但未定義 "create_module()"
時，將引發 "ImportError"。

在 3.10 版的變更: 使用 "load_module()" 將引發 "ImportWarning"。


5.4.2. 子模組
-------------

當使用任何機制（例如 "importlib" APIs、"import" 或 "import-from" 陳述
式，或內建的 "__import__()"）載入子模組時，會將子模組物件繫結到父模組
的命名空間中。例如，如果套件 "spam" 有一個子模組 "foo"，則在引入
"spam.foo" 之後，"spam" 將擁有一個名為 "foo" 的屬性，該屬性繫結到子模
組。我們假設你有以下的目錄結構：

   spam/
       __init__.py
       foo.py

並且 "spam/__init__.py" 中包含以下程式碼：

   from .foo import Foo

那麼執行以下程式碼會將 "foo" 和 "Foo" 的名稱繫結到 "spam" 模組中：

   >>> import spam
   >>> spam.foo
   <module 'spam.foo' from '/tmp/imports/spam/foo.py'>
   >>> spam.Foo
   <class 'spam.foo.Foo'>

鑑於 Python 相似的名稱繫結規則，這可能看起來有些出人意料，但這實際上是
引入系統的一個基本特性。不變的是如果你擁有 "sys.modules['spam']" 和
"sys.modules['spam.foo']"（就像上述引入後那樣），那麼後者必須作為前者
的 "foo" 屬性出現。


5.4.3. 模組規格
---------------

引入機制在引入過程中使用有關每個模組的各種資訊，尤其是在載入之前。大多
數資訊對所有模組來說都是通用的。模組規格的目的是以每個模組為基礎封裝這
些與引入相關的資訊。

在引入過程中使用規格允許在引入系統的各個組件之間傳遞狀態，例如在建立模
組規格的尋檢器和執行該規格的載入器之間傳遞。最重要的是，這允許引入機制
執行載入的模板操作，而在沒有模組規格的情況下，這些操作則是載入器的責任
。

模組的規格以 "module.__spec__" 的形式公開。適當地設定 "__spec__" 同樣
適用於在直譯器啟動期間初始化的模組。唯一的例外是 "__main__"，其中
"__spec__" 會在某些情況下被設定成 None。

有關模組規格內容的詳細資訊，請參閱 "ModuleSpec"。

在 3.4 版被加入.


5.4.4. __path__ attributes on modules
-------------------------------------

The "__path__" attribute should be a (possibly empty) *sequence* of
strings enumerating the locations where the package's submodules will
be found. By definition, if a module has a "__path__" attribute, it is
a *package*.

A package's "__path__" attribute is used during imports of its
subpackages. Within the import machinery, it functions much the same
as "sys.path", i.e. providing a list of locations to search for
modules during import. However, "__path__" is typically much more
constrained than "sys.path".

The same rules used for "sys.path" also apply to a package's
"__path__". "sys.path_hooks" (described below) are consulted when
traversing a package's "__path__".

A package's "__init__.py" file may set or alter the package's
"__path__" attribute, and this was typically the way namespace
packages were implemented prior to **PEP 420**.  With the adoption of
**PEP 420**, namespace packages no longer need to supply "__init__.py"
files containing only "__path__" manipulation code; the import
machinery automatically sets "__path__" correctly for the namespace
package.


5.4.5. Module reprs
-------------------

By default, all modules have a usable repr, however depending on the
attributes set above, and in the module's spec, you can more
explicitly control the repr of module objects.

If the module has a spec ("__spec__"), the import machinery will try
to generate a repr from it.  If that fails or there is no spec, the
import system will craft a default repr using whatever information is
available on the module.  It will try to use the "module.__name__",
"module.__file__", and "module.__loader__" as input into the repr,
with defaults for whatever information is missing.

Here are the exact rules used:

* If the module has a "__spec__" attribute, the information in the
  spec is used to generate the repr.  The "name", "loader", "origin",
  and "has_location" attributes are consulted.

* If the module has a "__file__" attribute, this is used as part of
  the module's repr.

* If the module has no "__file__" but does have a "__loader__" that is
  not "None", then the loader's repr is used as part of the module's
  repr.

* Otherwise, just use the module's "__name__" in the repr.

在 3.12 版的變更: Use of "module_repr()", having been deprecated since
Python 3.4, was removed in Python 3.12 and is no longer called during
the resolution of a module's repr.


5.4.6. Cached bytecode invalidation
-----------------------------------

Before Python loads cached bytecode from a ".pyc" file, it checks
whether the cache is up-to-date with the source ".py" file. By
default, Python does this by storing the source's last-modified
timestamp and size in the cache file when writing it. At runtime, the
import system then validates the cache file by checking the stored
metadata in the cache file against the source's metadata.

Python also supports "hash-based" cache files, which store a hash of
the source file's contents rather than its metadata. There are two
variants of hash-based ".pyc" files: checked and unchecked. For
checked hash-based ".pyc" files, Python validates the cache file by
hashing the source file and comparing the resulting hash with the hash
in the cache file. If a checked hash-based cache file is found to be
invalid, Python regenerates it and writes a new checked hash-based
cache file. For unchecked hash-based ".pyc" files, Python simply
assumes the cache file is valid if it exists. Hash-based ".pyc" files
validation behavior may be overridden with the "--check-hash-based-
pycs" flag.

在 3.7 版的變更: Added hash-based ".pyc" files. Previously, Python
only supported timestamp-based invalidation of bytecode caches.


5.5. The Path Based Finder
==========================

As mentioned previously, Python comes with several default meta path
finders. One of these, called the *path based finder* ("PathFinder"),
searches an *import path*, which contains a list of *path entries*.
Each path entry names a location to search for modules.

The path based finder itself doesn't know how to import anything.
Instead, it traverses the individual path entries, associating each of
them with a path entry finder that knows how to handle that particular
kind of path.

The default set of path entry finders implement all the semantics for
finding modules on the file system, handling special file types such
as Python source code (".py" files), Python byte code (".pyc" files)
and shared libraries (e.g. ".so" files). When supported by the
"zipimport" module in the standard library, the default path entry
finders also handle loading all of these file types (other than shared
libraries) from zipfiles.

Path entries need not be limited to file system locations.  They can
refer to URLs, database queries, or any other location that can be
specified as a string.

The path based finder provides additional hooks and protocols so that
you can extend and customize the types of searchable path entries.
For example, if you wanted to support path entries as network URLs,
you could write a hook that implements HTTP semantics to find modules
on the web.  This hook (a callable) would return a *path entry finder*
supporting the protocol described below, which was then used to get a
loader for the module from the web.

A word of warning: this section and the previous both use the term
*finder*, distinguishing between them by using the terms *meta path
finder* and *path entry finder*.  These two types of finders are very
similar, support similar protocols, and function in similar ways
during the import process, but it's important to keep in mind that
they are subtly different. In particular, meta path finders operate at
the beginning of the import process, as keyed off the "sys.meta_path"
traversal.

By contrast, path entry finders are in a sense an implementation
detail of the path based finder, and in fact, if the path based finder
were to be removed from "sys.meta_path", none of the path entry finder
semantics would be invoked.


5.5.1. Path entry finders
-------------------------

The *path based finder* is responsible for finding and loading Python
modules and packages whose location is specified with a string *path
entry*.  Most path entries name locations in the file system, but they
need not be limited to this.

As a meta path finder, the *path based finder* implements the
"find_spec()" protocol previously described, however it exposes
additional hooks that can be used to customize how modules are found
and loaded from the *import path*.

Three variables are used by the *path based finder*, "sys.path",
"sys.path_hooks" and "sys.path_importer_cache".  The "__path__"
attributes on package objects are also used.  These provide additional
ways that the import machinery can be customized.

"sys.path" contains a list of strings providing search locations for
modules and packages.  It is initialized from the "PYTHONPATH"
environment variable and various other installation- and
implementation-specific defaults.  Entries in "sys.path" can name
directories on the file system, zip files, and potentially other
"locations" (see the "site" module) that should be searched for
modules, such as URLs, or database queries.  Only strings should be
present on "sys.path"; all other data types are ignored.

The *path based finder* is a *meta path finder*, so the import
machinery begins the *import path* search by calling the path based
finder's "find_spec()" method as described previously.  When the
"path" argument to "find_spec()" is given, it will be a list of string
paths to traverse - typically a package's "__path__" attribute for an
import within that package.  If the "path" argument is "None", this
indicates a top level import and "sys.path" is used.

The path based finder iterates over every entry in the search path,
and for each of these, looks for an appropriate *path entry finder*
("PathEntryFinder") for the path entry.  Because this can be an
expensive operation (e.g. there may be "stat()" call overheads for
this search), the path based finder maintains a cache mapping path
entries to path entry finders.  This cache is maintained in
"sys.path_importer_cache" (despite the name, this cache actually
stores finder objects rather than being limited to *importer*
objects). In this way, the expensive search for a particular *path
entry* location's *path entry finder* need only be done once.  User
code is free to remove cache entries from "sys.path_importer_cache"
forcing the path based finder to perform the path entry search again.

If the path entry is not present in the cache, the path based finder
iterates over every callable in "sys.path_hooks".  Each of the *path
entry hooks* in this list is called with a single argument, the path
entry to be searched.  This callable may either return a *path entry
finder* that can handle the path entry, or it may raise "ImportError".
An "ImportError" is used by the path based finder to signal that the
hook cannot find a *path entry finder* for that *path entry*.  The
exception is ignored and *import path* iteration continues.  The hook
should expect either a string or bytes object; the encoding of bytes
objects is up to the hook (e.g. it may be a file system encoding,
UTF-8, or something else), and if the hook cannot decode the argument,
it should raise "ImportError".

If "sys.path_hooks" iteration ends with no *path entry finder* being
returned, then the path based finder's "find_spec()" method will store
"None" in "sys.path_importer_cache" (to indicate that there is no
finder for this path entry) and return "None", indicating that this
*meta path finder* could not find the module.

If a *path entry finder* *is* returned by one of the *path entry hook*
callables on "sys.path_hooks", then the following protocol is used to
ask the finder for a module spec, which is then used when loading the
module.

The current working directory -- denoted by an empty string -- is
handled slightly differently from other entries on "sys.path". First,
if the current working directory cannot be determined or is found not
to exist, no value is stored in "sys.path_importer_cache". Second, the
value for the current working directory is looked up fresh for each
module lookup. Third, the path used for "sys.path_importer_cache" and
returned by "importlib.machinery.PathFinder.find_spec()" will be the
actual current working directory and not the empty string.


5.5.2. Path entry finder protocol
---------------------------------

In order to support imports of modules and initialized packages and
also to contribute portions to namespace packages, path entry finders
must implement the "find_spec()" method.

"find_spec()" takes two arguments: the fully qualified name of the
module being imported, and the (optional) target module.
"find_spec()" returns a fully populated spec for the module. This spec
will always have "loader" set (with one exception).

To indicate to the import machinery that the spec represents a
namespace *portion*, the path entry finder sets
"submodule_search_locations" to a list containing the portion.

在 3.4 版的變更: "find_spec()" replaced "find_loader()" and
"find_module()", both of which are now deprecated, but will be used if
"find_spec()" is not defined.Older path entry finders may implement
one of these two deprecated methods instead of "find_spec()".  The
methods are still respected for the sake of backward compatibility.
However, if "find_spec()" is implemented on the path entry finder, the
legacy methods are ignored."find_loader()" takes one argument, the
fully qualified name of the module being imported.  "find_loader()"
returns a 2-tuple where the first item is the loader and the second
item is a namespace *portion*.For backwards compatibility with other
implementations of the import protocol, many path entry finders also
support the same, traditional "find_module()" method that meta path
finders support. However path entry finder "find_module()" methods are
never called with a "path" argument (they are expected to record the
appropriate path information from the initial call to the path
hook).The "find_module()" method on path entry finders is deprecated,
as it does not allow the path entry finder to contribute portions to
namespace packages.  If both "find_loader()" and "find_module()" exist
on a path entry finder, the import system will always call
"find_loader()" in preference to "find_module()".

在 3.10 版的變更: Calls to "find_module()" and "find_loader()" by the
import system will raise "ImportWarning".

在 3.12 版的變更: "find_module()" 和 "find_loader()" 已被移除。


5.6. Replacing the standard import system
=========================================

The most reliable mechanism for replacing the entire import system is
to delete the default contents of "sys.meta_path", replacing them
entirely with a custom meta path hook.

If it is acceptable to only alter the behaviour of import statements
without affecting other APIs that access the import system, then
replacing the builtin "__import__()" function may be sufficient.

To selectively prevent the import of some modules from a hook early on
the meta path (rather than disabling the standard import system
entirely), it is sufficient to raise "ModuleNotFoundError" directly
from "find_spec()" instead of returning "None". The latter indicates
that the meta path search should continue, while raising an exception
terminates it immediately.


5.7. Package Relative Imports
=============================

Relative imports use leading dots. A single leading dot indicates a
relative import, starting with the current package. Two or more
leading dots indicate a relative import to the parent(s) of the
current package, one level per dot after the first. For example, given
the following package layout:

   package/
       __init__.py
       subpackage1/
           __init__.py
           moduleX.py
           moduleY.py
       subpackage2/
           __init__.py
           moduleZ.py
       moduleA.py

In either "subpackage1/moduleX.py" or "subpackage1/__init__.py", the
following are valid relative imports:

   from .moduleY import spam
   from .moduleY import spam as ham
   from . import moduleY
   from ..subpackage1 import moduleY
   from ..subpackage2.moduleZ import eggs
   from ..moduleA import foo

Absolute imports may use either the "import <>" or "from <> import <>"
syntax, but relative imports may only use the second form; the reason
for this is that:

   import XXX.YYY.ZZZ

should expose "XXX.YYY.ZZZ" as a usable expression, but .moduleY is
not a valid expression.


5.8. Special considerations for __main__
========================================

The "__main__" module is a special case relative to Python's import
system.  As noted elsewhere, the "__main__" module is directly
initialized at interpreter startup, much like "sys" and "builtins".
However, unlike those two, it doesn't strictly qualify as a built-in
module.  This is because the manner in which "__main__" is initialized
depends on the flags and other options with which the interpreter is
invoked.


5.8.1. __main__.__spec__
------------------------

Depending on how "__main__" is initialized, "__main__.__spec__" gets
set appropriately or to "None".

When Python is started with the "-m" option, "__spec__" is set to the
module spec of the corresponding module or package. "__spec__" is also
populated when the "__main__" module is loaded as part of executing a
directory, zipfile or other "sys.path" entry.

In the remaining cases "__main__.__spec__" is set to "None", as the
code used to populate the "__main__" does not correspond directly with
an importable module:

* interactive prompt

* "-c" 選項

* running from stdin

* running directly from a source or bytecode file

Note that "__main__.__spec__" is always "None" in the last case, *even
if* the file could technically be imported directly as a module
instead. Use the "-m" switch if valid module metadata is desired in
"__main__".

Note also that even when "__main__" corresponds with an importable
module and "__main__.__spec__" is set accordingly, they're still
considered *distinct* modules. This is due to the fact that blocks
guarded by "if __name__ == "__main__":" checks only execute when the
module is used to populate the "__main__" namespace, and not during
normal import.


5.9. References
===============

The import machinery has evolved considerably since Python's early
days.  The original specification for packages is still available to
read, although some details have changed since the writing of that
document.

The original specification for "sys.meta_path" was **PEP 302**, with
subsequent extension in **PEP 420**.

**PEP 420** introduced *namespace packages* for Python 3.3.  **PEP
420** also introduced the "find_loader()" protocol as an alternative
to "find_module()".

**PEP 366** describes the addition of the "__package__" attribute for
explicit relative imports in main modules.

**PEP 328** introduced absolute and explicit relative imports and
initially proposed "__name__" for semantics **PEP 366** would
eventually specify for "__package__".

**PEP 338** defines executing modules as scripts.

**PEP 451** adds the encapsulation of per-module import state in spec
objects.  It also off-loads most of the boilerplate responsibilities
of loaders back onto the import machinery.  These changes allow the
deprecation of several APIs in the import system and also addition of
new methods to finders and loaders.

-[ 註解 ]-

[1] 參閱 "types.ModuleType"。

[2] The importlib implementation avoids using the return value
    directly. Instead, it gets the module object by looking the module
    name up in "sys.modules".  The indirect effect of this is that an
    imported module may replace itself in "sys.modules".  This is
    implementation-specific behavior that is not guaranteed to work in
    other Python implementations.
