python - Python 3.3+ 中的包不需要 __init__.py

Question

我正在使用 Python 3.5.1。我在这里阅读了文档和包装部分:https://docs.python.org/3/tutorial/modules.html#packages

现在，我有以下结构:

/home/wujek/Playground/a/b/module.py

module.py:

class Foo:
    def __init__(self):
        print('initializing Foo')

现在，在 /home/wujek/Playground:

~/Playground $ python3
>>> import a.b.module
>>> a.b.module.Foo()
initializing Foo
<a.b.module.Foo object at 0x100a8f0b8>

同样，现在在家中，Playground 的 super 文件夹:

~ $ PYTHONPATH=Playground python3
>>> import a.b.module
>>> a.b.module.Foo()
initializing Foo
<a.b.module.Foo object at 0x10a5fee10>

其实我什么都能做:

~ $ PYTHONPATH=Playground python3
>>> import a
>>> import a.b
>>> import Playground.a.b

为什么会这样？我虽然在 a 和 b 对于 module.py 在 Python 路径指向 Playground 文件夹时是否可导入？

这似乎已经从 Python 2.7 改变了:

~ $ PYTHONPATH=Playground python
>>> import a
ImportError: No module named a
>>> import a.b
ImportError: No module named a.b
>>> import a.b.module
ImportError: No module named a.b.module

在 ~/Playground/a 和 ~/Playground/a/b 中使用 __init__.py 可以正常工作。

Answer 1

概述

@Mike 的回答是正确的，但太不精确了。确实，Python 3.3+ 支持 Implicit Namespace Packages 允许它创建一个没有 __init__.py 文件的包。这称为 命名空间包，而 常规包 确实有一个 __init__.py 文件(空或非空)。

但是，只有在需要时才应该创建 命名空间包。对于大多数用例和开发人员来说，这并不适用，所以无论如何你都应该坚持使用 EMPTY __init__.py 文件。

命名空间包用例

为了演示这两种python包的区别，让我们看下面的例子:

google_pubsub/              <- Package 1
    google/                 <- Namespace package (there is no __init__.py)
        cloud/              <- Namespace package (there is no __init__.py)
            pubsub/         <- Regular package (with __init__.py)
                __init__.py <- Required to make the package a regular package
                foo.py

google_storage/             <- Package 2
    google/                 <- Namespace package (there is no __init__.py)
        cloud/              <- Namespace package (there is no __init__.py)
            storage/        <- Regular package (with __init__.py)
                __init__.py <- Required to make the package a regular package
                bar.py

google_pubsub 和 google_storage 是独立的包，但它们共享相同的命名空间 google/cloud。为了共享同一个命名空间，需要将公共(public)路径的每个目录都做成一个命名空间包，即google/和cloud/。 这应该是创建命名空间包的唯一用例，否则就没有必要了。

google 和 google/cloud 目录中没有 __init__py 文件至关重要，这样两个目录都可以被解释为 命名空间包。 In Python 3.3+ any directory on the sys.path with a name that matches the package name being looked for will be recognized as contributing modules and subpackages to that package .因此，当您同时从 google_pubsub 和 google_storage 导入时，Python 解释器将能够找到它们。

这与 常规包 不同，后者是自包含的，这意味着所有部分都位于同一目录层次结构中。当导入一个包并且 Python 解释器在 sys.path 上遇到一个带有 __init__.py 文件的子目录时，它将创建一个仅包含来自该文件的单个目录包目录，而不是在该目录之外查找所有适当命名的子目录。 这对于不想共享命名空间的包来说非常合适。我强烈推荐看看Traps for the Unwary in Python’s Import System更好地了解 Python 导入在常规和命名空间包中的行为方式以及需要注意的 __init__.py 陷阱。

总结

• 如果您想创建 命名空间包，请仅跳过 __init__.py 文件。仅当您有不同的库位于不同的位置并且您希望它们各自为父包(即命名空间包)贡献一个子包时，才创建命名空间包。
• 继续将空的 __init__.py 添加到您的目录中，因为 99% 的时间您只想创建 常规包。此外，mypy 和 pytest 等 Python 工具需要空的 __init__.py 文件来相应地解释代码结构。如果不小心处理，这可能会导致奇怪的错误。

资源

我的回答只涉及常规包和命名空间包如何工作的表面，因此请查看以下资源以获取更多信息:

• PEP 420 -- Implicit Namespace Packages
• The import system - Regular packages
• The import system - Namespace packages
• Traps for the Unwary in Python’s Import System