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）。
さて、この記事はここまでです。おそらく私が書いた中で最も水っぽい記事です。