一个思想实验

让我们短暂地乘坐时光机回到过去，假设我们回到了 1990 年代初期，在 Python 包和__init__.py 发明之前。但是，假设我们确实熟悉类似 Perl 的包导入，并且我们想在 Python 中实现类似的系统。

我们仍然可以使用 Python 的模块导入作为基础，因此我们当然可以设想将Foo.py 作为Foo 包的父Foo 模块。但是我们如何实现子模块和子包导入呢？

好吧，如果我们还没有 __path__ 属性的概念，我们可能会直接搜索 sys.path 来查找 Foo/Bar.py。

但我们**只有**在有人实际尝试导入 Foo.Bar 时才会这样做。

而不是在他们导入 Foo 时。

而**这**让我们能够摆脱 2011 年这里删除 __init__ 要求带来的向后兼容性问题。

怎么做到的呢？

当我们 import Foo 时，我们甚至**不查找** sys.path 上的 Foo/ 目录，因为我们**还不关心**。我们唯一关心的时候，是有人尝试实际导入 Foo 的子模块或子包的时候。

这意味着，如果 Foo 是一个标准库模块（例如），而我碰巧在 sys.path 上有一个 Foo 目录（当然，没有 __init__.py），那么**没有任何问题**。 Foo 模块仍然只是一个模块，并且仍然可以正常导入。

自包含与“虚拟”包

当然，在今天的 Python 中，如果 Foo 只是一个 Foo.py 模块（因此缺少 __path__ 属性），那么尝试 import Foo.Bar 会失败。

因此，这个 PEP 建议在缺少 __path__ 的情况下**动态**创建它。

也就是说，如果我尝试 import Foo.Bar，对导入机制的提议更改将注意到 Foo 模块缺少 __path__，因此会在继续之前尝试**构建**它。

它会通过列出 sys.path 中列出的所有目录中现有的所有 Foo/ 子目录来做到这一点。

如果列表为空，则导入将以 ImportError 失败，就像今天一样。但如果列表**不**为空，则将其保存在新的 Foo.__path__ 属性中，使该模块成为“虚拟包”。

也就是说，因为它现在具有有效的 __path__，所以我们可以以正常方式继续导入子模块或子包。

现在，请注意，此更改不会影响包含 __init__ 模块的“经典”自包含包。此类包已经**拥有** __path__ 属性（在导入时初始化），因此导入机制不会尝试稍后创建另一个属性。

这意味着（例如），标准库 email 包不会受到您在 sys.path 上拥有大量名为 email 的无关目录的任何影响。（即使它们包含 *.py 文件。）

但它**确实**意味着，如果您想将 Foo 模块转换为 Foo 包，您只需在 sys.path 上的某个位置添加一个 Foo/ 目录，然后开始向其中添加模块即可。

但是，如果您只需要一个“命名空间包”怎么办？也就是说，一个**仅**作为各种单独分发的子模块和子包的命名空间的包？

例如，如果您是 Zope 公司，分发数十种单独的工具，例如 zc.buildout，每个工具都在 zc 命名空间下的包中，您不希望必须在您发布的每个工具中创建和包含一个空的 zc.py。（而且，如果您是 Linux 或其他操作系统供应商，您不希望处理尝试将十个 zc.py 的副本安装到同一位置而导致的包安装冲突！）

没问题。我们只需对导入过程进行一次较小的调整：如果“经典”导入过程未能找到自包含模块或包（例如，如果 import zc 找不到 zc.py 或 zc/__init__.py），那么我们再次尝试通过搜索 sys.path 上的所有 zc/ 目录并将其放入列表中来构建 __path__。

如果此列表为空，则我们引发 ImportError。但如果它不为空，我们创建一个空的 zc 模块，并将列表放入 zc.__path__ 中。恭喜：zc 现在是一个仅命名空间的“纯虚拟”包！它没有模块内容，但您仍然可以从中导入子模块和子包，无论它们位于 sys.path 的哪个位置。

（顺便说一句，这两个添加到导入协议中的内容（即动态添加的 __path__ 和动态创建的模块）递归地应用于子包，使用父包的 __path__ 代替 sys.path 作为生成子 __path__ 的基础。这意味着自包含和虚拟包可以相互包含，不受限制，但需要注意的是，如果您将虚拟包放入自包含包中，它的 __path__ 将非常短！）

向后兼容性和性能

请注意，这两个更改**仅**影响今天会导致 ImportError 的导入操作。因此，不涉及虚拟包的导入性能不受影响，潜在的向后兼容性问题也受到很大限制。

今天，如果您尝试从没有 __path__ 的模块导入子模块或子包，则会立即出错。当然，如果您在 sys.path 上的某个位置没有 zc.py 或 zc/__init__.py，那么 import zc 同样会失败。

因此，唯一潜在的向后兼容性问题是

