《Python高手之路》——2.3 外部库

本节书摘来自异步社区《Python高手之路》一书中的第2章，第2.3节，作者[法]Julien Danjou（朱利安•丹乔）， 王飞龙 译，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.3 外部库

你是否有过这样的经历，收到一件不错的生日礼物或圣诞礼物，但是打开后却发现送你的人忘了买电池？Python的“内置电池”哲学让你作为程序员不会遇到这类问题，只要安装了Python，就拥有了完成任何功能所需的一切条件。

然而，Python标准库的开发者并不能预测你要实现的“任何”功能到底是什么。即使可以，大多数人也不想去处理一个几个GB的文件下载，即使可能只是需要写一个重命名文件的快速脚本。关键在于，即使拥有所有的扩展功能，仍然有许多功能是Python标准库没有涵盖的。不过，这并不是说有些事情是根本无法用Python实现的，这只是表明有些事情可能需要使用外部库。

Python标准库是安全且范围明确的：模块文档化程度很高，并且有足够多的人在经常使用它，从而可以保证在你想使用它时肯定不会遇到麻烦。而且，就算万一出了问题，也能确保在短时间内有人解决。但是，外部库就像是地图上标着“熊出没，请注意”的部分：可能缺少文档，功能有bug，更新较少或根本不更新。任何正式的项目都可能用到一些只有外部库提供的功能，但是需要谨记使用这些外部库可能带来的风险。

下面是来自一线的案例。OpenStack使用了SQLAlchemy（http://www.sqlalchemy.org/ ），一个Python数据库开发工具包。如果了解SQL的话会知道，数据库的结构是会发生变化的，所以OpenStack还使用了sqlalchemy-migrate（https://code.google.com/p/sqlalchemy-migrate/ ）来处理数据库模式的升级。一切运行良好，直到有一天它们不行了，开始出现大量bug，并且没有好转的迹象。而且，OpenStack在当时是想要支持Python 3的，然而没有任何迹象表明sqlalchemy-migrate要支持Python 3。因此，显然sqlalchemy-migrate已经死了，我们需要切换到其他替代方案。截止到作者写作时，OpenStack正准备升级到Alembic（https://pypi.python.org/pypi/alembic ），虽然也有一些工作要做，但好在不是那么痛苦。

所有这些引出一个重要的问题：“如何保证我不会掉进同样的陷阱里？”很遗憾，没办法保证。程序员也是人，没什么办法可以确保目前维护良好的库在几个月后仍然维护良好。但是，在OpenStack中我们使用下列检查表来根据需要给出建议（我建议你也这么做）。

• Python 3兼容。尽管现在你可能并不准备支持Python 3，但很可能早晚会涉及，所以确认选择的库是Python 3兼容的并且承诺保持兼容是明智的。
• 开发活跃。GitHub（http://github.com ）和Ohloh（http://www.ohloh.net/ ）通常提供足够的信息来判断一个库是否有维护者仍然在工作。
• 维护活跃。尽管一个库可能是“结束”状态（即功能完备，不会再加入新功能），但应该有维护者仍然在工作，以确保没有bug。可以通过查看项目的跟踪系统来看维护者对bug的反应是否迅速。
• 与各个操作系统发行版打包在一起。如果一个库被打包在主流的Linux发行版内，说明有其他项目依赖它，所以，如果真有什么问题，至少你不是唯一一个抱怨的。如果打算公开发布你的软件，那么这项检查也是很有用的。因为如果软件的依赖已经在终端用户的机器上安装了，显然分发你的软件会更容易。
• API兼容保证。没有比你的软件因为一个它依赖的库发生了变化而使整个API崩溃更糟的了。你一定很想知道选择的库在过去是否发生过类似的事件。

尽管可能工作量巨大，但这一检查表对于依赖同样适用。如果知道应用程序会大量依赖一个特定的库，那么至少应该对这个库的每一个依赖使用这个检查表。

不管最终使用哪个库，都要像其他工具一样对待，因为即使是有用的工具也可能会造成严重的损害。尽管不常发生，但问问你自己：如果你有一把锤子，你会拿着它满屋跑因而可能意外地损坏屋子里的东西，还是会把它放在工具架上或者车库里，远离那些贵重而易碎的东西，仅在需要的时候才拿出来？

对于外部库道理是一样的，不管它们多么有用，都需要注意避免让这些库和实际的源代码耦合过于紧密。否则，如果出了问题，你就需要切换库，这很可能需要重写大量的代码。更好的办法是写自己的API，用一个包装器对外部库进行封装，将其与自己的源代码隔离。自己的程序无需知道用了什么外部库，只要知道API提供了哪些功能即可。想要换一个不同的库？只需要修改包装器就可以了。只要它仍然提供同样的功能，那么完全不需要修改任何核心代码。也许会有例外，但应该不会太多。大部分库都被设计成只专注解决一定范围的问题，因此很容易隔离。