摘要

本PEP描述了Python 2.X系列和Python 3000之间向后不兼容的Python变更程序。所有此类变更都必须通过相应的Python 3000 PEP进行文档化，并且必须附带能够识别哪些Python 2.X代码片段在Python 3000中可能存在问题的代码。

基本原理

Python 3000将引入一系列向后不兼容的Python变更，主要目的是简化语言并纠正一些先前的设计错误。但Python 3000并非旨在成为一个与Python 2.X系列完全不同的新语言，并且预计大部分Python用户社区将在其可用时过渡到Python 3000。

为了鼓励这种过渡，提供一份关于如何将Python 2.X代码升级到Python 3000代码的清晰完整的指南至关重要。因此，对于任何向后不兼容的变更，都需要满足两点：

• 一份官方的Python增强提案（PEP）
• 能够识别在Python 3000中可能存在问题的Python 2.X代码片段的代码

Python 增强提案

每一项向后不兼容的变更都必须附带一份PEP。这份PEP应遵循常见的PEP指南，并解释向后不兼容变更的目的和理由。除了常见的PEP章节外，所有提出向后不兼容变更的PEP都必须包含一个额外的章节：“兼容性问题”。该章节应描述所提议的Python变更中哪些部分是向后不兼容的，以及可能出现的各种主要破坏。

尽管PEP仍需逐案评估，但如果其“兼容性问题”章节暗示了以下任何一种情况，则该PEP可能不适用于Python 3000：

• Python 2.X构造的大部分或所有实例在Python 3000中都不正确，而Python 3000构造的大部分或所有实例在Python 2.X中也都不正确。

  例如，将for循环的else子句的含义从“当循环未被中断时执行”更改为“当循环迭代次数为零时执行”，将意味着所有Python 2.X for循环的else子句都将被破坏，并且无法以适用于Python 3000的方式使用for循环的else子句。因此，关于这种想法的PEP很可能会被拒绝。

• Python 2.X构造的许多实例在Python 3000中都不正确，并且PEP未能展示这些变更在实际世界中的用例。

  Python 3000允许向后不兼容的变更，但不能过度。提出向后不兼容变更的PEP应提供能明显受益于这些变更的代码的良好示例。

编写PEP耗时，因此当多个向后不兼容的变更密切相关时，应在同一份PEP中提出。然而，此类PEP的“兼容性问题”章节可能会更长，因为它们现在必须描述所有提议变更可能导致的各种破坏。

识别有问题的代码

除了PEP要求外，向后不兼容的Python变更还必须附带代码，以便对在Python 3000中行为将有所不同的Python 2.X代码片段发出警告。这些警告将在Python 2.X中使用一个新的命令行开关：-3 启用。所有向后不兼容的变更都应附带针对Python 2.X的补丁，当指定 -3 时，该补丁会为每个被更改的构造发出警告。

例如，如果 dict.keys() 在Python 3000中返回一个迭代器，那么对Python 2.X分支的补丁应该做类似以下的事情：

如果指定了 -3，则将 dict.keys() 更改为返回 list 的一个子类，该子类在使用 __iter__() 以外的任何方法时都会发出警告。

这样的补丁意味着只有当使用Python 3000中将不存在的特性时才会发出警告，并且几乎所有现有代码都应继续工作。（依赖于 dict.keys() 总是返回 list 而不是子类的代码应该几乎不存在。）

参考资料

待定

版权

本文档已置于公共领域。