Python从小白到高手实现系列六十六：命名空间包

Python 之禅（The Zen of Python，你可以在解释器会话中输入 import this 来阅读）
中关于命名空间的说法如下：
命名空间是一个绝妙的想法，我们要多加利用！
这句话至少可以用两种方式来理解。第一种是语言上下文中的命名空间。我们都使用
命名空间，甚至不知道以下内容。
• 模块的全局命名空间。
• 函数或方法调用的本地命名空间。
• 内置名称的命名空间。
另一种命名空间可以在包的层面提供。它们就是命名空间包（namespace packages）这通
常是一个被忽略的功能，在你的组织中或者非常大的项目中对于构建打包生态系统非常有用。
5.2.1 为什么有用
可以将命名空间包理解成在高于元包（meta-package）的层面对相关的包或模块进行分
组的方法，其中每个包都可以单独安装。
如果你的应用组件的开发、打包和版本化都是独立的，但仍然希望从同一个命名空间访问
它们，那么命名空间包特别有用。这有助于明确每个包所属的组织或项目。例如，对于某个虚
构的 Acme 公司，共同的命名空间可以是 acme。结果可能导致创建通用的 acme 命名空间包，
作为来自该组织的其他包的容器。例如，如果来自 Acme 的某人想要向这个命名空间贡献一个
与 SQL 相关的库，那么他可以创建一个在 acme 中注册自己的新的 acme.sql 包。
知道普通包和命名空间包的区别以及它们能够解决的问题是很重要的。一般来说（不
用命名空间包），你将会创建一个 acme 包和一个 sql 子包/子模块，其文件结构如下所示：
$ tree acme/
acme/
├── acme
│ ├── init.py
│ └── sql
│ └── init.py
└── setup.py
2 directories, 3 files
如果你想添加一个新的子包—例如 templating，就会被迫将其包含在 acme 的源
代码树中，如下所示：
$ tree acme/
acme/
├── acme
│ ├── init.py
│ ├── sql
│ │ └── init.py
│ └── templating
│ └── init.py
└── setup.py
3 directories, 4 files
利用这种方法几乎不可能单独开发 acme.sql 和 acme.templating。setup.py
脚本还必须指定每个子包的所有依赖，所以不可能（至少非常困难）选择性地安装 acme
的部分组件。此外，如果有些子包的需求文件有冲突，那么这是一个无法解决的问题。
利用命名空间包，你可以单独保存每个子包的源代码树，如下所示：
$ tree acme.sql/
acme.sql/
├── acme
│ └── sql
│ └── init.py
└── setup.py
2 directories, 2 files
$ tree acme.templating/
acme.templating/
├── acme
│ └── templating
│ └── init.py
└── setup.py
2 directories, 2 files
你还可以在 PyPI 或者你使用的任何包索引中单独注册它们。用户可以从 acme 命名空
间中选择想要安装的子包，但他们永远不用安装通用的的 acme 包（它并不存在），代码如下：
$ pip install acme.sql acme.templating
注意，独立的源代码树不足以在 Python 中创建命名空间包。如果你不想让你的包互相
覆盖，那么需要做一点额外的工作。此外，正确的处理方式可能会随着你指定的 Python 语
言版本的不同而有所不同。接下来的两节将会详细介绍这方面的详细内容。