为什么说Python4.0不会像Python3.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 会怎样继续演进？
首先也是最重要的，Python改进提议过程并没有改变——加入了新模块(如asyncio）和语言特性(如yield from)以改进Python应用性能的向后兼容一直在议程之上。随着时间的流逝，Python3凭借默认提供的性能将继续拉大与Python 2的差距，即使Python 2用户通过第三方模块或Python 3的补丁达到和Python 3一样的性能。
解释器的实现和扩展也会继续探索改进Python的不同方法，包括PyPy's对JIT-编译器和软件业务内存的探索，对科学的和数据分析社区在充分发挥现代CPU和GPU提供的向量性能的面向数组编程的探索。与其他虚拟机运行时的整合(如JVM和CLR)也会随着时间改进，尤其随着Python成功进入教育领域，使其作为运行在那些虚拟机环境中的大型应用中使用的嵌入脚本语言变得更加流行。
PEP 387 为向后兼容提供了一个在 Python 2系列使用多年并且今天仍然适用的合理的解决方案概览：如果一个语言特性问题重重，那么它可以被反对最终移除。
不管怎样，一些开发和发行过程的其他改变使得Python3系列之内不太可能存在被反对的语言特性：
- CPython核心开发团队和Python Packaging Authoriy之间的协作，Python3.4+绑定的pip安装器，都更加强调的Python Package Index，减少了模块在适应相对较慢的语言更新周期中变得充分稳定之前向标准库添加模块的压力。
- PEP 411引入的"临时API”概念使得向后兼容可能在受益于广泛反馈的库和API提供标准向后兼容保证之前对它们使用"安置"时间。
- 在Python3的过渡中清除了过去积累的语言问题，并且Python新特性和标准库的需求比Python1.x和Python2.x时代更加苛刻。
- 广泛的"single source"Python 2/3库和框架开发极大鼓励了"documented deprecation“在Python3中的使用，即使当特性被新的、首选的、可选的特性替代。在这些情况下，文档中写入了反对注释，意味着该方法是新代码的首选，但纲领性的反对警告没有加入。这允许Python2和Python3都支持的现存代码无需改动(需要新的用户在维护现存代码库时学习稍微多一些的"documented deprecation")。
从英语居多到全语言
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的向后兼容性破坏和平行支持时期的改变到来。相反，我期待我们可以容纳任何正常改变管理过程中的未来语言演进，任何不能以这种方式处理的提议都将被当做强加在社区和核心开发团队上不可接受的高昂代价而被拒绝。