思想实验

让我们暂时跳进时光机，假装我们回到了20世纪90年代初，就在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模块仍然只是一个模块，它仍然正常导入。

自包含 vs. “虚拟”包

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

因此，此PEP提议在缺失__path__的情况下**动态创建**一个__path__。

也就是说，如果我尝试import Foo.Bar，对导入机制的拟议更改将注意到Foo模块缺少__path__，因此将尝试**构建**一个，然后再继续。

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

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

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

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

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

但它**确实**意味着，如果你想将你的Foo模块转换为Foo包，你所要做的就是在sys.path的某个地方添加一个Foo/目录，并开始向其中添加模块。

但如果你只想要一个“命名空间包”呢？也就是说，一个**仅**作为各种独立分发的子模块和子包的命名空间的包？

例如，如果你是Zope Corporation，分发了数十个独立工具，如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。但是，只要sys.path上存在zc/buildout.py或zc/buildout/__init__.py，那么import zc.buildout仍应成功。

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

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

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

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

虚拟路径

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

（注意：由于sys.meta_path importers不与sys.path或__path__条目字符串关联，因此这些importers**不**参与此过程。）

检查每个importer是否具有get_subpath()方法，如果存在，则使用要为该包构建的完整模块/包名称调用该方法。返回值是要么表示请求包的子目录的字符串，要么是None（如果没有这样的子目录）。

importers返回的字符串按找到的顺序添加到正在构建的路径列表中。（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 importer的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 importer对象的开发者

• 支持iter_modules()方法（pkgutil用来定位可导入模块和包）并且希望添加虚拟包支持的importer，应该修改其iter_modules()方法，使其能够发现和列出虚拟包以及标准模块和包。要做到这一点，importer应该简单地列出其管辖范围内的所有合法的Python标识符的直接子目录名称。

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

• “元”importer（即放在sys.meta_path上的importer）不需要实现get_subpath()，因为该方法仅在对应于sys.path条目和__path__条目的importer上调用。如果一个元importer希望支持虚拟包，它必须完全在其自己的find_module()实现中做到这一点。

  不幸的是，不太可能任何这样的实现能够将其包子路径与来自其他元importer或sys.pathimporter的包子路径合并，因此“支持虚拟包”对于元importer的含义目前是未定义的！

  （然而，鉴于元importer的预期用途是完全替换Python的正常导入过程（对于某些模块子集），并且目前实现的此类importer的数量非常少，这似乎不太可能成为一个实际问题。）