不管我們?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的核心開發(fā)人員Nick Coghlan的文章蝌借，希望你會(huì)感興趣。
一些剛剛接觸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)聽過(guò)很多次了（包括有人非常擔(dān)心地說(shuō)：“你已經(jīng)讓向后兼容性遭到了一次破壞，我怎么知道你還會(huì)不會(huì)再來(lái)一次牲剃？”）遣疯，我覺得我應(yīng)該把我的答案寫下來(lái)，將來(lái)有人問(wèn)及凿傅，我就可以讓他們來(lái)看這篇文章缠犀。
01：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了俄删。
02：那么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)記為棄用，最終將其刪除宙搬。
但是笨腥，開發(fā)和發(fā)布過(guò)程中，發(fā)生的許多其他更改勇垛，并不太可能在Python 3系列中被標(biāo)記為棄用：
? 這里主要強(qiáng)調(diào)一下Python包倉(cāng)庫(kù)脖母，這是CPython核心開發(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ì)稍微多一些）坛善。
03：從英語(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)用程序開發(fā)人員明智地使用Unicode意味著，確保所有的文本數(shù)據(jù)洽胶，都可以從二進(jìn)制盡可能地轉(zhuǎn)換為系統(tǒng)的文本操作晒夹，然后在輸出時(shí)轉(zhuǎn)換回二進(jìn)制。
遺憾的是姊氓，Python 2并不鼓勵(lì)開發(fā)人員丐怯，以這種方式編寫程序，這大大模糊了二進(jìn)制數(shù)據(jù)和文本之間的界限翔横，并使開發(fā)人員很難將兩者區(qū)分開读跷，更不用說(shuō)代碼了。
因此棕孙，Web和GUI框架作者舔亭，必須告訴他們的Python 2的用戶“使用Unicode文本。否則你就會(huì)在處理Unicode輸入時(shí)蟀俊，遇到捉摸不定钦铺、難以跟蹤的bug”。
Python 3則不同：它在“二進(jìn)制”和“文本”之間肢预，做了更大的分離矛洞，使得編寫正常的應(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的切換底循。
所以我并不覺得巢株，以后會(huì)有任何改動(dòng)，能像Python 3這樣熙涤，造成破壞向后兼容阁苞、并且需要并行支持期間。相反祠挫，我希望我們那槽，能夠在正常的變更管理流程中，適應(yīng)任何未來(lái)的語(yǔ)言演變等舔，任何無(wú)法以這種方式處理的提案骚灸，都會(huì)被拒絕，因?yàn)樗鼤?huì)給社區(qū)和核心開發(fā)團(tuán)隊(duì)慌植，帶來(lái)高得令人無(wú)法接受的成本甚牲。
