python-ideas的新手會在沒有為從目前合法的Python3代碼提供一個清晰的遷移路徑的向后兼容性改變提議時偶爾提到"Python 4000"的想法。畢竟，我們允許Python3.0不向后兼容，為什么我們不能允許Python 4.0也這樣做呢？

我聽到了很多質(zhì)疑(包括"你造成過一次向后兼容的嚴重破壞，我怎么知道你不會再次破壞？"這樣的心聲),我想在此記錄我的回答，以便日后可以向人們提及。

目前對 Python 4.0 有哪些期待？

我目前的期待是 Python 4.0 僅是"Python 3.9 之后的另一個發(fā)行",僅此而已。沒有重大的語言改變，沒有重大向后兼容性的破壞——從 Python 3.9 到 4.0 的平滑過渡應和從 Python 3.3 到 3.4（或者是從 2.6 到 2.7）一樣。我甚至期待著穩(wěn)定的應用二進制接口在過渡中可以保留。

以目前大概每十八個月的語言特性發(fā)行速度，我們將在2023年的一個時間見到 Python 4.0,而不是Python 3.10。

Python 會怎樣繼續(xù)演進？

首先也是最重要的，Python改進提議過程并沒有改變——加入了新模塊(如asyncio）和語言特性(如yield from)以改進Python應用性能的向后兼容一直在議程之上。隨著時間的流逝，Python3憑借默認提供的性能將繼續(xù)拉大與Python 2的差距，即使Python 2用戶通過第三方模塊或Python 3的補丁達到和Python 3一樣的性能。

解釋器的實現(xiàn)和擴展也會繼續(xù)探索改進Python的不同方法，包括PyPy's對JIT-編譯器和軟件業(yè)務內(nèi)存的探索，對科學的和數(shù)據(jù)分析社區(qū)在充分發(fā)揮現(xiàn)代CPU和GPU提供的向量性能的面向數(shù)組編程的探索。與其他虛擬機運行時的整合(如JVM和CLR)也會隨著時間改進，尤其隨著Python成功進入教育領(lǐng)域，使其作為運行在那些虛擬機環(huán)境中的大型應用中使用的嵌入腳本語言變得更加流行。

PEP 387 為向后兼容提供了一個在 Python 2系列使用多年并且今天仍然適用的合理的解決方案概覽：如果一個語言特性問題重重，那么它可以被反對最終移除。

不管怎樣，一些開發(fā)和發(fā)行過程的其他改變使得Python3系列之內(nèi)不太可能存在被反對的語言特性：

• CPython核心開發(fā)團隊和Python Packaging Authoriy之間的協(xié)作，Python3.4+綁定的pip安裝器，都更加強調(diào)的Python Package Index，減少了模塊在適應相對較慢的語言更新周期中變得充分穩(wěn)定之前向標準庫添加模塊的壓力。

• PEP 411引入的"臨時API”概念使得向后兼容可能在受益于廣泛反饋的庫和API提供標準向后兼容保證之前對它們使用"安置"時間。

• 在Python3的過渡中清除了過去積累的語言問題，并且Python新特性和標準庫的需求比Python1.x和Python2.x時代更加苛刻。

• 廣泛的"single source"Python 2/3庫和框架開發(fā)極大鼓勵了"documented deprecation“在Python3中的使用，即使當特性被新的、***的、可選的特性替代。在這些情況下，文檔中寫入了反對注釋，意味著該方法是新代碼的***，但綱領(lǐng)性的反對警告沒有加入。這允許Python2和Python3都支持的現(xiàn)存代碼無需改動(需要新的用戶在維護現(xiàn)存代碼庫時學習稍微多一些的"documented deprecation")。

從英語居多到全語言

Python3對向后兼容的破壞出乎意料也不值一提。在Python3中所有的向后兼容改變中，許多嚴重的遷移阻礙歸罪于PEP 3100的一個小著重號(●):

• 所有的字符串均使用Unicode字符編碼，擁有一個單獨的bytes()類型。新字符串類型將命名為'str‘。

PEP3100 是Python3的改變被認為最沒有爭議的終點——沒有單獨的PEP必需考慮。這個特別的改變被認為是沒有爭議的原因是我們在Python2上的經(jīng)驗表明web和GUI框架的作者們是對的：作為一個應用開發(fā)者敏感地處理Unicode意味著確保所有的文本數(shù)據(jù)從二進制盡可能的轉(zhuǎn)換到系統(tǒng)邊界，以文本來操作，再轉(zhuǎn)換為二進制輸出。

不幸的是，Python2沒有鼓勵開發(fā)者那樣寫程序——它大范圍地模糊了二進制數(shù)據(jù)和文本的界限，使開發(fā)者在頭腦中區(qū)分這兩者變得困難，更不用說他們的代碼。所以web和GUI框架作者必需告訴他們的Python2用戶"使用Unicode文本，否則會在處理Unicode文本輸入時因為晦澀和難以追蹤bugs受罪。"

Python3改進了這個問題:它在"二進制域"和"文本域"之間加入了強制分離，使編寫普通應用更加簡單，同時也使編寫工作在二進制和文本數(shù)據(jù)的區(qū)別不是那么清晰的系統(tǒng)界限代碼時更加困難。關(guān)于Python2和Python3之間的文本模型改變的更多細節(jié)我寫在這里。

Python的Unicode支持正在演進，這和計算文本操作從English-only的ASCII(1963年正式定義)開始，一路經(jīng)過"二進制數(shù)據(jù)+編碼聲明"的復雜模式(包括二十世紀八十年末引進的C/POSIX locale和Windows code page系統(tǒng))和Unicode標準的原始16位only版本（1991年發(fā)布），向相對廣泛的現(xiàn)代Unicode代碼點系統(tǒng) （1996年定義，每幾年發(fā)布重大更新）遷移的大背景相悖。

為什么提及這一點呢？因為這種“默認Unicode”的轉(zhuǎn)變是Python3***破壞性的向后兼容性改變，不同于其他更多是語言特定的改變，它是文本數(shù)據(jù)呈現(xiàn)和操作更廣泛的行業(yè)改變的冰山一隅。隨著通過Python3過渡時語言特定問題的清除，比早期的Python更高的語言特性門檻和沒有其他從"二進制數(shù)據(jù)編碼"向文本模型當前使用的Unicode編碼這樣大規(guī)模的行業(yè)范圍遷移的轉(zhuǎn)變，讓我看不到會需要一個類似Python3的向后兼容性破壞和平行支持時期的改變到來。相反，我期待我們可以容納任何正常改變管理過程中的未來語言演進，任何不能以這種方式處理的提議都將被當做強加在社區(qū)和核心開發(fā)團隊上不可接受的高昂代價而被拒絕。

在我的個人博客上你也可以找到這篇文章:Why Python 4.0 won’t be like Python 3.0 | Curious Efficiency.

英文原文：Why Python 4.0 won’t be like Python 3.0

譯文出自：http://www.oschina.net/translate/why-python-4-0-wont-be-like-python-3-0