摘要

本PEP描述了对Python进行向后不兼容更改的流程，这些更改发生在Python 2.X系列和Python 3000之间。所有此类更改必须由相应的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 2.X代码中哪些部分在Python 3000中可能存在问题的代码

Python增强提案

每个向后不兼容的更改都必须附带一个PEP。此PEP应遵循通常的PEP指南，并解释向后不兼容更改的目的和原因。除了通常的PEP部分之外，所有提议向后不兼容更改的PEP都必须包含一个附加部分：“兼容性问题”。本节应描述所提议的Python更改中哪些方面是不兼容的，以及预期的主要中断类型。

虽然PEP仍然必须根据具体情况进行评估，但如果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而不是子类的代码应该几乎不存在。）

参考文献

待定

版权

本文档已进入公有领域。