pyright について#
PEP 484は、もう 4 年近く前に提案されました。ちょうど今日、新しいライブラリを見つけたので、短い記事を書いて紹介しましょう。
PEP 484 について#
PEP 484は、2014 年に正式に提案され、2015 年に正式に採用され、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 でのプレゼンテーションのスライドを参照してください。最近、私も時間を作って、Type Hint の歴史について詳しく話す予定です（flag+1）。
静的なチェック#
静的なチェックの意義は、低レベルのエラーを早期に発見することです。早期のチェックは、CI や Git フックに簡単に統合することができます。
簡単な例を挙げます。
現在、主流の静的チェックツールは 2 つあります。
mypyの現在の問題点は次のとおりです。
-
パフォーマンスが低い
-
新機能の導入に保守的な姿勢を持っている
そのため、Google は独自の静的チェックソリューションであるpytypeを開発しました。mypy に比べてパフォーマンスと使いやすさが大幅に向上しています。
そして、今日、"オープンソースの先駆者" である Microsoft も自社の静的チェックツールpyrightを発表しました。Type Hint の周辺機能の互換性を確保しながら、mypy に比べて 5 倍のパフォーマンス向上を宣言しています。
これは大規模プロジェクトの CI にとって非常に大きな利点です。
ただし、pyright の潜在的なリスクには次のような問題があるかもしれません。
-
TypeScript で開発され、実行環境は node に基づいているため、CI の統合に困難をもたらす可能性があります。
-
使いやすさと信頼性にまだ改善の余地があります。
-
IDE エディタなどの関連プラグインが不足しているかもしれません（公式によれば、現在、VSCode のプラグインは開発中です）。
ただし、pyright は個人的に試してみる価値があります。私も後日、pyright の実装を読んで、Microsoft のアプローチを見てみる予定です（flag+2）。
さて、この記事はここまでです。おそらく私が書いた中で最も水っぽい記事です。