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?
我現(xiàn)在已經(jīng)聽(tīng)過(guò)那么多問(wèn)題了（包括更關(guān)注的措辭“你做了一次大的向后兼容性突破，我怎么知道你不會(huì)再這樣做了？”），我想我會(huì)在這里記錄我的答案，所以我將來(lái)能夠?qū)⑷藗円貋?lái)。
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.
我現(xiàn)在的預(yù)測(cè)就是Python 4.0只不過(guò)是“Python 3.9后的版本”。就是這樣。對(duì)語(yǔ)言來(lái)說(shuō)沒(méi)有重大改變，沒(méi)有主要向后兼容突破——從Python 3.9到4.0應(yīng)該就像從Python 3.3 到3.4（或者從2.6到2.7）。我甚至預(yù)測(cè)穩(wěn)定的應(yīng)用程序二進(jìn)制接口（Application Binary Interface）（在PEP 384中首次定義一樣）會(huì)在這個(gè)過(guò)渡邊界上保留。
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.
按照當(dāng)前語(yǔ)言特性發(fā)布的速度（大約每18個(gè)月），意味著我們可能會(huì)在2023年的某個(gè)時(shí)候看到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 增強(qiáng)提議流程沒(méi)有任何變化 —— 仍然提出了后向兼容的更改，添加了新模塊（如 asyncio）和語(yǔ)言功能（如 yield from）以增強(qiáng) Python 應(yīng)用程序可用的功能。隨著時(shí)間的推移，Python 3 在默認(rèn)情況下提供的功能方面繼續(xù)領(lǐng)先于 Python 2，即使 Python 2 用戶可以通過(guò)第三方模塊或 Python 3 的后端訪問(wèn)同等功能。
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.
在解釋器實(shí)現(xiàn)和擴(kuò)展上競(jìng)賽還將繼續(xù)探索增強(qiáng)Python的不同方法，包括PyPy對(duì)JIT編譯器生成和軟件事務(wù)存儲(chǔ)的探索，以及在科學(xué)和數(shù)據(jù)分析社區(qū)中對(duì)充分利用現(xiàn)代CPU和GPU所提供的矢量化計(jì)算能力的面向陣列編程的探索。與其他虛擬機(jī)運(yùn)行時(shí)（如JVM和CLR）的集成也有望隨著時(shí)間的推移而改進(jìn)，尤其是當(dāng)Python在教育領(lǐng)域取得的進(jìn)展可能使其作為嵌入式腳本語(yǔ)言在更多的應(yīng)用程序的運(yùn)行時(shí)的運(yùn)行環(huán)境中更受歡迎。
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.
對(duì)于向后不兼容的改動(dòng)，PEP 387提供了在Python 2系列中使用多年的方法的合理概述，并且至今仍然適用：如果某個(gè)功能被識(shí)別為過(guò)于有問(wèn)題，那么它可能會(huì)被棄用并最終被移除。
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.
然而，對(duì)開(kāi)發(fā)和發(fā)布過(guò)程進(jìn)行了許多其他變更，這使得在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核心開(kāi)發(fā)團(tuán)隊(duì)和Python Packaging Authority之間的協(xié)作，以及將pip安裝程序與Python 3.4+的捆綁所揭示的，越加注重的Python Package Index，在它們能足夠穩(wěn)定適應(yīng)相對(duì)較慢的語(yǔ)言更新周期之前，減少了將模塊添加到標(biāo)準(zhǔn)庫(kù)的壓力。
“臨時(shí)API”概念（在PEP 411中引入）使得可以在提供標(biāo)準(zhǔn)向后兼容性保證之前，對(duì)可能從更廣泛的反饋中受益的庫(kù)和API應(yīng)用“穩(wěn)定”期。
很多累積的遺留行為確實(shí)在Python 3過(guò)渡中被清除了，而Python和標(biāo)準(zhǔn)庫(kù)的新增功能要求比Python 1.x和Python 2.x時(shí)期要嚴(yán)格得多。
“單一來(lái)源”Python 2/3庫(kù)和框架的廣泛開(kāi)發(fā)強(qiáng)烈鼓勵(lì)在Python 3中使用“文檔棄用”，即使功能被更新的，首選的替代品替換。在這些情況下，文檔中會(huì)放置棄用通知，建議新代碼首選的方法，但不添加編程棄用警告。這允許現(xiàn)有代碼（包括支持Python 2和Python 3的代碼）保持不變（以犧牲新用戶為代價(jià)，在維護(hù)現(xiàn)有代碼庫(kù)的任務(wù)時(shí)可能需要稍微學(xué)習(xí)一些）。
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預(yù)計(jì)不會(huì)像它原來(lái)那樣具有破壞性。在Python 3中所有與之相關(guān)的向后不兼容的改動(dòng)中，許多嚴(yán)重的遷移障礙可以放在PEP 3100的一個(gè)小基點(diǎn)上：
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，并具有單獨(dú)的bytes()類型。新的字符串類型將被稱為'str'。
PEP 3100是Python 3變更的基地，它被認(rèn)為是毫無(wú)爭(zhēng)議的，單獨(dú)的PEP是沒(méi)有必要的。這個(gè)特殊變化被認(rèn)為是無(wú)爭(zhēng)議的原因是因?yàn)槲覀兪褂肞ython 2的經(jīng)驗(yàn)表明Web和GUI框架的作者是正確的：作為應(yīng)用程序開(kāi)發(fā)者明智地處理Unicode意味著確保所有文本數(shù)據(jù)從二進(jìn)制轉(zhuǎn)換為盡可能接近于系統(tǒng)邊界，按照文本處理，然后轉(zhuǎn)換回二進(jìn)制以用于輸出的目的。
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并不鼓勵(lì)開(kāi)發(fā)人員以這種方式編寫(xiě)程序 - 它大大模糊了二進(jìn)制和文本數(shù)據(jù)之間的界限，并使開(kāi)發(fā)人員難以將兩者分開(kāi)，更不用說(shuō)在代碼中了。因此，Web和GUI框架作者必須告知他們的Python 2用戶“始終使用Unicode格式文本。如果不這樣做，你可能會(huì)在處理Unicode輸入時(shí)遇到晦澀難以處理的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是不同的：它在“二進(jìn)制域”和“文本域”之間實(shí)現(xiàn)了更大的隔離，使得編寫(xiě)正常的應(yīng)用程序代碼變得更加容易，同時(shí)使得編寫(xiě)二進(jìn)制及文本邊界不太清晰的系統(tǒng)中的代碼變得更加困難。我在其他地方更詳細(xì)地介紹了Python 2和Python 3之間文本模型的實(shí)際變動(dòng)。
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 對(duì) Unicode 支持的這場(chǎng)革命是發(fā)生在更大的計(jì)算文本操作遷移的背景下的，從僅支持英文的 ASCII（1963年正式定義），到“二進(jìn)制數(shù)據(jù)+編碼聲明”的模型（包括 C/POSIX locale 和在20世紀(jì)八十年代后期引入的 Windows 代碼頁(yè)系統(tǒng)）的復(fù)雜性以及從最初的 16 位 Unicode 標(biāo)準(zhǔn)版本（1991年發(fā)布）到相對(duì)全面的現(xiàn)代 Unicode 代碼點(diǎn)系統(tǒng)（1996年首次定義，每幾年發(fā)布一個(gè)包含了新的主要更新的版本）。
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.
為什么要提這一點(diǎn)呢？因?yàn)檫@種切換到“默認(rèn)情況下使用 Unicode”是對(duì) Python3 中后向不兼容最具破壞性的，而不像其他改動(dòng)（它們與語(yǔ)言本身相關(guān)性更高），它是文本數(shù)據(jù)表示和操作方式在更大行業(yè)廣泛變化的一小部分。隨著 Python 3 轉(zhuǎn)換清除了語(yǔ)言特定問(wèn)題，與 Python 早期版本相比，新語(yǔ)言功能的進(jìn)入門檻要高得多，而且正在進(jìn)行的從“帶編碼的二進(jìn)制數(shù)據(jù)”切換到用于文本建模的 Unicode 的規(guī)模都比其他行業(yè)更廣泛，我看不到任何需要 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.
相反，我希望我們能夠在正常的變更管理流程中適應(yīng)任何未來(lái)的語(yǔ)言演變，任何無(wú)法以這種方式處理的提案都會(huì)被否決，因?yàn)樗鼤?huì)給社區(qū)和核心開(kāi)發(fā)團(tuán)隊(duì)帶來(lái)不可接受的高昂成本。
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.
聯(lián)系客服
