摘要

本 PEP 描述了评审和改进标准库模块（尤其是用 Python 编写的模块）的流程，使其准备好在 Python 3000 中使用。翻新模块可能会涉及不同的步骤，每个步骤在下面的章节中都有描述。当然，并非每个模块都需要执行所有步骤。

移除过时模块

所有在 2.x 版本中被标记为弃用的模块都应该在 Python 3000 中移除。同样，对于现在被视为过时的模块，即使它们使用范围很广而无法被弃用或移除，也应该在 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？）。

还应该验证每个公开可见的函数都有一个有意义的文档字符串，理想情况下包含多个 doctest。

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

模块元数据统一

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

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

向后不兼容的错误修复

多年来，许多错误报告声称标准库模块存在错误，但后来被关闭，因为修复会导致重大的不兼容性，而在 Python 2.x 系列中这是不可接受的。在 Python 3000 中，如果接口本身仍然可以接受，则可以应用修复程序。

由这些修复程序引起的任何细微的行为变化都必须在文档中提到，例如在“版本 3.0 中的变更”段落中。

接口变更

最后一个也是最具破坏性的变化是彻底修改模块的公共接口。如果要更改模块的接口，应该事先进行论证，或者编写一个 PEP。

更改必须在“版本 3.0 中的新增功能”中完全记录，并且 python3warn.py 脚本必须知道该更改。

参考资料

目前还没有。

版权

本文档已进入公有领域。