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

不會有的：一個靜態(tài)類型的編譯版 Python

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

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

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

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

不會有的：多行l(wèi)ambdas

Python 的 lambda 表達式，或者說匿名函數(shù)，是有限制的。它們只允許一個表達式 (本質(zhì)上，在賦值操作中 = 符號右邊的任何東西) 作為函數(shù)體。從JavaScript這樣的語言來到Python的開發(fā)者，在那里多行匿名函數(shù)是常態(tài)，他們經(jīng)常要求在Python中實現(xiàn)這一功能。

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

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

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

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

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

不太可能有的：一個沒有 GIL 的?Python

全局解釋器鎖，或稱 GIL，長期以來一直是 Python 愛好者的眼中釘、肉中刺。GIL 在 Python 運行時中同步活動，以序列化對對象的訪問并管理全局狀態(tài)。GIL 的缺點是，它使 Python 運行時在實踐中成為單線程。如果你想要真正的線程并行，你需要啟動不連續(xù)的 Python 解釋器副本，并在每個副本上運行獨立的線程。從理論上講，沒有 GIL 的 Python 可以允許更大的并行性，從而提高性能。那么，為什么它不太可能呢？

已經(jīng)有各種建議要從 Python 中移除 GIL。大多數(shù)建議會破壞向后的兼容性，或者使Python在單線程操作中變得更慢，或者兩者兼而有之。其中一項努力，即 "GILectomy "項目帶來了嚴重的性能損失。Python 3.x 對 GIL 進行了重做，以提高其基準性能，但為了保持向后的兼容性，并沒有刪除它。

由于這些問題，GIL 可能只是 Python 用戶生活中的一個事實。但是有可能改善它的性能。在Python運行時間中允許更好的并行性的一種方法是在一個進程中運行多個解釋器。要使這個建議成為現(xiàn)實，需要對Python的內(nèi)部進行重大修改，包括重做Python的部分C API。許多第三方模塊都依賴于C API，因此也需要更新。

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

或許會有的：一個Python原生JIT編譯器

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

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

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