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