事件回顧
就在不久前，Python核心開(kāi)發(fā)者Pablo在郵件中宣布，由于一些重要的性能Bug和崩潰問(wèn)題，預(yù)計(jì)在10月底發(fā)布的Python 3.11穩(wěn)定版本可能要推遲到12月。
圖片來(lái)源@郵件截圖
此事引來(lái)了不少人的關(guān)注。Python是當(dāng)今最流行的編程語(yǔ)言之一，StackOverflow 2022 開(kāi)發(fā)者報(bào)告顯示，對(duì)初學(xué)者而言，HTML/CSS、Javascript和Python幾乎并列為最常用的語(yǔ)言，而在TIOBE發(fā)布的2022年6月編程語(yǔ)言排行上，Python語(yǔ)言則排名第一，因而Python語(yǔ)言新版本的發(fā)布，通常很受關(guān)注。
自2008年12月3日Python3.0發(fā)布以來(lái)，Python官方計(jì)劃每年發(fā)布一個(gè)新版本，每次增加兩三種新語(yǔ)法。雖然實(shí)際情況并沒(méi)有嚴(yán)格按照計(jì)劃實(shí)現(xiàn)，但自3.8版本以后，Python的發(fā)版節(jié)奏基本有規(guī)律可循：在每個(gè)版本發(fā)布前，都有17個(gè)月的開(kāi)發(fā)周期，在此期間要進(jìn)行持續(xù)的開(kāi)發(fā)測(cè)試；測(cè)試期間，首先會(huì)發(fā)布alpha版本，等到4月份再發(fā)布beta版本，直到10月左右，發(fā)布最終的正式版本。Python 3歷次版本發(fā)布時(shí)間
本來(lái)，計(jì)劃今年發(fā)布的3.11版本也是按照這個(gè)節(jié)奏進(jìn)行，但這次，3.11版本的發(fā)布會(huì)成為一個(gè)例外。值得一提的是，在郵件的最后，Pablo對(duì)能否在12月發(fā)布穩(wěn)定版本也沒(méi)有信心。
圖片來(lái)源@郵件截圖
Python 3.11期待已久
雖然Python簡(jiǎn)單易學(xué)，但其運(yùn)行速度之慢歷來(lái)被詬病（在每次的編程語(yǔ)言速度競(jìng)賽中，Python的名次通常都?jí)|底），因而很多開(kāi)發(fā)者期待這門(mén)語(yǔ)言的性能有所提升。
也許正是這個(gè)原因，Python創(chuàng)始人Guido van Rossum重新出山后，在2021年P(guān)ython語(yǔ)言峰會(huì)上作了一場(chǎng)《Making CPython Faster》的分享，他表示，自己已經(jīng)投入了“香農(nóng)計(jì)劃”（“Shannon Plan”，得名于提出者M(jìn)ark Shannon），期望花4年時(shí)間把Python提速5倍，即每年1.5倍，其中近期計(jì)劃是在Python 3.11 版本中實(shí)現(xiàn)至少提速1倍。
根據(jù)7月6日發(fā)布的Python 3.11.0b3來(lái)看，在Ubuntu Linux上使用GCC編譯，且使用pyperformance基準(zhǔn)套件測(cè)量時(shí)，CPython 3.11比CPython 3.10平均快25%。根據(jù)工作負(fù)載的不同，CPython 3.11的提速介于10% 到 60% 之間。
圖片來(lái)源@文檔截圖
此外，由于Python3.11是一個(gè)較大版本更新，根據(jù)已有的測(cè)試結(jié)果看，其在更精確的錯(cuò)誤提示、類(lèi)型特性、用except*處理多個(gè)異常、Zero-cost異常、改進(jìn)類(lèi)型（包括改進(jìn)類(lèi)型、任意的字符串字面類(lèi)型、數(shù)據(jù)類(lèi)轉(zhuǎn)換、標(biāo)準(zhǔn)庫(kù)中的 TOML 只讀支持等）也有改進(jìn)，這些也是開(kāi)發(fā)者比較期待的新功能。
如何給Python“踩踩油門(mén)”
此前Python為何會(huì)給大家留下運(yùn)行速度慢的印象呢？通常有三種解釋。
第一種解釋為Python是動(dòng)態(tài)性語(yǔ)言不是靜態(tài)性語(yǔ)言。
對(duì)C等靜態(tài)語(yǔ)言來(lái)說(shuō)，編譯器在聲明變量的時(shí)候就知道其類(lèi)型了；而對(duì)Python來(lái)說(shuō)，Python程序在執(zhí)行的時(shí)候，編譯器不知道變量的類(lèi)型，只知道它是一個(gè)對(duì)象。這意味著，即使是a+b這樣的簡(jiǎn)單二元運(yùn)算，由于變量a和b本身都沒(méi)有類(lèi)型，而它們的值有類(lèi)型，Python執(zhí)行起來(lái)也很“麻煩”：在相“加”之前，必須先判斷類(lèi)型。
第二種解釋是Python是解釋性語(yǔ)言而不是編譯性語(yǔ)言。
像C、C++、Rust這些語(yǔ)言是直接編譯成機(jī)器碼運(yùn)行，是編譯型語(yǔ)言；Python的運(yùn)行過(guò)程是虛擬機(jī)讀入Python代碼（文本），詞法分析，編譯成虛擬機(jī)認(rèn)識(shí)的opcode，然后虛擬機(jī)解釋opcode執(zhí)行，而最后這一步“虛擬機(jī)解釋opcode執(zhí)行”是比較費(fèi)時(shí)間的。
第三種解釋認(rèn)為，是全局解釋器鎖(GIL，Global Interpreter Lock)的原因。
現(xiàn)代計(jì)算機(jī)處理器一般都會(huì)有多核，甚至有些服務(wù)器有多個(gè)處理器。所以操作系統(tǒng)抽象出 Thread，可以在一個(gè)進(jìn)程中spawn出多個(gè)Thread，讓這些Thread在多個(gè)核上面同時(shí)運(yùn)行，發(fā)揮處理器的最大效率。
而Python自帶垃圾回收程序，且選擇的實(shí)現(xiàn)垃圾回收機(jī)制是引用計(jì)數(shù)+分代回收，并以引用計(jì)數(shù)為主。在多線程情況下，大家一起運(yùn)行，引用計(jì)數(shù)多個(gè)線程一起操作，為保證不發(fā)生線程不安全的事情，多個(gè)線程操作同一個(gè)對(duì)象需要加鎖。這就是GIL，只不過(guò)這個(gè)鎖的粒度太大了，整個(gè)Python解釋器全局只有一個(gè)Thread可以運(yùn)行。
換句話說(shuō)，無(wú)論電腦CPU有多少核，對(duì)Python來(lái)說(shuō)，它只用一個(gè)核。這三種解釋都有一定道理，理論上Python提速可以從以上三個(gè)方向進(jìn)行突破。從最近Python團(tuán)隊(duì)公布的情況看，Python 3.11 的性能改進(jìn)主要集中在更快的啟動(dòng)和更快的運(yùn)行時(shí)，這些優(yōu)化大部分來(lái)自于PEP 659（一種自適應(yīng)解釋器），它運(yùn)作思路跟JIT有點(diǎn)相似，都是識(shí)別熱點(diǎn)代碼，但自適應(yīng)解釋器的工作范圍無(wú)法脫離字節(jié)碼。
圖片來(lái)源@文檔截圖
3.11為何會(huì)推遲發(fā)布
從Pablo在郵件中公布的信息看，Python 3.11推遲發(fā)布主要是由于出現(xiàn)很多“影響發(fā)布”的bug。
圖片來(lái)源@GitHub截圖
雖然bug的細(xì)節(jié)還有待進(jìn)一步發(fā)掘，但根據(jù)現(xiàn)有情況猜測(cè)，問(wèn)題可能在以下的兩方面。
一是C擴(kuò)展的問(wèn)題。CPython與C的簡(jiǎn)單接口是主要優(yōu)勢(shì)，而與C擴(kuò)展的不兼容性則是一大槽點(diǎn)。CPython團(tuán)隊(duì)在CPython 3.11中所做的優(yōu)化工作在很大程度上忽略了擴(kuò)展模塊的問(wèn)題，對(duì)此，團(tuán)隊(duì)領(lǐng)導(dǎo)者香農(nóng)表示，團(tuán)隊(duì)正在開(kāi)辟將低級(jí)函數(shù)API暴露給虛擬機(jī)的可能性，以盡可能地減少Python代碼和C代碼。
二是前面反復(fù)提到的提速問(wèn)題。Python創(chuàng)始人Guido van Rossum預(yù)期Python 3.11版本中實(shí)現(xiàn)至少提速1倍，而目前Python 3.11.0b3比Python 3.10平均只快了25%，跟理想目標(biāo)還有不小的差距。
另外，Meta開(kāi)發(fā)人員Sam Gross在今年的Python語(yǔ)言峰會(huì)上，向與會(huì)者介紹了nogil的情況，這是一個(gè)專(zhuān)注于移除GIL的項(xiàng)目，據(jù)Python基金會(huì)介紹，Gross 將發(fā)明一種新型鎖，如果順利的話，這個(gè)新鎖很可能在Python 3.12版本亮相。
Sam Gross的提案雖然讓很多開(kāi)發(fā)者興奮，但與Python團(tuán)隊(duì)的現(xiàn)在工作基于PEP 659進(jìn)行優(yōu)化的工作會(huì)產(chǎn)生沖突：畢竟CPython團(tuán)隊(duì)已實(shí)施的優(yōu)化，很大一部分都基于GIL仍存在的前提。如果采用Sam Gross的提案，在Python 3.12去除GIL，那么Python 3.11就要做出不小的改動(dòng)，也許，這也是導(dǎo)致Python 3.11延期的重要原因。
總之，考慮到當(dāng)前Python在編程語(yǔ)言界“如日中天”的地位，Python 3.11又志在克服其最大的缺點(diǎn)，Python的未來(lái)還是很值得期待的。
參考鏈接：
https://mail.python.org/archives/list/python-dev@python.org/thread/3JWVCSBPBFWY5ZWSJ7RYB6FS5NIMCEOY/
https://docs.python.org/zh-cn/3.11/whatsnew/3.11.html#faster-cpython
