8.5 【进阶】常规包与空间命名包¶
1. 常规包¶
在 Python 3.3 之前或者说 Python 2
中，一个包想要被导入使用，那么该包内必须要有 __init__.py
文件，这个文件是 Python 识别一个文件夹是否是一个 Python 的重要标志。
举个例子，现在有如下的目录树，demo 及子文件夹 foo 和 bar 下都有
__init__.py 文件。
$ tree demo/
demo/
├── bar
│ └── __init__.py
├── foo
│ └── __init__.py
└── __init__.py
在该目录下进入 Python Console 模式，然后就可以正常导入了
>>> import demo
>>> import demo.bar
>>> import demo.foo
如果此时我把 demo 目录下的 __init__.py 删除
$ tree demo/
demo/
├── bar
│ └── __init__.py
└── foo
└── __init__.py
再导入就会报错。
>>> import demo
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named demo
2. 命名空间包¶
在 Python 3.3 之后（PEP
420），即使一个文件夹中没有定义
__init__.py，也是可以被导入的，只不过它不是以 Python
包的形式导入，而是以命名空间包 (Namespace package)
的形式被导入，而这一特性是在 Python 3.3 被引入的。
比如还是上面的目录结构：
$ tree demo/
demo/
├── bar
│ └── __init__.py
└── foo
└── __init__.py
在 Python 3 下进入 Python Console 模式，发现导入是正常的
>>> import demo
>>> import demo.foo
>>> import demo.bar
>>>
使用 __path__ 查看一下，发现 demo 不再是一个常规包了，而是一个
namespace package
>>> demo
<module 'demo' (namespace)>
>>>
>>> demo.__path__
_NamespacePath(['/root/python/demo'])
3. 空间命名包的好处¶
利用命名空间包这个技术，可以用来导入目录分散的代码。
比如有如下的目录树
$ tree
.
├── xc-pkg
│ └── demo
│ └── foo
│ └── __init__.py
└── xm-pkg
└── demo
└── bar
└── __init__.py
在这 xc-pkg 和 xm-pkg 这两个目录里，都有着共同的命名空间
demo。这时候再导入这两个包的时候，发现这两个包被合并到一起了
>>> import sys
>>> sys.path.extend(['xm-pkg', 'xc-pkg'])
>>>
>>> import demo.foo
>>> import demo.bar
>>> demo
<module 'demo' (namespace)>
在这里工作的机制被称为命名空间包的一个特征。从本质上讲，命名空间包是一种特殊的封装设计，为合并不同的目录的代码到一个共同的命名空间。
命名空间包的关键是确保顶级目录中没有 __init__.py
文件来作为共同的命名空间。缺失 __init__.py
文件使得在导入包的时候会发生有趣的事情：这并没有产生错误，解释器创建了一个由所有包含匹配包名的目录组成的列表。特殊的包命名空间模块被创建，只读的目录列表副本被存储在其
__path__ 变量中。
>>> demo.__path__
_NamespacePath(['xm-pkg/demo', 'xc-pkg/demo'])
一个包是否被作为一个包命名空间的主要方法是检查其 __file__
属性。如果没有，那包是个命名空间。这也可以由其字符表现形式中的 namespace
这个词体现出来。
>>> demo
<module 'demo' (namespace)>
>>>
>>> demo.__file__
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'demo' has no attribute '__file__'
>>>