1. 期望包目录具有 __init__ 模块、期望没有 __init__ 模块的目录无法导入，或期望 __path__ 属性是静态的工具将无法识别虚拟包作为包。

   （实际上，这仅仅意味着工具需要更新以支持虚拟包，例如，使用 pkgutil.walk_modules() 而不是使用硬编码的文件系统搜索。）

2. 期望某些导入失败的代码现在可能会做一些意想不到的事情。在实践中，这应该相当罕见，因为大多数合理的非测试代码不会导入预期不存在的内容！

上述情况最有可能的例外情况是，当一段代码尝试通过导入某个包来检查该包是否已安装时。如果这**仅**通过导入顶级模块来完成（即，不检查 __version__ 或某些其他属性），**并且**在 sys.path 上的某个位置存在与所需包同名的目录，**并且**该包实际上没有安装，那么此类代码可能会被误认为某个包已安装，而实际上并没有。

例如，假设有人编写了一个包含以下代码的脚本（datagen.py）

try:
    import json
except ImportError:
    import simplejson as json

并在如下布局的目录中运行它

datagen.py
json/
    foo.js
    bar.js

如果 import json 由于 json/ 子目录的存在而成功，则代码会错误地认为 json 模块可用，并继续以错误失败。

但是，我们可以通过对迄今为止提出的算法进行一项小的更改来防止此类极端情况的发生。与其允许您导入“纯虚拟”包（如 zc），我们只允许导入虚拟包的内容。

也就是说，类似 import zc 的语句如果在 sys.path 上没有 zc.py 或 zc/__init__.py，则应引发 ImportError。但是，执行 import zc.buildout 仍然应该成功，只要在 sys.path 上存在 zc/buildout.py 或 zc/buildout/__init__.py 即可。

换句话说，我们不允许直接导入纯虚拟包，只允许导入模块和自包含包。（这是一个可以接受的限制，因为本身导入这样的包没有任何功能价值。毕竟，在您至少导入其一个子包或子模块之前，模块对象将没有任何内容！）

但是，一旦成功导入 zc.buildout，sys.modules 中**将**存在一个 zc 模块，并且尝试导入它当然会成功。我们只是为了防止初始导入成功，以防止在 sys.path 上存在冲突的子目录时出现误报的导入成功。

因此，有了这个小小的改动，上面的 datagen.py 示例将正常工作。当它执行 import json 时，即使 json/ 目录包含 .py 文件，其单纯的存在也不会影响导入过程。只有在尝试类似 import json.converter 的导入时，才会搜索 json/ 目录。

同时，期望通过遍历目录树来定位包和模块的工具可以更新为使用现有的 pkgutil.walk_modules() API，而需要在内存中检查包的工具应该使用下面“标准库更改/添加”部分中描述的其他 API。

虚拟路径

通过为 sys.path（对于顶级模块）或父 __path__（对于子模块）中找到的每个路径条目获取一个 PEP 302 “导入器”对象来创建虚拟路径。

（注意：因为 sys.meta_path 导入器不与 sys.path 或 __path__ 条目字符串关联，所以此类导入器不参与此过程。）

检查每个导入器是否存在 get_subpath() 方法，如果存在，则使用正在为其构建路径的模块/包的全名调用该方法。返回值要么是表示请求包的子目录的字符串，要么是 None（如果不存在这样的子目录）。

返回的字符串按找到的顺序添加到正在构建的路径列表中。（None 值和缺少 get_subpath() 方法将被简单跳过。）

然后，生成的列表（无论是否为空）都将存储在 sys.virtual_package_paths 字典中，以模块名称为键。

此字典有两个用途。首先，它用作缓存，以防多次尝试导入虚拟包的子模块。

其次，更重要的是，该字典可供在运行时扩展 sys.path 的代码使用，以相应地更新导入的包的 __path__ 属性。（有关更多详细信息，请参见下面的“标准库更改/添加”）。

在 Python 代码中，虚拟路径构造算法看起来像这样

def get_virtual_path(modulename, parent_path=None):

    if modulename in sys.virtual_package_paths:
        return sys.virtual_package_paths[modulename]

    if parent_path is None:
        parent_path = sys.path

    path = []

    for entry in parent_path:
        # Obtain a PEP 302 importer object - see pkgutil module
        importer = pkgutil.get_importer(entry)

        if hasattr(importer, 'get_subpath'):
            subpath = importer.get_subpath(modulename)
            if subpath is not None:
                path.append(subpath)

    sys.virtual_package_paths[modulename] = path
    return path

并且像这样的函数应该在标准库中公开，例如 imp.get_virtual_path()，以便创建 __import__ 替换或 sys.meta_path 钩子的用户可以重用它。

标准库更改/添加

pkgutil 模块应更新为适当地处理此规范，包括对 extend_path()、iter_modules() 等的任何必要更改。

具体来说，对 pkgutil 的建议更改和添加如下

