Python-ideas 的新手偶尔会提到“Python 4000”的想法，当他们提出不向后兼容的更改，而这些更改没有为当前合法的 Python 3 代码提供清晰的迁移路径时。毕竟，我们允许了 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）一样平淡无奇。我甚至期望稳定的应用程序二进制接口（最初在 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 的不同方法，包括 PyPy 对 JIT 编译器生成和软件事务内存的探索，以及科学和数据分析社区对面向数组编程的探索，这种编程充分利用了现代 CPU 和 GPU 提供的向量化功能。与其他虚拟机运行时（如 JVM 和 CLR）的集成也有望随着时间的推移而改进，特别是随着 Python 在教育领域取得的进展，它很可能在运行在这些环境中的大型应用程序中作为嵌入式脚本语言而变得越来越受欢迎。
对于不向后兼容的更改， PEP 387 合理概述了 Python 2 系列多年来使用的方法，并且至今仍然适用：如果某个功能被认为问题过多，那么它可能会被弃用并最终移除。
但是，对开发和发布流程进行的其他一些更改使得在 Python 3 系列中不太可能需要此类弃用
- 更加强调 Python 包索引，CPython 核心开发团队和 Python Packaging Authority 之间的合作表明了这一点，以及 Python 3.4+ 捆绑了
pip安装程序，这减轻了在标准库中添加模块的压力，在它们足够稳定以适应相对缓慢的语言更新周期之前 - “临时 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 意味着确保所有文本数据都尽可能靠近系统边界地从二进制转换为文本，以文本形式进行操作，然后再转换回二进制以用于输出目的。
不幸的是，Python 2 并没有鼓励开发人员以这种方式编写程序 - 它广泛地模糊了二进制数据和文本之间的界限，使得开发人员很难在头脑中区分两者，更不用说在他们的代码中区分了。因此，Web 和 GUI 框架作者不得不告诉他们的 Python 2 用户“始终使用 Unicode 文本。如果你不这样做，在处理 Unicode 输入时，你可能会遇到晦涩难懂且难以追踪的错误”。
Python 3 是不同的：它在“二进制域”和“文本域”之间施加了更大的分离，使得编写正常的应用程序代码更容易，同时使得编写处理系统边界的代码稍微困难一些，在系统边界中，二进制数据和文本数据之间的区别可能明显不那么清晰。我已经在 其他地方 更详细地写了关于 Python 2 和 Python 3 之间文本模型实际变化的内容。
Python 的 Unicode 支持的这场革命正在更大的背景下发生，即计算文本操作从仅限英语的 ASCII （官方定义于 1963 年），经历了“二进制数据 + 编码声明”模型的复杂性（包括 C/POSIX 区域设置 和 Windows 代码页 系统，于 1980 年代后期引入）和最初的 16 位版本的 Unicode 标准 （于 1991 年发布）到相对全面的现代 Unicode 代码点系统（首次定义于 1996 年，新的主要更新每隔几年发布一次）。
为什么要提到这一点？因为这种切换到“默认使用 Unicode”是 Python 3 中最具破坏性的向后不兼容更改，并且与其他更改（更具体地说，是语言特定的）不同，它是更大的行业范围内的变化中的一小部分，这种变化是关于文本数据的表示和操作方式。随着 Python 3 过渡清除了特定于语言的问题，与 Python 的早期相比，新语言功能的准入门槛更高，并且目前没有其他行业范围内的迁移像从“带有编码的二进制数据”切换到 Unicode 进行文本建模那样规模庞大，我看不到任何即将到来的变化会需要 Python 3 式的向后兼容性中断和平行支持期。相反，我期望我们能够在正常的变更管理流程中适应任何未来的语言演变，任何无法以这种方式处理的提案都将被拒绝，因为它对社区和核心开发团队施加了不可接受的高成本。
最初发布于 Curious Efficiency ，也可在 Red Hat 开发者博客上找到。根据 Creative Commons 重新发布。要了解有关 Python 演变的更多信息，您可能对 使用 Python 过渡到多语言编程感兴趣，作者也是 Nick Coghlan。
13 条评论