以下是目前 Python 中沒有的四種常用語言特性。其中至少有兩個(gè)永遠(yuǎn)不會(huì)有，而其他的最多是幾年后的事。我們將看看是什么阻礙了這些特性的實(shí)現(xiàn)，或者說要在未來的Python版本中包含它們需要做些什么。

暫時(shí)不會(huì)出現(xiàn)的：一個(gè)靜態(tài)類型的編譯版 Python

一些開發(fā)者夢想著一個(gè)使用靜態(tài)類型的 Python 來編譯本地機(jī)器代碼。畢竟，靈活的類型是造成 Python 緩慢的根源，而靜態(tài)類型將結(jié)束這種狀況。靜態(tài)類型也為程序員提供了強(qiáng)有力的保證，使他們能夠從他們的代碼中得到想要的結(jié)果。那么，問題出在哪里呢？

雖然 Python 確實(shí)有類型提示，但它們的目的是在編輯時(shí)通過提示工具使語言更適合于靜態(tài)分析。只有第三方項(xiàng)目（比如pydantic）在運(yùn)行時(shí)使用類型提示。Python 運(yùn)行時(shí)本身并不使用類型提示。

在PEP 484中，即Python類型提示的增強(qiáng)建議中，有一個(gè)明確的目標(biāo)是讓類型提示永遠(yuǎn)是可選的。"Python 仍將是一種動(dòng)態(tài)類型化的語言，作者不希望將類型提示變成強(qiáng)制性的，即使按照慣例也是如此。"

真正想要靜態(tài)類型的Python版本的開發(fā)者可以轉(zhuǎn)向Cython或mypyc，但即使是這些項(xiàng)目也是有代價(jià)的。在Cython中，最大的性能提升來自于使用純C類型和結(jié)構(gòu)，以及減少對Python運(yùn)行時(shí)的使用。簡單地說，在不犧牲Python的動(dòng)態(tài)性的情況下，很難讓它編譯得更快。把不需要?jiǎng)討B(tài)性的部分分離出來，然后提高它們的速度，這要容易得多。

暫時(shí)不會(huì)出現(xiàn)的：多行l(wèi)ambdas

Python的 lambda 表達(dá)式，或者說匿名函數(shù)，是有限制的。它們只允許一個(gè)表達(dá)式 (本質(zhì)上，在賦值操作中 = 符號(hào)右邊的任何東西)

作為函數(shù)體。從JavaScript這樣的語言來到Python的開發(fā)者，在那里多行匿名函數(shù)是常態(tài)，他們經(jīng)常要求在Python中實(shí)現(xiàn)這一功能。

Python的創(chuàng)造者 Guido van Rossum 很久以前就否定了 lambda，除了是單一表達(dá)式的語法糖之外的任何想法。他的立場在2006年的一封電子郵件中得到了最好的概括，在那里他討論了為什么多行l(wèi)ambdas在Python中沒有也不會(huì)成為一種東西。

多行l(wèi)ambdas幾乎沒有給Python增加任何實(shí)際的能力或表現(xiàn)力，而且會(huì)以使它成為一種可讀性較差的語言為代價(jià)。(可讀性是Python的首要問題)。

目前還沒有提供可用的語法，可以與Python的白色空間敏感設(shè)計(jì)的其他部分優(yōu)雅地整合。

將多行l(wèi)ambda轉(zhuǎn)換成一個(gè)完整的函數(shù)幾乎不費(fèi)吹灰之力，反正van Rossum建議將其作為 "多行l(wèi)ambda "方案的使用情況。

不用說，Python中多行l(wèi)ambdas的前景并不光明。

不太可能有的：一個(gè)沒有 GIL的Python全局解釋器鎖，或稱GIL，長期以來一直是 Python 愛好者的眼中釘、肉中刺。GIL 在 Python

運(yùn)行時(shí)中同步活動(dòng)，以序列化對對象的訪問并管理全局狀態(tài)。GIL 的缺點(diǎn)是，它使 Python

運(yùn)行時(shí)在實(shí)踐中成為單線程。如果你想要真正的線程并行，你需要啟動(dòng)不連續(xù)的 Python 解釋器副本，并在每個(gè)副本上運(yùn)行獨(dú)立的線程。從理論上講，沒有

GIL 的 Python 可以允許更大的并行性，從而提高性能。那么，為什么它不太可能呢？

已經(jīng)有各種建議要從Python 中移除 GIL。大多數(shù)建議會(huì)破壞向后的兼容性，或者使Python在單線程操作中變得更慢，或者兩者兼而有之。其中一項(xiàng)努力，即"GILectomy "項(xiàng)目帶來了嚴(yán)重的性能損失。Python 3.x 對 GIL進(jìn)行了重做，以提高其基準(zhǔn)性能，但為了保持向后的兼容性，并沒有刪除它。由于這些問題，GIL可能只是 Python用戶生活中的一個(gè)事實(shí)。但是有可能改善它的性能。在Python運(yùn)行時(shí)間中允許更好的并行性的一種方法是在一個(gè)進(jìn)程中運(yùn)行多個(gè)解釋器。要使這個(gè)建議成為現(xiàn)實(shí)，需要對Python的內(nèi)部進(jìn)行重大修改，包括重做Python的部分CAPI。許多第三方模塊都依賴于C API，因此也需要更新。

一個(gè)較新的提議，PEP 684，擴(kuò)展了多解釋器的概念，讓每個(gè)子解釋器使用自己的GIL。在這種情況下，提議的改變也將允許戰(zhàn)略性地共享需要在子解釋器之間共享的對象。

或許會(huì)有的：一個(gè)Python原生JIT編譯器

在保持Python語言所特有的靈活性的同時(shí)，有一個(gè)行之有效的方法是使用一個(gè)即時(shí)編譯器，或者叫JIT。JIT 編譯包括在運(yùn)行時(shí)分析代碼，而不是提前分析，并根據(jù)它在運(yùn)行時(shí)表現(xiàn)出來的行為有選擇地或完全地編譯成機(jī)器代碼。

Python已經(jīng)存在JIT。PyPy是最常用和發(fā)展最好的例子，它擅長在不修改程序源代碼的情況下使長期運(yùn)行的、服務(wù)器式的應(yīng)用程序提供更好的性能。但是Python的參考版本CPython會(huì)不會(huì)從某種JIT中受益呢？

最近在2021年P(guān)ython語言峰會(huì)上討論的使Python更快的倡議，產(chǎn)生了一些類似的建議。目前的建議不是在Python中實(shí)現(xiàn)一個(gè)完整的JIT，而是在解釋器中加入自適應(yīng)行為，以便在常見的特殊情況下加快執(zhí)行速度。未來可能還有其他類型的JIT類型的專業(yè)化的空間，比如為真正的高速代碼路徑生成機(jī)器碼。但近期的計(jì)劃是對現(xiàn)有的解釋器進(jìn)行擴(kuò)展，而不是取代它。

以上為本次分享的全部內(nèi)容，如果對編程想獲得更多了解，請前往六星源課堂，開啟你的編程之旅~