• 一个新的 extend_virtual_paths(path_entry) 函数，用于扩展现有的、已导入的虚拟包的 __path__ 属性，以包括在新的 sys.path 条目中找到的任何部分。此函数应由在运行时扩展 sys.path 的应用程序调用，例如，当向路径添加插件目录或 egg 时。

  此函数的实现对 sys.virtual_package_paths 执行简单的自上而下的遍历，并执行任何必要的 get_subpath() 调用，以识别需要添加到该包的虚拟路径中的路径条目，因为 path_entry 已添加到 sys.path 中。（或者，对于子包，添加基于其父包的虚拟路径的派生子路径条目。）

  （注意：此函数必须更新 sys.virtual_package_paths 中的路径值以及 sys.modules 中任何相应模块的 __path__ 属性，即使在常见情况下它们都将是相同的 list 对象。）

• 一个新的 iter_virtual_packages(parent='') 函数，允许从 sys.virtual_package_paths 自上而下遍历虚拟包，通过生成 parent 的子虚拟包。例如，调用 iter_virtual_packages("zope") 可能会生成 zope.app 和 zope.products（如果它们是 sys.virtual_package_paths 中列出的虚拟包），但不会生成 zope.foo.bar。（此函数需要实现 extend_virtual_paths()，但也可能对需要检查导入的虚拟包的其他代码有用。）
• ImpImporter.iter_modules() 应更改为检测并生成在虚拟包中找到的模块的名称。

除了上述更改之外，zipimport 导入器也应该类似地更改其 iter_modules() 实现。（注意：当前版本的 Python 通过 pkgutil 中的 shim 实现这一点，因此从技术上讲，这也是对 pkgutil 的更改。）

最后但并非最不重要的一点是，imp 模块（或 importlib，如果合适）应公开上面“虚拟路径”部分中描述的算法，作为一个 get_virtual_path(modulename, parent_path=None) 函数，以便 __import__ 替换的创建者可以使用它。

实现说明

对于虚拟包的用户、开发人员和分发者

• 虽然虚拟包易于设置和使用，但仍然有使用自包含包的时间和地点。虽然这不是绝对必要的，但向自包含包中添加 __init__ 模块可以让包的用户（以及 Python 本身）知道包的所有代码都将在这个单个子目录中找到。此外，它允许您定义 __all__，公开公共 API，提供包级文档字符串，以及执行对自包含项目更有意义而不是对仅仅的“命名空间”包更有意义的其他操作。
• sys.virtual_package_paths 允许包含不存在或尚未导入的包名称的条目；使用其内容的代码不应假设此字典中的每个键也存在于 sys.modules 中，或者导入名称一定会成功。
• 如果您正在将当前的自包含包更改为虚拟包，则需要注意，您不能再使用其 __file__ 属性来定位存储在包目录中的数据文件。相反，您必须搜索 __path__ 或使用与所需文件相邻的子模块的 __file__，或包含所需文件的自包含子包的 __file__。

  （注意：对于现有的“命名空间包”用户来说，此警告已经适用。也就是说，能够对包进行分区会导致您必须知道所需数据文件位于哪个分区。我们在这里提到它只是为了让新的从自包含包转换为虚拟包的用户也意识到这一点。）

• XXX “纯虚拟”包的 __file__ 是什么？None？一些任意字符串？第一个目录的路径加上尾部分隔符？无论我们放什么，某些代码都会中断，但最后一个选择可能会使一些代码意外地工作。这是好还是坏？

对于那些实现 PEP 302 导入器对象的开发者

• 支持 iter_modules() 方法（由 pkgutil 用于查找可导入的模块和包）的导入器，如果想要添加虚拟包支持，应该修改其 iter_modules() 方法，使其能够发现并列出虚拟包以及标准模块和包。为此，导入器只需列出其管辖范围内所有有效的 Python 标识符作为直接子目录名称即可。

  XXX 这可能会列出许多并非真正包的目录。我们是否应该要求存在可导入的内容？如果是，我们应该搜索多深，以及如何防止例如循环链接或遍历到不同的文件系统等？太复杂了。此外，即使列出了虚拟包，它们仍然无法被导入，这对 pkgutil.walk_modules() 的当前实现方式来说是一个问题。

• “元”导入器（即，放置在 sys.meta_path 上的导入器）不需要实现 get_subpath()，因为此方法仅在对应于 sys.path 条目和 __path__ 条目的导入器上调用。如果元导入器希望支持虚拟包，则必须完全在其自己的 find_module() 实现中完成。

  不幸的是，任何这样的实现都不太可能将其包子路径与其他元导入器或 sys.path 导入器的子路径合并，因此对于元导入器来说，“支持虚拟包”的含义目前尚不明确！

  （但是，由于元导入器的预期用例是完全替换 Python 的正常导入过程以用于某些模块子集，并且当前实现的此类导入器的数量非常少，因此在实践中这似乎不太可能成为一个大问题。）