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

Python-ideas的新手会在提议没有为从目前合法的Python3代码提供一个清晰的迁移路径的向后兼容性改变时偶尔提到"Python 4000"的想法。毕竟，我们允许Python3.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）一样。我甚至期待着稳定的应用二进制接口在过渡中可以保留。

以目前大概每十八个月的语言特性发行速度，我们将在2023年的一个时间见到 Python 4.0,而不是Python 3.10。

目前对 Python 4.0 有哪些期待？

我目前的期待是 Python 4.0 仅是"Python 3.9 之后的另一个发行",仅此而已。没有重大的语言改变，没有重大向后兼容性的破坏——从 Python 3.9 到 4.0 的平滑过渡应和从 Python 3.3 到 3.4（或者是从 2.6 到 2.7）一样。我甚至期待着稳定的应用二进制接口在过渡中可以保留。

以目前大概每十八个月的语言特性发行速度，我们将在2023年的一个时间见到 Python 4.0,而不是Python 3.10。

从英语居多到全语言

Python3对向后兼容的破坏出乎意料也不值一提。在Python3中所有的向后兼容改变中，许多严重的迁移阻碍归罪于PEP 3100的一个小着重号(●):

• 所有的字符串均使用Unicode字符编码，拥有一个单独的bytes()类型。新字符串类型将命名为'str‘。

PEP3100 是Python3的改变被认为最没有争议的终点——没有单独的PEP必需考虑。这个特别的改变被认为是没有争议的原因是我们在Python2上的经验表明web和GUI框架的作者们是对的：作为一个应用开发者敏感地处理Unicode意味着确保所有的文本数据从二进制尽可能的转换到系统边界，以文本来操作，再转换为二进制输出。

不幸的是，Python2没有鼓励开发者那样写程序——它大范围地模糊了二进制数据和文本的界限，使开发者在头脑中区分这两者变得困难，更不用说他们的代码。所以web和GUI框架作者必需告诉他们的Python2用户"使用Unicode文本，否则会在处理Unicode文本输入时因为晦涩和难以追踪bugs受罪。"

Python3改进了这个问题:它在"二进制域"和"文本域"之间加入了强制分离，使编写普通应用更加简单，同时也使编写工作在二进制和文本数据的区别不是那么清晰的系统界限代码时更加困难。关于Python2和Python3之间的文本模型改变的更多细节我写在这里。

Python的Unicode支持正在演进，这和计算文本操作从English-only的ASCII(1963年正式定义)开始，一路经过"二进制数据+编码声明"的复杂模式(包括二十世纪八十年末引进的C/POSIX locale和Windows code page系统)和Unicode标准的原始16位only版本（1991年发布），向相对广泛的现代Unicode代码点系统 （1996年定义，每几年发布重大更新）迁移的大背景相悖。

为什么提及这一点呢？因为这种“默认Unicode”的转变是Python3最具破坏性的向后兼容性改变，不同于其他更多是语言特定的改变，它是文本数据呈现和操作更广泛的行业改变的冰山一隅。随着通过Python3过渡时语言特定问题的清除，比早期的Python更高的语言特性门槛和没有其他从"二进制数据编码"向文本模型当前使用的Unicode编码这样大规模的行业范围迁移的转变，让我看不到会需要一个类似Python3的向后兼容性破坏和平行支持时期的改变到来。相反，我期待我们可以容纳任何正常改变管理过程中的未来语言演进，任何不能以这种方式处理的提议都将被当做强加在社区和核心开发团队上不可接受的高昂代价而被拒绝。

在我的个人博客上你也可以找到这篇文章:Why Python 4.0 won’t be like Python 3.0 | Curious Efficiency.

Python 的详细介绍：请点这里
Python 的下载地址：请点这里