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

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

目前對 Python 4.0 有哪些期待？

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

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

Python 會怎樣繼續演進？

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

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

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

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

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

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

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

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

從英語居多到全語言

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

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

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

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

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

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

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

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