PyreflyとTy: Pythonの2つの新しいRustベースの型チェッカーを比較する

2025年5月28日原文(blog.edward-li.com)

概要

Pyrefly と ty は新しいRust製Python型チェッカー
どちらも従来の mypy や pyright より高速
速度・設計思想・インクリメンタル処理・型推論に違い
それぞれMetaとAstralが開発、オープンソース指向
まだアルファ版、今後の進化に期待

Pyreflyとty：新世代Rust製Python型チェッカー比較

2025年PyCon Typing Summitで Pyrefly （Meta製）と ty （Astral製）が公式初披露
どちらも Rust で開発され、従来のPython型チェッカー（ mypy、 pyright 等）より高速
Pyrefly はMetaの旧型チェッカーPyre（OCaml製）の後継
- Pyreより 35倍高速、mypy/pyrightより 14倍高速、1.8M行/秒対応
- オープンソースコミュニティと積極的に連携
ty はAstral（uvやruff開発元）が開発
- 旧名Red-Knot、現在はtyとして展開
- 公開は控えめだが、 1～2桁高速 を目標
両者とも Ruff をASTパーサとして採用
CLI型チェックとLSP/IDE統合に対応
共通点は高速なRust実装だが、設計思想や細部で違い

速度比較ベンチマーク

PyTorch リポジトリ全体・torchサブディレクトリでテスト
- tyがpyreflyの 2～3倍高速、mypy/pyrightの 10～20倍高速
- 検出ファイル数に差（pyrefly:約8600、ty:約6500）
Django 5.2.1 でも同様の傾向
- ty: 0.6秒（2900ファイル）、pyrefly: 0.9秒（3200ファイル）、pyright: 16秒
mypyリポジトリ （mypy/mypyc）でも
- ty: 74ms、pyrefly: 136ms、mypy: 3.5秒、pyright: 2.8秒

設計思想・目標

Pyrefly ：型推論を最大限活用し、明示的型なしでも型保証を目指す
ty ：「グラジュアル保証」重視
- 型アノテーションを外しても型エラーが発生しない設計
- 例：属性にNoneを代入後、intを代入してもエラーにならない（Unknown型導入）
Pyrefly は推論が積極的な分、エラー検出も多い

インクリメンタル処理の違い

Pyrefly ：独自エンジンで モジュール単位 インクリメンタル型チェック
- ファイル単位で再パース、Rustの高速性で十分と判断
ty ： Salsa （Rust Analyzer同様）で 関数単位 の微細なインクリメンタル型チェック
- 依存関数のみ再パース、より細かい最適化

機能・型推論の違い

どちらも アルファ版、機能は発展途上
Pyrefly は暗黙的型推論に強み
- 明示的型指定なしでも複雑な型推論が可能
ty は「Unknown」型で柔軟性重視
- Anyとの違いを明確化、型安全性と利便性のバランス
- 例: my_list = [1, "b", None] の場合
  - pyrefly: int | str | Noneと推論し、val * 2でエラー
  - ty: Unknown型で柔軟に対応、エラーなし
  - mypy, pyright: objectやUnknown型で曖昧な挙動

まとめと今後

Pyrefly は積極的な型推論・高速性・コミュニティ連携重視
ty はグラジュアル保証・極細粒度インクリメンタル・柔軟性重視
どちらも従来型チェッカーより 圧倒的な速度 と 新しい設計思想 を提示
まだ アルファ版 のため、今後の機能追加・安定化に期待

Hackerたちの意見

tyは、別のマントラに従っている: 漸進的保証。基本的なアイデアは、型付けがしっかりしたプログラムでは、型アノテーションを削除しても型エラーが発生しないということ。つまり、動作しているコードに新しい型を追加して型エラーを解決する必要はないってこと。Tyが提供する漸進的保証は面白いね。それを試してみようかと思ってる。Pythonみたいな既存の動的コードベースを持つ言語では、漸進的型付けをするのにちょうどいい方法に思える。

└

