摘要

本 PEP 描述了一个审查和改进标准库模块（特别是用 Python 编写的模块）的流程，使其为 Python 3000 做好准备。可以有不同阶段的改进，每个阶段都在下面的部分中进行描述。当然，并非每个模块都需要执行所有步骤。

移除过时模块

在 2.x 版本中标记为弃用的所有模块都应在 Python 3000 中移除。对于今天看来过时但由于使用广泛而无法弃用或移除的模块也适用。Python 3000 是摆脱它们的绝佳机会。

需要有一份文件列出所有已移除的模块，并提供可能的替代品或选择方案信息。这些信息也需要由 PEP XXX 中提到的 python3warn.py 移植辅助脚本提供。

重命名模块

有关于“标准库大规模重命名”的提案，引入一个分层的库命名空间或一个用于导入标准模块的顶级包。撇开这种可能性不谈，一些模块的名称被认为选择不当，这是在 2.x 系列中永远无法纠正的错误。例如，“StringIO”或“Cookie”之类的名称。对于 Python 3000，将有机会为这些模块赋予更清晰、更规范的名称。

当然，每次重命名都必须在相应模块的文档中说明，或许也需要在第 1 步的全局文档中说明。此外，python3warn.py 脚本将识别旧的模块名称并相应地通知用户。

如果名称更改及时赶在 Python 2.x 系列的下一个版本发布之前，则值得考虑在 2.x 分支中引入新名称以简化过渡。

代码清理

由于大多数用 Python 编写的库模块除了错误修复外都没有被触动，遵循“永不改变正在运行的系统”的政策，其中许多可能包含不符合最新语言特性的代码，可以改写成更简洁、更现代的 Python。

PyChecker 应该能干净地运行在库上。通过仔细调整配置文件，PyLint 也应该发出尽可能少的警告。

只要这些更改不改变模块的接口和行为，就不需要进行文档更新。

增强测试和文档覆盖率

单元测试的代码覆盖率在模块之间差异很大。应检查每个测试套件的完整性，并将剩余的经典测试转换为 PyUnit（或 Python 3000 附带的任何新的闪亮测试框架，可能是 py.test？）。

还应验证每个公开可见的函数是否都有有意义的文档字符串，并且最好包含多个 doctests。

增强测试覆盖率不需要文档更改。

统一模块元数据

这是一个小而可能不太重要的步骤。曾有各种尝试在模块中提供作者、版本等元数据（例如“__version__”全局变量）。这些可以标准化并在整个库中使用。

此步骤也不需要文档更改。

向后不兼容的错误修复

多年来，提交了许多关于标准库模块错误的错误报告，但后来被关闭为“不修复”，因为修复会引入一个在 Python 2.x 系列中不可接受的重大不兼容性。在 Python 3000 中，如果接口本身仍然可接受，则可以应用修复。

由此类修复引起的每一个轻微的行为更改都必须在文档中提及，或许在一个“版本 3.0 中的更改”段落中。

接口更改

最后也是最具破坏性的更改是模块公共接口的彻底改革。如果模块的接口要更改，应事先做出解释，或编写一个 PEP。

更改必须在文档中完全记录为“版本 3.0 中的新功能”，并且 python3warn.py 脚本必须知晓它。

参考资料

暂无。

版权

本文档已置于公共领域。