Python3.3中的包是否不需要_init__u;.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/playdey：

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

同样，现在在家里，操场的超级玩家：

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

为什么这行得通？我认为需要有__init__. py文件（空的可以工作）在两个a和b中，当Python路径指向时，module.py是可导入的>游乐场文件夹？

这似乎与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

在~/playway/a和~/playway/a/b中使用.\uuu init\uuu.py，工作正常。

Answer 1

如果您的项目中有setup.py，并且您在其中使用find_packages（），则需要在每个目录中有一个__init__. py文件，以便自动找到包。

包只有在包含__init__. py文件时才会被识别

UPD：如果要使用不带\uuu init\uuuuuuupy.py的隐式命名空间包，只需使用find\u namespace\u packages（）

文档

Answer 2

Python3.3具有隐式名称空间包，允许它在不使用\uuuu init\uuuu.py文件的情况下创建包。

允许隐式名称空间包意味着提供\uuuuu init\uuuuu.py文件的要求可能会被完全删除，并受到影响。

使用\uuuu init\uuuu.py文件的旧方法仍然与Python 2中的方法一样有效。

Answer 3

@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\u pubsub和google\u storage是独立的软件包，但它们共享相同的命名空间google/cloud。为了共享同一名称空间，需要将公共路径的每个目录设置为名称空间包，即google/和cloud/。这应该是创建名称空间包的唯一用例，否则就没有必要了。

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

这与常规包不同，常规包是自包含的，这意味着所有部分都位于同一目录层次结构中。当导入包时，Python解释器在sys.path上遇到带有\uuuu init\uuuuu.py文件的子目录时，它将创建一个仅包含该目录中模块的目录包，而不是在该目录外找到所有适当命名的子目录。这对于不想共享名称空间的包来说是非常好的。我强烈建议大家看看Python导入系统中的陷阱，以便更好地了解Python导入在常规和命名空间包中的行为，以及需要注意的\uuuuu init\uuuuuuuuupy陷阱。

• 如果要创建名称空间包，请仅跳过\uuuuuu init\uuuuuuuuu.py文件。如果您有位于不同位置的不同库，并且希望它们各自为父包（即命名空间包）贡献一个子包，则仅创建命名空间包。

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

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