你不會在 Python 中看到的 4 個有用的特性
譯文
以下是目前 Python 中沒有的四種常用語言特性。其中至少有兩個永遠不會有，而其他的最多是幾年后的事。我們將看看是什么阻礙了這些特性的實現，或者說要在未來的Python版本中包含它們需要做些什么。
不會有的：一個靜態類型的編譯版 Python
一些開發者夢想著一個使用靜態類型的 Python 來編譯本地機器代碼。畢竟，靈活的類型是造成 Python 緩慢的根源，而靜態類型將結束這種狀況。靜態類型也為程序員提供了強有力的保證，使他們能夠從他們的代碼中得到想要的結果。那么，問題出在哪里呢？
雖然 Python 確實有類型提示，但它們的目的是在編輯時通過提示工具使語言更適合于靜態分析。只有第三方項目（比如pydantic）在運行時使用類型提示。Python 運行時本身并不使用類型提示。
在PEP 484中，即Python類型提示的增強建議中，有一個明確的目標是讓類型提示永遠是可選的。"Python 仍將是一種動態類型化的語言，作者不希望將類型提示變成強制性的，即使按照慣例也是如此。"
真正想要靜態類型的Python版本的開發者可以轉向Cython或mypyc，但即使是這些項目也是有代價的。在Cython中，最大的性能提升來自于使用純C類型和結構，以及減少對Python運行時的使用。簡單地說，在不犧牲Python的動態性的情況下，很難讓它編譯得更快。把不需要動態性的部分分離出來，然后提高它們的速度，這要容易得多。
不會有的：多行lambdas
Python 的 lambda 表達式，或者說匿名函數，是有限制的。它們只允許一個表達式 (本質上，在賦值操作中 = 符號右邊的任何東西) 作為函數體。從JavaScript這樣的語言來到Python的開發者，在那里多行匿名函數是常態，他們經常要求在Python中實現這一功能。
Python 的創造者 Guido van Rossum 很久以前就否定了 lambda 除了是單一表達式的語法糖之外的任何想法。他的立場在2006年的一封電子郵件中得到了最好的概括，在那里他討論了為什么多行lambdas在Python中沒有也不會成為一種東西。
多行lambdas幾乎沒有給Python增加任何實際的能力或表現力，而且會以使它成為一種可讀性較差的語言為代價。(可讀性是Python的首要問題)。
目前還沒有提供可用的語法，可以與Python的白色空間敏感設計的其他部分優雅地整合。
將多行lambda轉換成一個完整的函數幾乎不費吹灰之力，反正van Rossum建議將其作為 "多行lambda "方案的使用情況。
不用說，Python中多行lambdas的前景并不光明。
不太可能有的：一個沒有 GIL 的 Python
全局解釋器鎖，或稱 GIL，長期以來一直是 Python 愛好者的眼中釘、肉中刺。GIL 在 Python 運行時中同步活動，以序列化對對象的訪問并管理全局狀態。GIL 的缺點是，它使 Python 運行時在實踐中成為單線程。如果你想要真正的線程并行，你需要啟動不連續的 Python 解釋器副本，并在每個副本上運行獨立的線程。從理論上講，沒有 GIL 的 Python 可以允許更大的并行性，從而提高性能。那么，為什么它不太可能呢？
已經有各種建議要從 Python 中移除 GIL。大多數建議會破壞向后的兼容性，或者使Python在單線程操作中變得更慢，或者兩者兼而有之。其中一項努力，即 "GILectomy "項目帶來了嚴重的性能損失。Python 3.x 對 GIL 進行了重做，以提高其基準性能，但為了保持向后的兼容性，并沒有刪除它。
由于這些問題，GIL 可能只是 Python 用戶生活中的一個事實。但是有可能改善它的性能。在Python運行時間中允許更好的并行性的一種方法是在一個進程中運行多個解釋器。要使這個建議成為現實，需要對Python的內部進行重大修改，包括重做Python的部分C API。許多第三方模塊都依賴于C API，因此也需要更新。
一個較新的提議，PEP 684，擴展了多解釋器的概念，讓每個子解釋器使用自己的GIL。在這種情況下，提議的改變也將允許戰略性地共享需要在子解釋器之間共享的對象。
或許會有的：一個Python原生JIT編譯器
在保持Python語言所特有的靈活性的同時，有一個行之有效的方法是使用一個即時編譯器，或者叫JIT。JIT 編譯包括在運行時分析代碼，而不是提前分析，并根據它在運行時表現出來的行為有選擇地或完全地編譯成機器代碼。
Python已經存在JIT。PyPy是最常用和發展最好的例子，它擅長在不修改程序源代碼的情況下使長期運行的、服務器式的應用程序提供更好的性能。但是Python的參考版本CPython會不會從某種JIT中受益呢？
最近在2021年Python語言峰會上討論的使Python更快的倡議，產生了一些類似的建議。目前的建議不是在Python中實現一個完整的JIT，而是在解釋器中加入自適應行為，以便在常見的特殊情況下加快執行速度。未來可能還有其他類型的JIT類型的專業化的空間，比如為真正的高速代碼路徑生成機器碼。但近期的計劃是對現有的解釋器進行擴展，而不是取代它。
