为什么Python 4.0不会像3.0一样？

当提出向后不兼容的更改时python-ideas的新手偶尔会提出“Python 4000”的概念，这些更改不给当前合法的Python3代码提供明确的移植路径。毕竟，我们允许Python 3.0进行这种更改，那么为什么我们不允许它用于Python 4.0呢？

我现在已经听过那么多问题了（包括更关注的措辞“你做了一次大的向后兼容性突破，我怎么知道你不会再这样做了？”），我想我会在这里记录我的答案，所以我将来能够将人们引回来。

现在对Python 4.0的预测是什么？

我现在的预测就是Python 4.0只不过是“Python 3.9后的版本”。就是这样。对语言来说没有重大改变，没有主要向后兼容突破——从Python 3.9到4.0应该就像从Python 3.3 到3.4（或者从2.6到2.7）。我甚至预测稳定的应用程序二进制接口（Application Binary Interface）（在 PEP 384 中首次定义一样）会在这个过渡边界上保留。

按照当前语言特性发布的速度（大约每18个月），意味着我们可能会在2023年的某个时候看到Python 4.0，而不是看到Python 3.10。

那么 Python 将如何继续发展？

首先，Python 增强提议流程没有任何变化 —— 仍然提出了后向兼容的更改，添加了新模块（如 asyncio）和语言功能（如 yield from）以增强 Python 应用程序可用的功能。随着时间的推移，Python 3 在默认情况下提供的功能方面继续领先于 Python 2，即使 Python 2 用户可以通过第三方模块或 Python 3 的后端访问同等功能。

然而，对开发和发布过程进行了许多其他变更，这使得在Python 3系列中不太可能需要这些弃用。

• 正如CPython核心开发团队和Python Packaging Authority之间的协作，以及将pip安装程序与Python 3.4+的捆绑所揭示的，越加注重的Python Package Index，在它们能足够稳定适应相对较慢的语言更新周期之前，减少了将模块添加到标准库的压力。

• “临时API”概念（在PEP 411中引入）使得可以在提供标准向后兼容性保证之前，对可能从更广泛的反馈中受益的库和API应用“稳定”期。

• 很多累积的遗留行为确实在Python 3过渡中被清除了，而Python和标准库的新增功能要求比Python 1.x和Python 2.x时期要严格得多。

• “单一来源”Python 2/3库和框架的广泛开发强烈鼓励在Python 3中使用“文档弃用”，即使功能被更新的，首选的替代品替换。在这些情况下，文档中会放置弃用通知，建议新代码首选的方法，但不添加编程弃用警告。这允许现有代码（包括支持Python 2和Python 3的代码）保持不变（以牺牲新用户为代价，在维护现有代码库的任务时可能需要稍微学习一些）。

从（多数是）英语到所有书面语言

同样值得注意的是，Python 3预计不会像它原来那样具有破坏性。在Python 3中所有与之相关的向后不兼容的改动中，许多严重的迁移障碍可以放在 PEP 3100 的一个小基点上：

• 使所有字符串都是Unicode，并具有单独的bytes()类型。新的字符串类型将被称为'str'。

PEP 3100是Python 3变更的基地，它被认为是毫无争议的，单独的PEP是没有必要的。这个特殊变化被认为是无争议的原因是因为我们使用Python 2的经验表明Web和GUI框架的作者是正确的：作为应用程序开发者明智地处理Unicode意味着确保所有文本数据从二进制转换为尽可能接近于系统边界，按照文本处理，然后转换回二进制以用于输出的目的。

为什么要提这一点呢？因为这种切换到“默认情况下使用 Unicode”是对 Python3 中后向不兼容最具破坏性的，而不像其他改动（它们与语言本身相关性更高），它是文本数据表示和操作方式在更大行业广泛变化的一小部分。随着 Python 3 转换清除了语言特定问题，与 Python 早期版本相比，新语言功能的进入门槛要高得多，而且正在进行的从“带编码的二进制数据”切换到用于文本建模的 Unicode 的规模都比其他行业更广泛，我看不到任何需要 Python 3 样式后向兼容性中断和并行支持的更改。相反，我希望我们能够在正常的变更管理流程中适应任何未来的语言演变，任何无法以这种方式处理的提案都会被否决，因为它会给社区和核心开发团队带来不可接受的高昂成本。