为什么Python 4.0不会像Python 3.0

在提出向后不兼容的更改（这些更改不提供从当前合法的Python 3代码提供清晰的移植路径）时，使用python-ideas的新手偶尔会参考“ Python 4000”的思想。 毕竟，我们允许对Python 3.0进行这种更改，所以为什么不对Python 4.0进行更改呢？

我已经足够多的时候听到这个问题了（包括更关注的措辞“您一次重大的向后兼容性中断，我怎么知道您不会再做一次？”），我想我会在这里记录我的答案，这样我以后就可以将人们推荐给它。

目前对Python 4.0的期望是什么？

我目前的期望是Python 4.0仅仅是“ Python 3.9之后的发行版本”。 而已。 语言没有重大变化，没有重大的向后兼容性中断-从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 2用户可以通过第三方模块或Python 3的反向移植访问等效功能，Python 3在默认提供的功能方面也将继续领先于Python 2。

竞争性解释器的实现和扩展也将继续探索增强Python的不同方法，包括PyPy对JIT编译器生成和软件事务存储的探索，以及科学和数据分析社区对面向阵列编程的探索，该充分利用所提供的矢量化功能由现代CPU和GPU组成。 随着时间的流逝，与其他虚拟机运行时（例如JVM和CLR）的集成也有望得到改善，尤其是随着Python在教育领域的发展，有可能使其作为嵌入式脚本语言在运行于Windows的大型应用程序中更加流行。这些环境。

对于向后不兼容的更改， PEP 387提供了在Python 2系列中使用多年的方法的合理概述，并在今天仍然适用：如果某个功能被认为存在过多问题，则可能不推荐使用该功能，并最终将其删除。

但是，对开发和发布过程进行了许多其他更改，使得在Python 3系列中不太可能需要这种弃用：

• CPython核心开发团队和Python Packaging Authority之间的合作以及对pip安装程序与Python 3.4+的捆绑表明，对Python包索引的更加重视，减轻了向标准库添加模块的压力在它们足够稳定以适应相对较慢的语言更新周期之前
• “临时API”概念（在PEP 411中引入）使得可以在提供标准的向后兼容性保证之前，对被认为可能会从更广泛的反馈中受益的库和API应用“稳定期”
• 很多积累老式行为确实是在Python 3过渡清除出去，并为新增加的Python和标准库的要求要严格得多 ，现在比他们在Python 1.x和2.x的Python的天
• “单一源” 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的支持发生了革命，这是由于通过“二进制数据+编码声明”模型（包括C / POSIX ）的复杂性，从纯英语的ASCII （正式定义为1963年）开始了更大范围的计算文本操作的背景迁移。 语言环境和Windows代码页系统（在1980年代末期引入）以及Unicode标准的最初的16位版本（1991年发布）到相对全面的现代Unicode代码点系统（于1996年首次定义，每次发布新的主要更新）几年）。

为什么要提到这一点？ 因为此切换为“默认情况下为Unicode”是Python 3中向后不兼容更改的最大破坏力，并且与其他更改（特定于特定语言）不同，所以它是整个行业范围内文本数据如何更改的一小部分代表和操纵。 随着Python 3过渡解决了特定于语言的问题，与Python的早期相比，新语言功能的进入障碍大大增加，并且没有其他行业范围内的从“带有编码的二进制数据”转换为“二进制”的大规模迁移。目前正在进行用于文本建模的Unicode，我看不到任何需要Python 3样式向后兼容中断和并行支持期的更改。 相反，我希望我们能够在正常的变更管理流程中适应任何将来的语言发展，并且任何无法以这种方式处理的提案都将被拒绝，因为这会给社区和核心开发带来不可接受的高昂成本球队。

最初发表于《 好奇效率》 ，也可从Red Hat Developer Blog获得 。 在知识共享下重新发布。 有关Python进化的更多信息，您可能也对Nick Coghlan的《 使用Python向多语言编程的过渡》感兴趣。

翻译自: https://opensource.com/life/14/9/why-python-4-wont-be-python-3