问题描述：

我使用的是 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>

类似地，现在在home的超级文件夹中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

为什么这样做有效？我认为当 Python 路径指向文件夹时，和中都需要有__init__.py文件（空文件也可以）才能导入？a`bmodule.pyPlayground`

从 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效果很好。

解决方案 1：

概述

@Mike 的回答是正确的，但太不精确了。确实，Python 3.3+ 支持隐式命名空间包，允许它创建没有文件的包。与有文件（空或非空）的常规包__init__.py相比，这称为命名空间包。__init__.py

但是，只有在需要时才应创建命名空间包。对于大多数用例和开发人员来说，这并不适用，因此无论如何您都应该坚持使用空__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/。这应该是创建命名空间包的唯一用例，否则就没有必要。

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

这与常规包不同，常规包是自包含的，即所有部分都位于同一目录层次结构中。当导入包时，Python 解释器在包含sys.path文件的子目录中遇到包__init__.py，它将创建一个仅包含该目录中模块的单个目录包，而不是查找该目录之外所有适当命名的子目录。对于不想共享命名空间的包来说，这完全没问题。我强烈建议您查看Python 导入系统中疏忽大意的陷阱，以更好地了解 Python 导入常规和命名空间包的行为方式以及__init__.py需要注意哪些陷阱。

概括

• __init__.py仅当您要创建命名空间包时才跳过文件。仅当您拥有位于不同位置的不同库，并且希望它们各自为父包（即命名空间包）贡献一个子包时，才创建命名空间包。

• 继续__init__.py向目录中添加空文件，因为 99% 的时间你只想创建常规包。此外，Python 工具（例如mypy和）pytest需要空__init__.py文件来相应地解释代码结构。如果不小心，这可能会导致奇怪的错误。

资源

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

• PEP 420——隐式命名空间包

• 导入系统 - 常规包

• 导入系统 - 命名空间包

• Python 导入系统中容易被忽视的陷阱

解决方案 2：

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

允许隐式命名空间包意味着可以完全放弃__init__.py提供文件的要求，并受到影响……

处理文件的旧方式__init__.py仍然像在 Python 2 中一样有效。

解决方案 3：

如果您setup.py在项目中使用find_packages()它，则需要__init__.py在每个目录中都有一个文件，以便自动找到包。

只有包含以下__init__.py文件的包才会被识别

UPD：如果你想使用隐式命名空间包，则只需__init__.py使用find_namespace_packages()

文档

解决方案 4：

我想说，__init__.py如果想要隐式命名空间 package ，则应该省略 only 。如果您不知道它的含义，则可能不想要它，因此您应该继续__init__.py在 Python 3 中使用 even 。

解决方案 5：

根据我的经验，即使使用 python 3.3+，__init__.py有时仍需要一个空文件。一种情况是当您想将子文件夹引用为包时。例如，当我运行 时python -m test.foo，它不起作用，直到我__init__.py在测试文件夹下创建一个空文件。我这里说的是相当新的 3.6.6 版本。

除此之外，即使出于与现有源代码或项目指南兼容的原因，最好__init__.py在包文件夹中留一个空文件夹。