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 ：

 ~ $ 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

为什么这行得通？ I though there needed to be __init__.py files (empty ones would work) in both a and b for module.py to be importable when the 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

在 __init__.py ~/Playground/a 和 ~/Playground/a/b 它工作正常。

原文由 wujek 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

Python 3.3+ 具有 隐式命名空间包，允许它创建没有 __init__.py 文件的包。

允许隐式名称空间包意味着提供 __init__.py 文件的要求 可以完全删除，并影响……。

使用 __init__.py 文件的旧方法仍然像在 Python 2 中一样工作。

原文由 Mike Müller 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

概述

@Mike 的回答是正确的，但 不够精确。确实，Python 3.3+ 支持 _隐式命名空间包_，允许它创建一个没有 __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 。为了共享同一个命名空间，需要将公共路径的每个目录都做成一个命名空间包，即 google/ 和 cloud/ 。 这应该是创建命名空间包的唯一用例，否则就没有必要了。

至关重要的是，在 google 和 google/cloud 目录中没有 __init__py 文件，这样两个目录都可以被解释为 包。 在 Python 3.3+ 中， sys.path 上名称与要查找的包名称相匹配的任何目录都将被识别为该包的贡献模块和子包。因此，当您从 google_pubsub 和 google_storage 导入时，Python 解释器将能够找到它们。

这与独立的 常规包 不同，后者意味着所有部分都位于同一目录层次结构中。当导入包时，Python 解释器遇到 sys.path 上的子目录和 __init__.py 文件，然后它将创建一个仅包含该目录中模块的目录包，而不是查找所有模块该目录外适当命名的子目录。 这对于不想共享命名空间的包来说非常好。我强烈建议您查看 Python 导入系统中的 Traps for the Unwary 以 更好地了解 Python 导入如何使用常规包和命名空间包以及需要注意的 __init__.py 陷阱。

概括

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

资源

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

• PEP 420——隐式命名空间包
• 导入系统 - 常规包
• 导入系统——命名空间包
• Python 导入系统中粗心的陷阱

原文由 arauter 发布，翻译遵循 CC BY-SA 4.0 许可协议