为什么 Python 4.0 不会像 3.0 一样? 已翻译 100%

oschina 投递于 2018/08/17 14:31 (共 10 段, 翻译完成于 08-28)
阅读 8193
收藏 10
2
加载中

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.

已有 2 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 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.

已有 1 人翻译此段
我来翻译

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

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 2 人翻译此段
我来翻译

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

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 2 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(17)

水表
所以py4到底兼容不兼容py3?
臣白衣

引用来自“小果汁儿”的评论

因为那个软弱无能的废物:Python之父,已经滚蛋了。
儿子 你吃屎了?
Xiaoshiyue
Xiaoshiyue
4
Avior
Avior
还是Java好,向下兼容
egmkang
egmkang
把性能提升一下
R
RemyZane
看到Python都出狗仔文了,并且还能引来这么多批评声,甚感欣慰
挖红薯
挖红薯
有病
小果汁儿
小果汁儿
因为那个软弱无能的废物:Python之父,已经滚蛋了。
ddatsh
ddatsh

引用来自“leegstar”的评论

用go妥妥的
+10086
bisu3306
bisu3306
语法上有革命性的变化是好事,不过不处理好兼容层, 就会丢失大批用户。
swift就是一个很好的例子,不过经过这么多代的变化 ,语法已经很完美,但到现在还没怎么大量使用。
返回顶部
顶部