為什麼 Python 4.0 會與 Python 3.0 不同？
【CSDN編者按】不管我們如何希望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這樣，造成破壞向後兼容、並且需要並行支持期間。相反，我希望我們，能夠在正常的變更管理流程中，適應任何未來的語言演變，任何無法以這種方式處理的提案，都會被拒絕，因為它會給社區和核心開發團隊，帶來高得令人無法接受的成本。
原文：https://opensource.com/life/14/9/why-python-4-wont-be-python-3
作者：Nick Coghlan，CPython的核心開發人員，Python軟體基金會的董事會成員。他是幾項Python增強建議的作者及合伙人（包括PEP 343：在Python 2.5中，添加了with語句和上下文管理器，PEP 453：與Python 3.4捆綁在一起的pip安裝程序），並作為BDFL的代理人，代替吉多·范羅蘇姆（Guido van Rossum）處理許多PEP申請。
譯者：彎月，責編：胡巍巍
TAG:CSDN |