關於 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)
嗯，本文就到這裡，這應該是我寫過最水的文章了。