python-ideas新手偶尔会提到“Python4000”，因为没有向后兼容性更改提案提供从当前合法的Python3代码想法的清晰迁移路径。毕竟，我们允许Python3.0向后不兼容，为什么我们不能允许Python4.0做同样的事情呢？我听到了很多问题（包括“你破坏了一次向后兼容性，我怎么知道你不会再破坏它？”），我想在这里记录我的回答，以便以后参考.目前对Python4.0的期望是什么？我目前的期望是Python4.0只是“Python3.9之后的另一个版本”，仅此而已。没有重大的语言变化，没有重大的向后兼容性中断——从Python3.9到4.0的过渡应该与从Python3.3到3.4（或从2.6到2.7）一样顺利。我什至期待在过渡中保留稳定的应用程序二进制接口。按照目前大约每18个月发布一次语言功能的速度，我们将在2023年的某个时候看到Python4.0，而不是Python3.10。Python将如何继续发展？首先，Python改进提议过程没有改变——向后兼容添加新模块（如asyncio）和语言特性（如yieldfrom）以提高Python应用程序性能始终在议事日程上。随着时间的推移，Python3将以默认提供的性能继续拉大与Python2的差距，即使Python2用户通过第三方模块或Python3补丁实现与Python3相同的性能。解释器实现和扩展也将继续探索改进Python的不同方法，包括PyPy对JIT编译器和软件业务内存的探索，以及科学和数据分析社区充分利用现代CPU和GPU提供的矢量性能的方法。数组编程的探索。随着时间的推移，与其他虚拟机运行时（例如JVM和CLR）的集成也将得到改善，尤其是当Python成功进入教育领域作为一种嵌入式脚本语言用于在这些虚拟机环境中运行的大型应用程序时。变得更受欢迎。PEP387概述了一种合理的向后兼容性解决方案，该解决方案已在Python2系列中使用多年并且今天仍然适用：如果语言功能有问题，可以反对它最终被删除。然而，开发和发布过程中的一些其他变化使得Python3系列中不太可能存在已弃用的语言功能：CPython核心开发团队与PythonPackagingAuthority之间的协作，Python3.4+绑定的pip安装程序，两者更加强调Python包索引，减少模块在变得足够稳定以适应相对较慢的语言更新周期之前添加到标准库中的压力。PEP411引入的“临时API”的概念使得向后兼容成为可能，使用“放置”时间让库和API在提供标准向后兼容性保证之前受益于广泛的反馈。在Python3的过渡中，过去积累的语言问题得到了清理，对Python新特性和标准库的要求比Python1.x和Python2.x更加苛刻。广泛的“单一来源”Python2/3库和框架开发极大地鼓励在Python3中使用“记录在案的弃用”，即使功能被新的、更新的、可选的功能所取代。在这些情况下，文档中会写入弃用注释，暗示该方法是代码中的新方法，但不会添加编程弃用警告。这允许Python2和Python3支持的现有代码保持不变（要求新用户在维护现有代码库时稍微了解更多“记录的弃用”）。从英语主导到全语言Python3对向后兼容性的破坏是意想不到的，不值一提。在Python3的所有向后兼容性更改中，许多严重的迁移障碍都归因于PEP3100中的一个要点(●)：所有字符串都使用Unicode字符编码，并且具有单一的bytes()类型。新的字符串类型将被命名为“str”。PEP3100是对Python3的更改被认为争议最少的端点——无需考虑单独的PEP。这一特殊变化被认为没有争议的原因是我们使用Python2的经验表明Web和GUI框架的作者是正确的：作为应用程序开发人员敏感地处理Unicode意味着确保尽可能从二进制中提取所有文本数据。转换为系统边界，对文本进行操作，并转换为二进制输出。不幸的是，Python2并不鼓励开发人员以这种方式编写程序——它在很大程度上模糊了二进制数据和文本之间的界限，使开发人员很难在心理上将两者分开，更不用说他们的代码了。因此，Web和GUI框架的作者必须告诉他们的Python2用户“使用Unicode文本，否则在处理Unicode文本输入时会遇到晦涩难懂且难以追踪的错误”。“它们之间的强制分离，使得编写通用应用程序变得更容易，而编写在二进制和文本数据之间的区别不太清楚的系统边界工作的代码更难。我已经写了更多关于Python2和Python2之间文本模型变化的细节Python3here.Python对Unicode的支持在不断发展，从计算文本操作的纯英文ASCII（1963年正式定义）开始，一直到“二进制数据+编码语句”的复杂模式（包括C/POSIX语言环境和Windows代码）页系统）和最初的16位唯一版本的Unicode标准（1991年发布），在迁移到相对广泛的现代Unicode代码点系统（1996年定义，每隔几年发布一次重大更新）的背景下。为什么提到这个？因为这个“默认Unicode”转变是Python3中最具破坏性的向后兼容性变化，与其他更特定于语言的变化不同，它只是兄弟的冰山一角文本数据表示和处理方面的行业变化。随着通过Python3过渡时特定语言问题的清除，语言特性的门槛比早期的Python更高，并且没有其他主要的行业范围内从“二进制数据编码”迁移到文本模型当前使用的Unicode编码，让我看不到需要像Python3一样的向后兼容性中断和并行支持期的更改。相反，我希望我们能够在正常的变更管理流程中适应任何未来的语言演变，并且任何不能以这种方式处理的提案都将被拒绝，因为这会给社区和核心开发团队带来无法接受的高成本。你也可以在我的个人博客上找到这篇文章：为什么Python4.0不会像Python3.0|好奇的效率。英文原文：WhyPython4.0won'tbelikePython3.0翻译自：http://www.oschina.net/translate/why-python-4-0-wont-be-like-python-3-0
