Python語(yǔ)言將如何繼續(xù)發(fā)展？

不管我們?nèi)绾蜗Ｍ鸓HP永遠(yuǎn)天下第一，亦或是Java永久無(wú)敵，更或者希望C語(yǔ)言永遠(yuǎn)是最好的語(yǔ)言。

然而，筆者今天搜索百度指數(shù)得知，Python的指數(shù)，已經(jīng)高于Java和PHP的指數(shù)之和。

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

筆者今天在百度指數(shù)的搜索結(jié)果

一些剛剛接觸Python思想的人，會(huì)提出無(wú)法向后兼容的修改建議，這些建議并沒(méi)有針對(duì)，當(dāng)前合法的Python 3代碼，給出明確的移植方案，而他們偶爾會(huì)提及Python 4000的思想。畢竟，Python 3.0時(shí)，我們?cè)试S了這類改動(dòng)，為什么Python 4.0就不允許呢？

這樣的問(wèn)題我已經(jīng)聽(tīng)過(guò)很多次了（包括有人非常擔(dān)心地說(shuō)：“你已經(jīng)讓向后兼容性遭到了一次破壞，我怎么知道你還會(huì)不會(huì)再來(lái)一次？”），我覺(jué)得我應(yīng)該把我的答案寫(xiě)下來(lái)，將來(lái)有人問(wèn)及，我就可以讓他們來(lái)看這篇文章。

Python 4.0目前的期望是什么？

我目前的期望是：Python 4.0僅僅只是“Python 3.9之后的一個(gè)版本”。僅此而已。語(yǔ)言沒(méi)有深刻的變化，也沒(méi)有重大的向后兼容性問(wèn)題，從Python 3.9到4.0，應(yīng)該像從Python 3.3到3.4（或從2.6到2.7）一樣平安無(wú)事。我甚至希望在版本升遷之際，應(yīng)用程序的二進(jìn)制接口（PEP 384引入的功能），能夠保持穩(wěn)定。

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

那么Python將如何繼續(xù)發(fā)展呢？

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

隨著時(shí)間的推移，Python 3在功能方面，將領(lǐng)先Python 2越來(lái)越多，即使Python 2用戶，可以通過(guò)第三方模塊或Python 3的后向移植，獲得同等功能，也無(wú)法趕上Python 3的功能。

不同解釋器實(shí)現(xiàn)和擴(kuò)展的互相競(jìng)爭(zhēng)，將繼續(xù)探索增強(qiáng)Python的不同方法，包括PyPy關(guān)于JIT編譯器生成和軟件事務(wù)內(nèi)存的嘗試，以及科學(xué)和數(shù)據(jù)分析社區(qū)，對(duì)面向數(shù)組編程的探索（這種方式充分利用了，現(xiàn)代CPU和GPU所提供的向量化功能）。

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

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

但是，開(kāi)發(fā)和發(fā)布過(guò)程中，發(fā)生的許多其他更改，并不太可能在Python 3系列中被標(biāo)記為棄用：

? 這里主要強(qiáng)調(diào)一下Python包倉(cāng)庫(kù)，這是CPython核心開(kāi)發(fā)團(tuán)隊(duì)和Python Packaging Authority通力協(xié)作的成果，而且Python 3.4+捆綁了pip的安裝程序，減少了向標(biāo)準(zhǔn)庫(kù)添加模塊的難度，即使你還不確定它們，足夠穩(wěn)定以適應(yīng)相對(duì)較慢的語(yǔ)言更新周期。

? “臨時(shí)API”概念（由PEP 411引入），可以在提供標(biāo)準(zhǔn)的向后兼容性保證之前，允許你設(shè)置“過(guò)渡期”來(lái)獲得更廣泛的回饋，從而有助于庫(kù)和API的構(gòu)建。

? 很多累積下來(lái)的遺留行為，在Python 3轉(zhuǎn)換過(guò)程中，得到了確實(shí)的解決，現(xiàn)在對(duì)Python和標(biāo)準(zhǔn)庫(kù)新增功能的要求，也比Python 1.x和Python 2.x時(shí)期要嚴(yán)格得多。

