每天早晨8点50分，准点开车打卡
本文为译文，来源开源中国
https://opensource.com/life/14/9/why-python-4-wont-be-python-3
https://www.oschina.net/translate/why-python-4-wont-be-python-3
当提出向后不兼容的更改时python-ideas的新手偶尔会提出“Python 4000”的概念，这些更改不给当前合法的Python3代码提供明确的移植路径。毕竟，我们允许Python 3.0进行这种更改，那么为什么我们不允许它用于Python 4.0呢？
Newcomers to python-ideas occasionally make reference to the idea of "Python 4000" when proposing backwards incompatible changes that don't offer a clear migration path from currently legal Python 3 code. After all, we allowed that kind of change for Python 3.0, so why wouldn't we allow it for Python 4.0?
我现在已经听过那么多问题了（包括更关注的措辞“你做了一次大的向后兼容性突破，我怎么知道你不会再这样做了？”），我想我会在这里记录我的答案，所以我将来能够将人们引回来。
I've heard that question enough times now (including the more concerned phrasing "You made a big backwards compatibility break once, how do I know you won't do it again?"), that I figured I'd record my answer here, so I'd be able to refer people back to it in the future.
现在对 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中首次定义一样）会在这个过渡边界上保留。
My current expectation is that Python 4.0 will merely be "the release that comes after Python 3.9". That's it. No profound changes to the language, no major backwards compatibility breaks - going from Python 3.9 to 4.0 should be as uneventful as going from Python 3.3 to 3.4 (or from 2.6 to 2.7). I even expect the stable Application Binary Interface (as first defined in PEP 384) to be preserved across the boundary.
按照当前语言特性发布的速度（大约每18个月），意味着我们可能会在2023年的某个时候看到Python 4.0，而不是看到Python 3.10。
At the current rate of language feature releases (roughly every 18 months), that means we would likely see Python 4.0 some time in 2023, rather than seeing Python 3.10.
那么 Python 将如何继续发展？
首先，Python 增强提议流程没有任何变化 —— 仍然提出了后向兼容的更改，添加了新模块（如 asyncio）和语言功能（如 yield from）以增强 Python 应用程序可用的功能。随着时间的推移，Python 3 在默认情况下提供的功能方面继续领先于 Python 2，即使 Python 2 用户可以通过第三方模块或 Python 3 的后端访问同等功能。
First and foremost, nothing has changed about the Python Enhancement Proposal process - backwards compatible changes are still proposed all the time, with new modules (like asyncio) and language features (like yield from) being added to enhance the capabilities available to Python applications. As time goes by, Python 3 will continue to pull further ahead of Python 2 in terms of the capabilities it offers by default, even if Python 2 users have access to equivalent capabilities through third party modules or backports from Python 3.
在解释器实现和扩展上竞赛还将继续探索增强Python的不同方法，包括PyPy对JIT编译器生成和软件事务存储的探索，以及在科学和数据分析社区中对充分利用现代CPU和GPU所提供的矢量化计算能力的面向阵列编程的探索。与其他虚拟机运行时（如JVM和CLR）的集成也有望随着时间的推移而改进，尤其是当Python在教育领域取得的进展可能使其作为嵌入式脚本语言在更多的应用程序的运行时的运行环境中更受欢迎。
Competing interpreter implementations and extensions will also continue to explore different ways of enhancing Python, including PyPy's exploration of JIT-compiler generation and software transactional memory, and the scientific and data analysis community's exploration of array oriented programming that takes full advantage of the vectorisation capabilities offered by modern CPUs and GPUs. Integration with other virtual machine runtimes (like the JVM and CLR) is also expected to improve with time, especially as the inroads Python is making in the education sector are likely to make it ever more popular as an embedded scripting language in larger applications running in those environments.
对于向后不兼容的改动，PEP 387提供了在Python 2系列中使用多年的方法的合理概述，并且至今仍然适用：如果某个功能被识别为过于有问题，那么它可能会被弃用并最终被移除。
For backwards incompatible changes, PEP 387 provides a reasonable overview of the approach that was used for years in the Python 2 series, and still applies today: if a feature is identified as being excessively problematic, then it may be deprecated and eventually removed.
然而，对开发和发布过程进行了许多其他变更，这使得在Python 3系列中不太可能需要这些弃用。
However, a number of other changes have been made to the development and release process that make it less likely that such deprecations will be needed within the Python 3 series:
正如CPython核心开发团队和Python Packaging Authority之间的协作，以及将pip安装程序与Python 3.4+的捆绑所揭示的，越加注重的Python Package Index，在它们能足够稳定适应相对较慢的语言更新周期之前，减少了将模块添加到标准库的压力。
“临时API”概念（在PEP 411中引入）使得可以在提供标准向后兼容性保证之前，对可能从更广泛的反馈中受益的库和API应用“稳定”期。
很多累积的遗留行为确实在Python 3过渡中被清除了，而Python和标准库的新增功能要求比Python 1.x和Python 2.x时期要严格得多。
“单一来源”Python 2/3库和框架的广泛开发强烈鼓励在Python 3中使用“文档弃用”，即使功能被更新的，首选的替代品替换。在这些情况下，文档中会放置弃用通知，建议新代码首选的方法，但不添加编程弃用警告。这允许现有代码（包括支持Python 2和Python 3的代码）保持不变（以牺牲新用户为代价，在维护现有代码库的任务时可能需要稍微学习一些）。
the greater emphasis on the Python Package Index, as indicated by the collaboration between the CPython core development team and the Python Packaging Authority, as well as the bundling of the pip installer with Python 3.4+, reduces the pressure to add modules to the standard library before they're sufficiently stable to accommodate the relatively slow language update cycle
the "provisional API" concept (introduced in PEP 411) makes it possible to apply a "settling in" period to libraries and APIs that are judged likely to benefit from broader feedback before offering the standard backwards compatibility guarantees
a lot of accumulated legacy behaviour really was cleared out in the Python 3 transition, and the requirements for new additions to Python and the standard library are much stricter now than they were in the Python 1.x and Python 2.x days
the widespread development of "single source" Python 2/3 libraries and frameworks strongly encourages the use of "documented deprecation" in Python 3, even when features are replaced with newer, preferred, alternatives. In these cases, a deprecation notice is placed in the documentation, suggesting the approach that is preferred for new code, but no programmatic deprecation warning is added. This allows existing code, including code supporting both Python 2 and Python 3, to be left unchanged (at the expense of new users potentially having slightly more to learn when tasked with maintaining existing code bases).
从（多数是）英语到所有书面语言
同样值得注意的是，Python 3预计不会像它原来那样具有破坏性。在Python 3中所有与之相关的向后不兼容的改动中，许多严重的迁移障碍可以放在PEP 3100的一个小基点上：
It's also worth noting that Python 3 wasn't expected to be as disruptive as it turned out to be. Of all the backwards incompatible changes in Python 3, many of the serious barriers to migration can be laid at the feet of one little bullet point in PEP 3100:
使所有字符串都是Unicode，并具有单独的bytes()类型。新的字符串类型将被称为'str'。
PEP 3100是Python 3变更的基地，它被认为是毫无争议的，单独的PEP是没有必要的。这个特殊变化被认为是无争议的原因是因为我们使用Python 2的经验表明Web和GUI框架的作者是正确的：作为应用程序开发者明智地处理Unicode意味着确保所有文本数据从二进制转换为尽可能接近于系统边界，按照文本处理，然后转换回二进制以用于输出的目的。
PEP 3100 was the home for Python 3 changes that were considered sufficiently non-controversial that no separate PEP was considered necessary. The reason this particular change was considered non-controversial was because our experience with Python 2 had shown that the authors of web and GUI frameworks were right: dealing sensibly with Unicode as an application developer means ensuring all text data is converted from binary as close to the system boundary as possible, manipulated as text, and then converted back to binary for output purposes.
遗憾的是，Python 2并不鼓励开发人员以这种方式编写程序 - 它大大模糊了二进制和文本数据之间的界限，并使开发人员难以将两者分开，更不用说在代码中了。因此，Web和GUI框架作者必须告知他们的Python 2用户“始终使用Unicode格式文本。如果不这样做，你可能会在处理Unicode输入时遇到晦涩难以处理的bug”。
Unfortunately, Python 2 doesn't encourage developers to write programs that way - it blurs the boundaries between binary data and text extensively, and makes it difficult for developers to keep the two separate in their heads, let alone in their code. So web and GUI framework authors have to tell their Python 2 users "always use Unicode text. If you don't, you may suffer from obscure and hard to track down bugs when dealing with Unicode input".
Python 3是不同的：它在“二进制域”和“文本域”之间实现了更大的隔离，使得编写正常的应用程序代码变得更加容易，同时使得编写二进制及文本边界不太清晰的系统中的代码变得更加困难。我在其他地方更详细地介绍了Python 2和Python 3之间文本模型的实际变动。
Python 3 is different: it imposes a much greater separation between the "binary domain" and the "text domain", making it easier to write normal application code, while making it a bit harder to write code that works with system boundaries where the distinction between binary and text data can be substantially less clear. I've written in more detail elsewhere regarding what actually changed in the text model between Python 2 and Python 3.
Python 对 Unicode 支持的这场革命是发生在更大的计算文本操作迁移的背景下的，从仅支持英文的 ASCII（1963年正式定义），到“二进制数据+编码声明”的模型（包括 C/POSIX locale 和在20世纪八十年代后期引入的 Windows 代码页系统）的复杂性以及从最初的 16 位 Unicode 标准版本（1991年发布）到相对全面的现代 Unicode 代码点系统（1996年首次定义，每几年发布一个包含了新的主要更新的版本）。
Python 3 is different: it imposes a much greater separation between the "binary domain" and the "text domain", making it easier to write normal application code, while making it a bit harder to write code that works with system boundaries where the distinction between binary and text data can be substantially less clear. I've written in more detail elsewhere regarding what actually changed in the text model between Python 2 and Python 3.
为什么要提这一点呢？因为这种切换到“默认情况下使用 Unicode”是对 Python3 中后向不兼容最具破坏性的，而不像其他改动（它们与语言本身相关性更高），它是文本数据表示和操作方式在更大行业广泛变化的一小部分。随着 Python 3 转换清除了语言特定问题，与 Python 早期版本相比，新语言功能的进入门槛要高得多，而且正在进行的从“带编码的二进制数据”切换到用于文本建模的 Unicode 的规模都比其他行业更广泛，我看不到任何需要 Python 3 样式后向兼容性中断和并行支持的更改。
Why mention this point? Because this switch to "Unicode by default" is the most disruptive of the backwards incompatible changes in Python 3 and unlike the others (which were more language specific), it is one small part of a much larger industry wide change in how text data is represented and manipulated. With the language specific issues cleared out by the Python 3 transition, a much higher barrier to entry for new language features compared to the early days of Python and no other industry wide migrations on the scale of switching from "binary data with an encoding" to Unicode for text modelling currently in progress, I can't see any kind of change coming up that would require a Python 3 style backwards compatibility break and parallel support period.
相反，我希望我们能够在正常的变更管理流程中适应任何未来的语言演变，任何无法以这种方式处理的提案都会被否决，因为它会给社区和核心开发团队带来不可接受的高昂成本。
Instead, I expect we'll be able to accommodate any future language evolution within the normal change management processes, and any proposal that can't be handled that way will just get rejected as imposing an unacceptably high cost on the community and the core development team.
~完~
打卡赠书：坚持30天打卡赠书新玩法！
送什么书？请点击左下角阅读原文查看！
签到方式：长按以下二维码参与打卡↓↓↓↓↓
1097
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
