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