利用 Python 的 package 机制简化 utils 包设计

来源:转载

对于 package 机制的说明,其实官方文档已经有非常详尽的论述了,本文并不着眼于此。



简单来说,一个目录下如果包含__init__.py
,则被 Python 视作一个 Python package。其中:


__init__.py
中的东西,在初始化这个包时,会首先被加载
package 中还可以定义 sub package
初衷

为了概念统一,我们把写代码的人,大致分为两种角色:


Library Author
Caller 即 API 使用者

有时候我们会是 1 或者 2, 有时候我们可能既是 1 又是 2 ( 比如负责一个较大的系统时)


很显然,本文的角度是从 1 出发的(即我们只扮演库作者,并且不知道我们的调用者是谁)。



最开始时,utils 可能仅仅是一个utils.py
就可以了,然后调用者from utils import XXUtils
就完事了,这自然没有本文什么事。


然而大部分情况不是这样的,所有 Utils 都放到一个文件里面是 stupid 的(一个源码文件最多 400~500行 )。所以我们的目录结构会是这样的:


utils/
__init__.py
a_util.py
b_util.py
......


调用者怎么使用呢?from utils.a_util import AUtils


这种方式有一个假定:调用者要很清楚他所需要的 Utils 位于哪个 py 文件中。但是这种假定并不总是成立,大家对于同一概念的理解,极有可能是千差万别的。比如 utils,你觉得叫做 utils 合适,别人还觉得叫做 tools 合适呢,其实都是同一个东西。



显然,这加重了调用者的心智负担。更加显然的是,作为库作者,我们有义务来优化调用者的使用体验
!(不然你的库再牛逼,没有人爱用也是空弹琴。)


HOW

合理利用 package 机制,就能马上优化这一体验。



我们只要在__init__.py
中这么写即可:


__init__.py
from .a_util import AUtils
from .b_util import BUtils

调用者则仍然是这么使用:


from utils import AUtils, BUtils

即:调用者根本不关心你的实现在哪里,你只要给我一个 utils 的命名空间即可,而且确保所有的 Utils 都在这个命名空间里面。


为了更加符合 PEP8 的规范,作为库作者,我们的目录结构可能会变成这样:


utils/
__init__.py
_a_util.py 不对外界公开, 仅限本package的其他模块使用
_b_util.py
应用


不仅是对于 utils 包,对与 constants 包,exceptions 包也可以应用此方法。在许多开源库中,大牛们经常使用这一手法来优化我们的体验(太常见了,几乎大部分开源库的__init__.py
中都会写东西)


分享给朋友:
您可能感兴趣的文章:
随机阅读: