關於 pyright#
PEP 484,出來也快四年了。正好今天看到一個新庫,寫個短文,安利下 & 吐槽下。
關於 PEP 484#
PEP 484,14 年正式提出,15 年正式接納,成為 Python 3.5 以後的標準的一部分。簡而言之是通過額外的語法,來為 Python 引入靜態類型檢查的例子
舉個簡單例子
def return_callback(flag: bool, callback: typing.Callable[[int, int], int])-> int:
if not flag:
return None
return callback(1, 2)
我們通過這樣的類型靜態標註,來增加可讀性以及靜態檢查的能力。具體內容,可以參看我去年在 BPUG 上的分享的 slide。我最近也會抽出時間,詳細聊聊 Type Hint 的前世今生(flag+1)
靜態檢查#
靜態檢查的意義在於,能及時發現低級錯誤,及時檢查,可以很方便的集成進 CI 或者 Git Hook 中
舉個簡單例子
目前而言,主流的靜態檢查工具有兩種
mypy 目前的問題有:
-
性能較差
-
對於新特性接入持保守態度
所以後續 Google 選擇了推出自己的靜態檢查方案 pytype ,其性能相對於 mypy 來講,性能和易用性也有了比較大的提升,
而目前,“開源急先鋒 “微軟也在今天推出了自己的靜態檢查工具 pyright。目前在保證了對 Type Hint 周邊特性兼容的情況下,宣稱性能相較於 mypy 有 5 倍的提升
而這對於大項目的 CI 來講是一個極大的利好
不過目前,關於 pyright 的潛在風險點可能還有這樣的問題
-
基於 TypeScript 開發,運行環境基於 node,這可能會帶來 CI 集成的難度。
-
易用性和可靠性還存在不足
-
可能和 IDE 編輯器等配套的插件不足(官方也說,目前 VSCode 的插件還在開發中)
不過,pyright 還是值得大家在私下嘗鮮的。後續我也會嘗試閱讀下 pyright 的實現,看看微軟的實現思路(flag+2)
嗯,本文就到這裡,這應該是我寫過最水的文章了。