Python 核心開發者解釋為何 Python 4.0 不會像 3.0 一樣

知識 09-06

(點擊

上方公號

，快速關注我們)

翻譯：oschina ，英文：Nick Coghlan

www.oschina.net/translate/why-python-4-wont-be-python-3?print

當提出向後不兼容的更改時，python-ideas的新手偶爾會提出「Python 4000」的概念，這些更改不給當前合法的Python3代碼提供明確的移植路徑。畢竟，我們允許Python 3.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）。我甚至預測穩定的應用程序二進位介面（Application Binary Interface）（在

PEP 384

中首次定義一樣）會在這個過渡邊界上保留。

按照當前語言特性發布的速度（大約每18個月），意味著我們可能會在2023年的某個時候看到Python 4.0，而不是看到Python 3.10。

那麼 Python 將如何繼續發展？

首先，Python 增強提議流程沒有任何變化 —— 仍然提出了後向兼容的更改，添加了新模塊（如 asyncio）和語言功能（如 yield from）以增強 Python 應用程序可用的功能。隨著時間的推移，Python 3 在默認情況下提供的功能方面繼續領先於 Python 2，即使 Python 2 用戶可以通過第三方模塊或 Python 3 的後端訪問同等功能。

在解釋器實現和擴展上競賽還將繼續探索增強Python的不同方法，包括PyPy對JIT編譯器生成和軟體事務存儲的探索，以及在科學和數據分析社區中對充分利用現代CPU和GPU所提供的矢量化計算能力的面向陣列編程的探索。與其他虛擬機運行時（如JVM和CLR）的集成也有望隨著時間的推移而改進，尤其是當Python在教育領域取得的進展可能使其作為嵌入式腳本語言在更多的應用程序的運行時的運行環境中更受歡迎。

對於向後不兼容的改動，

PEP 387

提供了在Python 2系列中使用多年的方法的合理概述，並且至今仍然適用：如果某個功能被識別為過於有問題，那麼它可能會被棄用並最終被移除。

然而，對開發和發布過程進行了許多其他變更，這使得在Python 3系列中不太可能需要這些棄用。

正如CPython核心開發團隊和Python Packaging Authority之間的協作，以及將pip安裝程序與Python 3.4+的捆綁所揭示的，越加註重的Python Package Index，在它們能足夠穩定適應相對較慢的語言更新周期之前，減少了將模塊添加到標準庫的壓力。

「臨時API」概念（在PEP 411中引入）使得可以在提供標準向後兼容性保證之前，對可能從更廣泛的反饋中受益的庫和API應用「穩定」期。

很多累積的遺留行為確實在Python 3過渡中被清除了，而Python和標準庫的新增功能要求比Python 1.x和Python 2.x時期要嚴格得多。

「單一來源」Python 2/3庫和框架的廣泛開發強烈鼓勵在Python 3中使用「文檔棄用」，即使功能被更新的，首選的替代品替換。在這些情況下，文檔中會放置棄用通知，建議新代碼首選的方法，但不添加編程棄用警告。這允許現有代碼（包括支持Python 2和Python 3的代碼）保持不變（以犧牲新用戶為代價，在維護現有代碼庫的任務時可能需要稍微學習一些）。

從（多數是）英語到所有書面語言

同樣值得注意的是，Python 3預計不會像它原來那樣具有破壞性。在Python 3中所有與之相關的向後不兼容的改動中，許多嚴重的遷移障礙可以放在

PEP 3100

的一個小基點上：

使所有字元串都是Unicode，並具有單獨的bytes()類型。新的字元串類型將被稱為』str』。

PEP 3100是Python 3變更的基地，它被認為是毫無爭議的，單獨的PEP是沒有必要的。這個特殊變化被認為是無爭議的原因是因為我們使用Python 2的經驗表明Web和GUI框架的作者是正確的：作為應用程序開發者明智地處理Unicode意味著確保所有文本數據從二進位轉換為儘可能接近於系統邊界，按照文本處理，然後轉換回二進位以用於輸出的目的。

遺憾的是，Python 2並不鼓勵開發人員以這種方式編寫程序 – 它大大模糊了二進位和文本數據之間的界限，並使開發人員難以將兩者分開，更不用說在代碼中了。因此，Web和GUI框架作者必須告知他們的Python 2用戶「始終使用Unicode格式文本。如果不這樣做，你可能會在處理Unicode輸入時遇到晦澀難以處理的bug」。

Python 3是不同的：它在「二進位域」和「文本域」之間實現了更大的隔離，使得編寫正常的應用程序代碼變得更加容易，同時使得編寫二進位及文本邊界不太清晰的系統中的代碼變得更加困難。我在

其他地方

更詳細地介紹了Python 2和Python 3之間文本模型的實際變動。

Python 對 Unicode 支持的這場革命是發生在更大的計算文本操作遷移的背景下的，從僅支持英文的

ASCII

（1963年正式定義），到「二進位數據+編碼聲明」的模型（包括

C/POSIX locale

和在20世紀八十年代後期引入的 Windows

代碼頁

系統）的複雜性以及從最初的 16 位

Unicode

標準版本（1991年發布）到相對全面的現代 Unicode 代碼點系統（1996年首次定義，每幾年發布一個包含了新的主要更新的版本）。

為什麼要提這一點呢？因為這種切換到「默認情況下使用 Unicode」是對 Python3 中後向不兼容最具破壞性的，而不像其他改動（它們與語言本身相關性更高），它是文本數據表示和操作方式在更大行業廣泛變化的一小部分。隨著 Python 3 轉換清除了語言特定問題，與 Python 早期版本相比，新語言功能的進入門檻要高得多，而且正在進行的從「帶編碼的二進位數據」切換到用於文本建模的 Unicode 的規模都比其他行業更廣泛，我看不到任何需要 Python 3 樣式後向兼容性中斷和並行支持的更改。相反，我希望我們能夠在正常的變更管理流程中適應任何未來的語言演變，任何無法以這種方式處理的提案都會被否決，因為它會給社區和核心開發團隊帶來不可接受的高昂成本。

關於作者

Nick Coghlan – Nick是CPython的核心開發人員，也是Python Software Foundation的董事會成員。他是幾個公認的Python增強建議的作者或共同作者（包括PEP 343，它在Python 2.5中添加了with語句和上下文管理器，PEP 453看到了與Python 3.4捆綁在一起的pip安裝程序），並且還接受了一些Guido van Rossum代表BDFL代表的PEP。

【關於投稿】

如果大家有原創好文投稿，請直接給公號發送留言。

① 留言格式：

【投稿】+《文章標題》+ 文章鏈接

② 示例：

【投稿】

《不要自稱是程序員，我十多年的 IT 職場總結》：

http://blog.jobbole.com/94148/

③ 最後請附上您的個人簡介哈~

看完本文有收穫？請轉

發分享給更多人

關注「P