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提供了哪些功能即可。想要换一个不同的库？只需要修改包装器就可以了。只要它仍然提供同样的功能，那么完全不需要修改其余的核心代码。也许会有例外，但应该不会太多。大部分库都被设计成只专注解决一定范围的问题，因此很容易隔离。
5.7.3节将会涉及如何使用入口点构建驱动系统（driver system），这个系统让你可以将项目的某些部分设计成可以根据需要切换的模块。