加载中

Newcomers to python-ideas occasionally make reference to the idea of "Python 4000" when proposingbackwardsincompatible 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.

当提出向后不兼容这个改变的时候,即不提供给当前合法的Python3代码明确的移植路径,python新手偶尔会联想到“Python 4000”的想法。毕竟,我们允许这种对Python 3.0的修改,那么为什么我们不允许Python 4.0这么做?

我现在已经听到这个问题很多次了(包括更加不安的措辞“你做了一次向后兼容性的大突破,我怎么知道你不会再次这么做?”),我想我应该在这里记录我的答案,这样以后就可以让大家回顾它。

What are the current expectations for Python 4.0?

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 majorbackwardscompatibility 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.

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 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。

So how will Python continue to evolve?

First and foremost, nothing has changed about the Python Enhancement Proposal process -backwardscompatible 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 throughthird partymodules or backports from Python 3.

Python 将如何发展?

首先,增强 Python 提议的流程没有任何变化 —— 仍然提出了后向兼容的更改,添加了新模块(如 asyncio)和语言功能(如 yield from)以增强 Python 应用程序可用的功能。随着时间的推移,即使 Python 2 用户可以通过第三方模块或 Python 3 的后端访问同等功能,Python 3 将在默认情况下提供的功能方面继续领先于 Python 2。

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 ofarray orientedprogramming that takes full advantage of thevectorisationcapabilities 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.

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

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

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:

  • 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系列中不太可能需要这些弃用。

  • 正如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的代码)保持不变(以牺牲新用户为代价,在维护现有代码库的任务时可能需要稍微学习一些)。


From (mostly) English to all written languages

It's also worth noting that Python 3 wasn't expected to be as disruptive as it turned out to be. Of all thebackwardsincompatible 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:

  • Make all strings be Unicode, and have a separate bytes() type. The new string type will be called 'str'.

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 3预计不会像它原来那样具有破坏性。在Python 3中所有与之相关的向后不兼容的改动中,许多严重的迁移障碍可以放在PEP 3100的一个小基点上:

  • 使所有字符串都是Unicode,并具有单独的bytes()类型。新的字符串类型将被称为'str'。

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

Unfortunately, Python 2 doesn't encourage developers to write programs that way - it blurs the boundaries between binary data and textextensively,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 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 2并不鼓励开发人员以这种方式编写程序 - 它大大模糊了二进制和文本数据之间的界限,并使开发人员难以将两者分开,更不用说在代码中了。因此,Web和GUI框架作者必须告知他们的Python 2用户“始终使用Unicode格式文本。如果不这样做,你可能会在处理Unicode输入时遇到晦涩难以处理的bug”。

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

This revolution in Python's Unicode support is taking place against a larger background migration of computational text manipulation from the English-only ASCII (officially defined in 1963), through the complexity of the "binary data + encoding declaration" model (including the C/POSIX locale and Windows code page systems introduced in the late 1980's) and the initial 16-bit only version of the Unicode standard (released in 1991) to the relatively comprehensive modern Unicode code point system (first defined in 1996, with new major updates released every few years).

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

Why mention this point? Because this switch to "Unicode by default" is the most disruptive of thebackwardsincompatible changes in Python 3 and unlike the others (which were more language specific), it is one small part of a much largerindustry widechange 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 otherindustry widemigrations 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.

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

About the author

Nick Coghlan - Nick is a CPython core developer and a member of the Board of Directors for the Python Software Foundation. He is the author or co-author of several accepted Python Enhancement Proposals (including PEP 343, which added the with statement and context managers in Python 2.5, and PEP 453 which saw the pip installer bundled with Python 3.4), and has also accepted a number of PEPs on Guido van Rossum's behalf as BDFL-Delegate.

关于作者

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。

返回顶部
顶部