? “單一來(lái)源”的Python 2/3庫(kù)和框架，被廣泛接受，極大地鼓勵(lì)了在Python 3中使用“棄用功能文檔”，即使這些功能被新的、更好的功能替代。在這些情況下，文檔中設(shè)置的棄用通知，會(huì)建議新代碼應(yīng)當(dāng)使用的方法，但不會(huì)產(chǎn)生程序上的棄用警告。這樣一來(lái)現(xiàn)有代碼（包括支持Python 2和Python 3的代碼），可以保持不變（相應(yīng)的代價(jià)是：新用戶在面對(duì)維護(hù)現(xiàn)有代碼庫(kù)的任務(wù)時(shí)，可能需要學(xué)習(xí)的內(nèi)容會(huì)稍微多一些）。

從英語(yǔ)到所有語(yǔ)言

還有一點(diǎn)值得一提的是，Python 3本來(lái)沒(méi)打算，像現(xiàn)在這樣具有破壞性。在Python 3中所有無(wú)法向后兼容的改變中，許多嚴(yán)重阻礙代碼移植的困難，都可以歸結(jié)為PEP 3100中的一點(diǎn)上：

? 讓所有字符串都變成Unicode，并且擁有單獨(dú)的bytes()類型。新的字符串類型將被稱為'str'。

PEP 3100匯總了Python 3中所有爭(zhēng)議性不大、從而沒(méi)有必要單獨(dú)建立PEP的改動(dòng)。這個(gè)特殊的變化，被認(rèn)為無(wú)爭(zhēng)議的原因是：因?yàn)槲覀兪褂肞ython 2的經(jīng)驗(yàn)表明，Web和GUI框架的作者是正確的，即作為應(yīng)用程序開(kāi)發(fā)人員明智地使用Unicode意味著，確保所有的文本數(shù)據(jù)，都可以從二進(jìn)制盡可能地轉(zhuǎn)換為系統(tǒng)的文本操作，然后在輸出時(shí)轉(zhuǎn)換回二進(jìn)制。

遺憾的是，Python 2并不鼓勵(lì)開(kāi)發(fā)人員，以這種方式編寫(xiě)程序，這大大模糊了二進(jìn)制數(shù)據(jù)和文本之間的界限，并使開(kāi)發(fā)人員很難將兩者區(qū)分開(kāi)，更不用說(shuō)代碼了。

因此，Web和GUI框架作者，必須告訴他們的Python 2的用戶“使用Unicode文本。否則你就會(huì)在處理Unicode輸入時(shí)，遇到捉摸不定、難以跟蹤的bug”。

Python 3則不同：它在“二進(jìn)制”和“文本”之間，做了更大的分離，使得編寫(xiě)正常的應(yīng)用程序代碼更加容易，但也使得在那些二進(jìn)制和文本數(shù)據(jù)的區(qū)別，不那么清晰。

Python對(duì)Unicode的支持的這場(chǎng)革命，針對(duì)的是更大的關(guān)于計(jì)算文本操作移植的背景：從只有英文的ASCII（1963年正式定義），到“二進(jìn)制數(shù)據(jù)+編碼聲明”模型（包括20世紀(jì)80年代后期，引入的C/POSIX語(yǔ)言環(huán)境和Windows代碼頁(yè)系統(tǒng)），以及最初的16位Unicode標(biāo)準(zhǔn)版本（1991年發(fā)布）到相對(duì)全面的現(xiàn)代Unicode代碼點(diǎn)系統(tǒng)（1996年首次定義，每隔幾年都有一次最新的主要更新）。

為什么要提這一點(diǎn)？因?yàn)楦淖兊健澳J(rèn)使用Unicode”，是Python 3中最具有破壞性的、無(wú)法向后兼容的改動(dòng)，而且與其他（更依賴于具體語(yǔ)言特性的）改動(dòng)不同，它只是如何表示和操作文本數(shù)據(jù)這項(xiàng)大范圍的改動(dòng)中的一小部分。

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

所以我并不覺(jué)得，以后會(huì)有任何改動(dòng)，能像Python 3這樣，造成破壞向后兼容、并且需要并行支持期間。相反，我希望我們，能夠在正常的變更管理流程中，適應(yīng)任何未來(lái)的語(yǔ)言演變，任何無(wú)法以這種方式處理的提案，都會(huì)被拒絕，因?yàn)樗鼤?huì)給社區(qū)和核心開(kāi)發(fā)團(tuán)隊(duì)，帶來(lái)高得令人無(wú)法接受的成本。