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

当提出向后不兼容这个改变的时候,即不提供给当前合法的Python3代码明确的移植路径,python新手偶尔会联想到“Python 4000”的想法。毕竟,我们允许这种对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 2 用户可以通过第三方模块或 Python 3 的后端访问同等功能,Python 3 将在默认情况下提供的功能方面继续领先于 Python 2。

在解释器实现和扩展上竞赛还将继续探索增强Python的不同方法,包括PyPy对JIT编译器生成和软件事务存储的探索,以及在科学和数据分析社区中对充分利用现代CPU和GPU所提供的矢量化计算能力的面向阵列编程的探索。与其他虚拟机运行时(如JVM和CLR)的集成也有望随着时间的推移而改进,尤其是当Python在教育领域取得的进展可能使其作为嵌入式脚本语言在更多的应用程序的运行时的运行环境中更受欢迎。

对于向后不兼容的改动,PEP 387提供了在Python 2系列中使用多年的方法的合理概述,并且至今仍然适用:如果某个功能被识别为过于有问题,那么它可能会被弃用并最终被移除。

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


从(多数是)英语到所有书面语言

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

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

遗憾的是,Python 2并不鼓励开发人员以这种方式编写程序 - 它大大模糊了二进制和文本数据之间的界限,并使开发人员难以将两者分开,更不用说在代码中了。因此,Web和GUI框架作者必须告知他们的Python 2用户“始终使用Unicode格式文本。如果不这样做,你可能会在处理Unicode输入时遇到晦涩难以处理的bug”。

Python 3是不同的:它在“二进制域”和“文本域”之间实现了更大的隔离,使得编写正常的应用程序代码变得更加容易,同时使得编写二进制及文本边界不太清晰的系统中的代码变得更加困难。我在其他地方更详细地介绍了Python 2和Python 3之间文本模型的实际变动。

Python 对 Unicode 支持的这场革命是发生在更大的计算文本操作迁移的背景下的,从仅支持英文的 ASCII(1963年正式定义),到“二进制数据+编码声明”的模型(包括 C/POSIX locale 和在20世纪八十年代后期引入的 Windows 代码页系统)的复杂性以及从最初的 16 位 Unicode 标准版本(1991年发布)到相对全面的现代 Unicode 代码点系统(1996年首次定义,每几年发布一个包含了新的主要更新的版本)。

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

关于作者

Nick Coghlan  -  Nick是CPython的核心开发人员,也是Python Software Foundation的董事会成员。他是几个公认的Python增强建议的作者或共同作者(包括PEP 343,它在Python 2.5中添加了with语句和上下文管理器,PEP 453看到了与Python 3.4捆绑在一起的pip安装程序),并且还接受了一些Guido van Rossum代表BDFL代表的PEP。