不管我們如何希望PHP永遠天下第一，亦或是Java永久無敵，更或者希望C語言永遠是最好的語言。

然而，筆者今天搜索百度指數得知，Python的指數，已經高于Java和PHP的指數之和。

而Python的版本迭代也是嗖嗖的，那么新版本4.0和3.0究竟有什么區別呢？今天分享一篇Python軟件基金會的董事會成員、CPython的核心開發人員Nick Coghlan的文章，希望你會感興趣。

筆者今天在百度指數的搜索結果

一些剛剛接觸Python思想的人，會提出無法向后兼容的修改建議，這些建議并沒有針對，當前合法的Python 3代碼，給出明確的移植方案，而他們偶爾會提及Python 4000的思想。畢竟，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）一樣平安無事。我甚至希望在版本升遷之際，應用程序的二進制接口（PEP 384引入的功能），能夠保持穩定。

按照目前的語言功能的發布速度（大約每18個月發布一次），這意味著我們可能會在2023年看到Python 4.0，而不會有Python 3.10了。

那么Python將如何繼續發展呢？

首先，也是最重要的，PEP流程沒有任何變化，仍將持續提出向后兼容的更改，并將添加新模塊（如asyncio）和語言功能（如yield from）等，以增強Python應用程序能夠使用的功能。

隨著時間的推移，Python 3在功能方面，將領先Python 2越來越多，即使Python 2用戶，可以通過第三方模塊或Python 3的后向移植，獲得同等功能，也無法趕上Python 3的功能。

不同解釋器實現和擴展的互相競爭，將繼續探索增強Python的不同方法，包括PyPy關于JIT編譯器生成和軟件事務內存的嘗試，以及科學和數據分析社區，對面向數組編程的探索（這種方式充分利用了，現代CPU和GPU所提供的向量化功能）。

與其他虛擬機運行時（如JVM和CLR）的集成，也有望隨著時間的推移，而改進，尤其是在教育領域取得的進展，可能會讓Python作為更受歡迎的嵌入式腳本語言，在更大的應用程序中運行。

對于一些無法向后兼容的更改，PEP 387提供了一個合理的方法，該方法在Python 2系列中使用多年，并且今天仍然適用：即如果認為某個功能，會引起很大的問題，那么可以將其標記為棄用，最終將其刪除。

但是，開發和發布過程中，發生的許多其他更改，并不太可能在Python 3系列中被標記為棄用：

? 這里主要強調一下Python包倉庫，這是CPython核心開發團隊和Python Packaging Authority通力協作的成果，而且Python 3.4+捆綁了pip的安裝程序，減少了向標準庫添加模塊的難度，即使你還不確定它們，足夠穩定以適應相對較慢的語言更新周期。

? “臨時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對Unicode的支持的這場革命，針對的是更大的關于計算文本操作移植的背景：從只有英文的ASCII（1963年正式定義），到“二進制數據+編碼聲明”模型（包括20世紀80年代后期，引入的C/POSIX語言環境和Windows代碼頁系統），以及最初的16位Unicode標準版本（1991年發布）到相對全面的現代Unicode代碼點系統（1996年首次定義，每隔幾年都有一次最新的主要更新）。

為什么要提這一點？因為改變到“默認使用Unicode”，是Python 3中最具有破壞性的、無法向后兼容的改動，而且與其他（更依賴于具體語言特性的）改動不同，它只是如何表示和操作文本數據這項大范圍的改動中的一小部分。

隨著Python 3轉換清除了一些語言特定的問題，與Python早期相比，新的語言功能的門檻提高了很多，而且沒有任何波及業界的移植的規模，比得上目前正在進行的，從“帶編碼的二進制數據”到用于文本建模的Unicode的切換。

所以我并不覺得，以后會有任何改動，能像Python 3這樣，造成破壞向后兼容、并且需要并行支持期間。相反，我希望我們，能夠在正常的變更管理流程中，適應任何未來的語言演變，任何無法以這種方式處理的提案，都會被拒絕，因為它會給社區和核心開發團隊，帶來高得令人無法接受的成本。