5.2.1.一般套件¶

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

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

parent/__init__.pyone/__init__.pytwo/__init__.pythree/__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.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 識別的資源。

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

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

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

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）。

5.4.1.載入器¶

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

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

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

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

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

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

5.4.2.子模組¶

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

spam/__init__.pyfoo.py

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

from.fooimportFoo

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

>>>importspam>>>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。

5.4.4.__path__ attributes on modules¶

The__path__ attribute should be a (possibly empty)sequence of strings enumerating the locations where the package'ssubmodules will be found. By definition, if a module has a__path__attribute, it is apackage.

A package's__path__ attribute is used during imports of itssubpackages.Within the import machinery, it functions much the same assys.path,i.e. providing a list of locations to search for modules during import.However,__path__ is typically much more constrained thansys.path.

The same rules used forsys.path also apply to a package's__path__.sys.path_hooks (described below) areconsulted 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 implementedprior toPEP 420. With the adoption ofPEP 420, namespace packages nolonger 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 theattributes set above, and in the module's spec, you can more explicitlycontrol the repr of module objects.

If the module has a spec (__spec__), the import machinery will tryto generate a repr from it. If that fails or there is no spec, the importsystem will craft a default repr using whatever information is availableon the module. It will try to use themodule.__name__,module.__file__, andmodule.__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 specis 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 themodule's repr.

• If the module has no__file__ but does have a__loader__ that is notNone, then the loader's repr is used as part of the module's repr.

• Otherwise, just use the module's__name__ in the repr.

5.4.6.Cached bytecode invalidation¶

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

Python also supports "hash-based" cache files, which store a hash of the sourcefile'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 theresulting hash with the hash in the cache file. If a checked hash-based cachefile is found to be invalid, Python regenerates it and writes a new checkedhash-based cache file. For unchecked hash-based.pyc files, Python simplyassumes the cache file is valid if it exists. Hash-based.pyc filesvalidation behavior may be overridden with the--check-hash-based-pycsflag.

5.5.1.Path entry finders¶

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

As a meta path finder, thepath based finder implements thefind_spec() protocol previouslydescribed, however it exposes additional hooks that can be used tocustomize how modules are found and loaded from theimport path.

Three variables are used by thepath based finder,sys.path,sys.path_hooks andsys.path_importer_cache. The__path__attributes on package objects are also used. These provide additional waysthat the import machinery can be customized.

sys.path contains a list of strings providing search locations formodules and packages. It is initialized from thePYTHONPATHenvironment variable and various other installation- andimplementation-specific defaults. Entries insys.path can namedirectories on the file system, zip files, and potentially other "locations"(see thesite module) that should be searched for modules, such asURLs, or database queries. Only strings should be present onsys.path; all other data types are ignored.

Thepath based finder is ameta path finder, so the importmachinery begins theimport path search by calling the pathbased finder'sfind_spec() method asdescribed previously. When thepath argument tofind_spec() is given, it will be alist of string paths to traverse - typically a package's__path__attribute for an import within that package. If thepath argument isNone, this indicates a top level import andsys.path is used.

The path based finder iterates over every entry in the search path, andfor each of these, looks for an appropriatepath entry finder(PathEntryFinder) for thepath entry. Because this can be an expensive operation (e.g. there may bestat() call overheads for this search), the path based finder maintainsa cache mapping path entries to path entry finders. This cache is maintainedinsys.path_importer_cache (despite the name, this cache actuallystores finder objects rather than being limited toimporter objects).In this way, the expensive search for a particularpath entrylocation'spath entry finder need only be done once. User code isfree to remove cache entries fromsys.path_importer_cache forcingthe path based finder to perform the path entry search again.

If the path entry is not present in the cache, the path based finder iteratesover every callable insys.path_hooks. Each of thepath entryhooks in this list is called with a single argument, thepath entry to be searched. This callable may either return apathentry finder that can handle the path entry, or it may raiseImportError. AnImportError is used by the path based finder tosignal that the hook cannot find apath entry finderfor thatpath entry. Theexception is ignored andimport path iteration continues. The hookshould expect either a string or bytes object; the encoding of bytes objectsis up to the hook (e.g. it may be a file system encoding, UTF-8, or somethingelse), and if the hook cannot decode the argument, it should raiseImportError.

Ifsys.path_hooks iteration ends with nopath entry finderbeing returned, then the path based finder'sfind_spec() method will storeNoneinsys.path_importer_cache (to indicate that there is no finder forthis path entry) and returnNone, indicating that thismeta path finder could not find the module.

If apath entry finderis returned by one of thepath entryhook callables onsys.path_hooks, then the following protocol is usedto ask the finder for a module spec, which is then used when loading themodule.

The current working directory -- denoted by an empty string -- is handledslightly differently from other entries onsys.path. First, if thecurrent working directory is found to not exist, no value is stored insys.path_importer_cache. Second, the value for the current workingdirectory is looked up fresh for each module lookup. Third, the path used forsys.path_importer_cache and returned byimportlib.machinery.PathFinder.find_spec() will be the actual currentworking 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 tocontribute portions to namespace packages, path entry finders must implementthefind_spec() method.

find_spec() takes two arguments: thefully qualified name of the module being imported, and the (optional) targetmodule.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 namespaceportion, the path entry finder setssubmodule_search_locations toa list containing the portion.

5.8.1.__main__.__spec__¶

Depending on how__main__ is initialized,__main__.__spec__gets set appropriately or toNone.

When Python is started with the-m option,__spec__ is setto the module spec of the corresponding module or package.__spec__ isalso populated when the__main__ module is loaded as part of executing adirectory, zipfile or othersys.path entry.

Inthe remaining cases__main__.__spec__ is set toNone, 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 alwaysNone in the last case,even if the file could technically be imported directly as a moduleinstead. Use the-m switch if valid module metadata is desiredin__main__.

Note also that even when__main__ corresponds with an importable moduleand__main__.__spec__ is set accordingly, they're still considereddistinct modules. This is due to the fact that blocks guarded byif__name__=="__main__": checks only execute when the module is usedto populate the__main__ namespace, and not during normal import.