關於 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 中

舉個簡單例子

目前而言，主流的靜態檢查工具有兩種

1. Python 官方和 484 配套出的 mypy

2. Google 出的 pytype

mypy 目前的問題有：

1. 效能較差

2. 對於新特性接入持保守態度

所以後續 Google 選擇了推出自己的靜態檢查方案 pytype ，其效能相對於 mypy 來講，效能和易用性也有了比較大的提升，

而目前，“開源急先鋒“微軟也在今天推出了自己的靜態檢查工具 pyright 。目前在保證了對 Type Hint 周邊特性相容的情況下，宣稱效能相較於 mypy 有5倍的提升

而這對於大專案的 CI 來講是一個極大的利好

不過目前，關於 pyright 的潛在風險點可能還有這樣的問題

1. 基於 TypeScript 開發，執行環境基於 node，這可能會帶來 CI 整合的難度。

2. 易用性和可靠性還存在不足

3. 可能和 IDE編輯器等配套的外掛不足（官方也說，目前 VSCode 的外掛還在開發中）

不過，pyright 還是值得大家在私下嚐鮮的。後續我也會嘗試閱讀下 pyright 的實現，看看微軟的實現思路（flag+2)

嗯，本文就到這裡，這應該是我寫過最水的文章了。