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

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

目前對 Python 4.0 有哪些期待？

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

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

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

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

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

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

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

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

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

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

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

從英語居多到全語言

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

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

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

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

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

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

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

在我的個(gè)人博客上你也可以找到這篇文章: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