グリーンフィールドでない限り、漸進的型付けが唯一の方法だよね。いくつかのレガシーPythonコードベースにmypyを使って型ヒントを組み込んだけど、実際に賢い方法はモジュールごとに「オプトイン」することだけだと思う。もしpyreflyがそれをサポートしないなら、使い道はかなり限られると思う。もしかしたら、llmコード生成の方向を狙ってるのかもしれないけど。llmがPythonスクリプトを生成するための、すごく速くて厳密な型チェッカーが役立つのは見えるな。

└

これは、Typescriptの初期の頃を思い出させるね。既存の大規模プロジェクトにスムーズに導入することに焦点を当てていたから。より制約のある要件（例えばnoImplicitAny）は、一つずつオンにできて、最終的にstrictスイッチを切り替えてすべてのチェックにオプトインすることができた。

└

漸進的型付けって、コードベースのどこにでもある暗黙の「any」（不明な型）がエラーでも警告でもないってことなんだ。完全に型付けされてると思ってた重要なコードでもね。間違って型バグを導入して、文法や推論の制限で型チェッカーが予期せずにおかしくなって、「このファイルに問題はありません！」って自信満々に言ってくるのが理解できるけど、私がmypyを試したときの最終的な問題は、型からの保護を実際に保証する方法がなかったこと。「このファイルには漸進性はない、完全に型付けされてる！」って主張する方法が重要だけど、漸進的型付けは移行だけじゃなくて、動的言語でできるクレイジーなことや、静的型付けを重視しない人を怖がらせる誤検知の恐怖とも関係してる。もしかしたら「ソフト」型付けって呼ぶ方が分かりやすいかも。今のところ、漸進的型付けはアンチパターンだと思う。

└

Pythonを書くためにお金をもらっているけど、Rustプログラマーだと思っているし、徐々に保証される方が理にかなっていると思う。

└

これ、私にはすごく嫌だな。Pythonに型アノテーションを追加する半分の目的は、エラーが起きやすい動的型付けを抑えることなんだよね。Pythonが許可しているからって、バカなことをした時に気づかないのは嫌だ。だから、動かすコードを大事にする人のために、暗黙のAnyを使わないモードとか「厳格モード」を追加してほしいな。

どこかの型チェッカーが本格的なノートブック統合を始めてくれるといいな。ライブコーディングのための統合で、ノートブックを静的にチェックするバッチスクリプトだけじゃなくて。1〜60分のセルを実行する前に型でエラーを見つけられるのは大きな勝利だよ。

└

VSCodeでJupyterノートブック使ってる？普通のPythonファイルと同じpylanceを使うから、使い捨てコードを書くときにはちょっとイライラするんだよね。

└

他のレスに同意だね。VSCodeのノートブックを使って静的型チェックをするべきだよ。言語サーバーは、ノートブックの統合や「ライブコーディング」を含めて、まさに君が求めていることをやってくれるんだ。

my_list = [1, 2, 3] > pyrefly、mypy、pyrightは、my_list.append("foo")が型エラーだと仮定してるけど、技術的には許可されてる（Pythonのコレクションは複数の型のオブジェクトを持てるから！） > もしこれが意図された動作なら、tyはmy_listに追加の明示的な型付けを要求せずに暗黙的にこれを許可する唯一のチェッカーだね。EDIT: 私のコメントがこんなに厳しくなるつもりはなかったんだけど、実はtyが成功することを応援してるよ :) ORIGINAL: ここでのtyの動作には強く反対だよ。プロダクションコードではほぼ常に単一型のリストがあって、型チェッカーがこれを前提にすることが重要なんだ。特にリストが同じ型のリテラルアイテムを既に持っている場合はね。Pythonがこれを許可していることは全く関係ない。私にとって、型チェッカーがlist[int | str]を暗黙的に許可するのは、初心者レベルのコードを最適化してるように思える。

└

初心者向けのコードを最適化してるとは思わないな。むしろ、レガシーコードの最適化をしてる感じ。大規模な未型付けのコードベースに型チェッカーを導入するのは大変だけど、既存のコードのほとんどが受け入れられれば、負担は少なくなるよね。

└

そして、型チェッカーがこれを前提とすることは重要です。でも、なんでそれが重要なの？もし list[int] が必須なら、そこでは型エラーが出るべきだと思うけど。

Hacker Newsで議論の続きを見る

ハクソク