Pythonの新たなRust製型チェッカー、PyreflyとTyを比較
(blog.edward-li.com)- 最近、MetaのPyreflyとAstralのTyという2つのRust製Python型チェッカーが公開され、既存のmypyやpyrightと比べて圧倒的な性能と新しいタイピングのパラダイムを示している
- Pyreflyは積極的な型推論とオープンソース志向を掲げ、Tyは「gradual guarantee」の原則を導入して、型エラーの発生を最小限に抑えることに重点を置いている
- どちらのツールも初期アルファ版だが、さまざまなプロジェクトでのベンチマーク結果では、平均してTyのほうが高速な実行速度を記録している
- インクリメンタル解析では、Pyreflyはモジュール単位、Tyは関数ターゲット単位のより細かな増分化を提供しており、使い勝手や構造が異なる
- Tyは交差型と否定型など革新的な型システムを示し、より直感的で明快なエラーメッセージを提供する
PyreflyとTyの紹介
- PyreflyとTyはRustで開発されたPython型チェッカー
- PyreflyはMeta（旧Facebook）が開発し、既存のOCaml製Pyreを置き換える
- TyはAstralが開発しており、AstralはuvやruffなどのPythonツールで知られている
- 両プロジェクトともオープンソースとして公開されているが、まだ正式リリース前のアルファ段階にある
- 両チームはPyCon 2025 Typing Summitで、それぞれのビジョン、目標、アプローチを紹介した
共通点
- どちらもRustで開発されており、インクリメンタル解析（Incremental Checking）をサポートする
- PythonコードのAST解析にはruffを活用している
- コマンドラインでの型検査やLSP/IDE統合対応など、開発環境との連携にも優れている
相違点 1: 速度
PyTorchベンチマーク
- TyはPyreflyより約2〜3倍高速で、どちらも既存のmypy、pyrightより10〜20倍高速
- PyreflyはPyre比で35倍、mypy/pyright比で14倍の性能向上を目標としている
- Tyは現世代の型チェッカーより1〜2桁高速な性能を目標に設計されている
Djangoベンチマーク
- Tyが最速で、Pyreflyがそれに続く
- Pyrightは明らかに遅い結果となっている
mypyリポジトリのベンチマーク
- 同様の結果で、Tyが最速、Pyreflyがわずかな差で後に続く
- mypyとpyrightは著しく遅い実行時間を記録している
相違点 2: タイピングの目標
Pyrefly
- コードに明示的な型指定がなくても、可能な限り型を推論してエラーを捕捉する戦略を追求
- より積極的な型推論によってコードの安定性最大化を目指す
Ty
- **Gradual guarantee（段階的保証）**の原則を適用
- 動作するコードから明示的な型を取り除いても型エラーが発生しないよう設計されている
- 型アノテーションがなくてもエラーを起こさず、必要な場合にのみ追加のアノテーションを要求する
- 例: 明示的な型のないフィールドに値を代入しても型エラーにならず、
Unknown | Noneなどとして扱われる
相違点 3: インクリメンタル解析方式
- Pyrefly: 変更されたファイル（モジュール）と、その依存モジュールのみを再解析（モジュール単位の増分化）
- Ty: RustのSalsaフレームワークを活用し、関数単位まで細かい増分化を実現
- モジュール単位は十分に高速だという判断があり、関数単位はコードベースが複雑化する可能性がある（各ツールの戦略の違い）
相違点 4: 機能（型システムと対応範囲）
Pyreflyの長所
- 暗黙的な型推論が非常に強力
- 明示的な型がなくても、関数の戻り値、辞書、リストなど複雑な型を解析してエラーを検出できる
- ジェネリクス、オーバーロード、ワイルドカードimportなどの複雑なタイピング問題を重視して設計されている
- ジェネリック型推論の精度はTyより高い
Tyの特徴
- 「gradual guarantee」により、明示的な型がない場合でも型の変化を柔軟に許容する
- **交差型（Intersection Types）と否定型（Negation Types）**など、革新的な型システムをサポート
- エラーメッセージは非常に明確で直感的に設計されている
- リストなどへの多様な型の代入を柔軟に許容し、型の
Unknown値をシステムとして導入している
制約 / アルファ状態
- 両製品ともアルファ段階であり、型推論や一部機能は未完成
- たとえばTyのリスト型推論など、一部の結果は完成度がまだ十分ではない
詳細機能比較
暗黙的型推論
- Pyreflyは戻り値型やコレクションオブジェクトの型を能動的に推論し、revealed typeとエラーを明確に提示する
- Tyは推論が不十分な場合、
Unknownまたは@Todoを返す
ジェネリクス
- PyreflyとTyはいずれも一般的なジェネリック型の問題をうまく解決する
- Pyreflyは型パラメータなしで生成されたインスタンスの型解釈で優位性を持つ
- 両チェッカーとも**共変 / 反変（covariance / contravariance）**の問題では、mypyやpyrightに比べて弱さを見せる
エラーメッセージ
- Tyは簡潔で読みやすいエラーメッセージに重点を置く
- Pyrefly、mypy、pyrightと比べても一目で理解しやすいメッセージを提供する
交差型 / 否定型
-
Tyのみが**交差型（&）および否定型（~）**をサポートし、以下のような複雑な型演算を処理する
- 例:
WithX | Other型でx属性が存在するとき、Tyは自動的にWithXへ分岐する - 例: 特定のサブクラスではない場合、
MyClass & ~MySubclassとして型解釈する
- 例:
-
このような交差型と否定型は、型理論において非常に先進的な機能である
その他の高度な例
- Tyは型システムを使ってディオファントス方程式のような複合演算にも活用できる
- テストはMarkdown文書として記述されている（参照: Astral ruffのmdtestリソース）
結論と展望
- Pythonエコシステムに圧倒的に高速で新しい型チェッカーが登場した状況だ
- Tyは段階的な型安全性を、Pyreflyは能動的な型推論をそれぞれ主戦略としている
- どちらのツールも初期段階にあり、今後機能が収束したり進化したりする余地が大きい
- 公式サイトで試すことができ、VSCodeやCursorなど主要エディタ向けプラグインも提供されている
- 今後、GoogleもGo製の型チェッカーをオープンソース化する予定とのうわさもあり、Python型解析の分野はさらに豊かになりそうだ
活用 / 参考
- Pyrefly: pyrefly.org/sandbox
- Ty: play.ty.dev
- AstralのTyはMarkdownベースのテストを活用している（詳細なパスはruffリポジトリのmdtestを参照）
- 公式ドキュメント、エディタプラグイン、パッケージインストールコマンドもすべて提供されている
2件のコメント
ty は、使用している関数に戻り値の型が書かれていないと、無条件で
unknownになるようですね。保存して初めて確認してくれて、pyrefly は書かれていなくても推論してくれて、タイピング中にも確認してくれます
Hacker Newsの意見
tyの開発者として、tyとpyreflyが徐々に注目を集めていることを嬉しく思う立場を強調しつつ、両プロジェクトともまだ完成段階ではないことを改めて強調。未実装機能による例も見られており、「これはおかしい」と感じたとき、実はまだ開発されていない部分かもしれない点を理解してほしいとのこと。Pythonが非常に大きく多様な言語であることを認識する必要がある
tyのMarkdownスタイルのテスト方式が本当に気に入っているという意見。テストがドキュメントの役割まで果たすのは非常に優れたアイデアで、この方式の発想がRustの文書化されたコード例から着想を得たのか気になる
型を示す部分を
@TODOで表示した点に笑ったが、考えてみるとかなり気が利いていて便利な仕掛けだという感想TypeScript経験者として、型推論や型ナローイング、そして各Python型チェッカーごとに挙動が異なる点など、さまざまな試み自体に興味がある。依然として高速で信頼できる型チェッカーは絶対に必要だが、Pythonはこの面でかなり遅れている印象。型チェッカーはコードの生産性と信頼性を高めるべきだと考えており、こうしたプロジェクトを応援している
Rust開発者の観点から「Rust向けのスクリプト言語」に関する質問。Rustと文法の相性がよく、Rustの型をネイティブにインポートでき、素早くコンパイル／ホットリロードできる言語を研究しているコミュニティがあるのか気になる。あるいは、文法は違ってもPythonがその役割を代替できる可能性について意見を求めている。関連リンク添付 https://news.ycombinator.com/item?id=44050222
Python経験があまりない外部の視点からの意見。型ヒント活用に関心があるならRedditの投稿 https://www.reddit.com/r/Python/comments/10zdidm/why_type_hinting_sucks/ を参照することを勧める。その投稿を深刻に受け止めすぎるべきではないが、どれほど優れた型ツールがあっても、まず「良い慣行」が先だという点を強調。たとえばDjangoやMetaのような大規模コードベースで一貫した利用と厳格な型チェックを可能にするには、開発者に推奨される慣習を守らせる必要があるという点。PythonはC++のように機能が多すぎ、ランタイムも寛容なので、結局は一部だけを制限して使うほうが管理しやすい。しかし、その制限された部分が人や目的によって異なりうる点を指摘。より厳しい型システムを持ち込もうとするRust開発者がLinuxカーネル開発者と衝突する事例にも重ねている
そのReddit投稿の上位コメントでは、「
Anyを使えばよいので議論は無意味だ」といった形で一蹴しているが、実例でも、より明確な型宣言があればライブラリ関数の将来的な変更や予期しない入力値に対するエラーを事前に防げたはずだという点。Pythonコードが保守性と信頼性を持つには型チェックが必須だという強い主張Pythonの型チェックにあまりに多くの時間と労力をかけるより、いっそより適した静的型付け言語へ移行し、相互運用レイヤーとして必要な部分だけPythonを使うほうが良いという結論。常に可能とは限らないが、Pythonを無理やり合わせることに時間を浪費しがちだという悩み
Pythonの強力で複雑な機能群（例: meta class、descriptor、
__call__の使用、object.__new__、名前マングリング、self.__dict__）には魔法が入りすぎており、コードの可読性を大きく損なうという批判。個人的にはこうした機能は使わないと宣言実際にはその言語を使っていないのに意見を述べている点がどこから来るのか気になるという声。Python開発者は実使用を通じて深く理解しているのに、非利用者が外部的な根拠で言語を批判するのは不思議だという反応。contrived example（作為的な例）で議論する雰囲気を指摘
長年Pythonを使ってきた経験者として、最大の失敗は型ヒントと型チェッカーをまったく使わないことだと断言
tyの「段階的保証（gradual guarantee）」に興味を示す意見。つまり、型アノテーションを1つ削除しても型エラーが発生しないべきだという点が魅力で、動的コードが多いPythonに最も適した方式だと考えている
段階的型付けは、コードのどこにでも
any（未確定型）が入っていても警告すら出ない構造であり、重要なコードに対してさえ完全な型安全性を保証できず、十分に保護されない問題があったという回想。mypyの使用経験でもこの点は致命的で、「このファイルは完全に静的に型チェックする」と宣言する機能が絶対に必要だという主張。「段階的」型付けはむしろanti-patternに近く、いっそ「soft typing」という用語のほうが適切かもしれないという意見既存コードベースでは段階的型付け以外に方法がないという立場。実際にmypyで複数のレガシーPythonコードベースに型ヒントを適用してきた経験からすると、「モジュール単位 opt-in」が最も合理的。pyreflyがこれをサポートしないなら実用性には限界がありそう。ただし、llm（大規模言語モデル）によるコード生成の観点では、非常に高速で厳格な型チェッカーには有用性がある
TypeScript初期導入に似ており、既存の大規模プロジェクトへのスムーズなオンボーディングを重視しているという見方。徐々に
noImplicitAnyやstrictオプションをモジュールごとに有効化していき、最終的には強力な型検証環境へ変えていけるRustプログラマとしても「段階的保証」が最も合理的だと思うという意見
段階的型付けのサポート方式には個人的に大きな魅力を感じないという立場。そもそもPythonの動的型システムは不安定であり、型アノテーションを追加する目的の半分はその誤作動を制御することにあるため、
no-implicit-anyやstrictモードの選択肢が必ず必要だという要望Astralのツール群はPythonエコシステムに新鮮なエネルギーを与えているが、「長期的な展望」には疑問があるという指摘。今後Python本体に統合されるのか、5年以内に消えるのか、サブスクリプションベースのrug pullになるのかという不安
ビジネスソースライセンスを通じて、Astralツールを使う本番デプロイに企業向けサブスクリプションなどを事実上必須に誘導する可能性が高いという見方。現在の製品はその目的にぴったりではないものの、ベンチャーキャピタルの投資観点では似たモデルに向かうだろうという推測
公式発表ではAstralがツールの上にさまざまなサービスを販売すると明記している。参考リンク https://astral.sh/blog/announcing-astral-the-company-behind-ruff
実際のところ、こうした懸念はAstralだけに当てはまるものではなく、すべてのプロジェクトに当てはまるという指摘。特にFacebookのツール群は、時間が経つとメンテナンスされない「放置」のリスクが高いと警告。結局、利用者は常に自分でリスクを負うしかないという助言
Redditのある利用者の意見を引用し、VCの基本モデルは結局FAANGのようなビッグテックに買収されることを期待するか、脅威となるほど成長させて「acqui-hire」を狙う方式だという分析。Astralにも買収合併後の人材流入などのシナリオがありうる
最近、Astralが大企業専用ツール、たとえばホスティング型のprivateパッケージregistryなども準備中だという噂
my_list = [1, 2, 3]の例で、mypy、pyrefly、pyrightはmy_list.append("foo")を型エラーとみなすが、tyだけが明示なしで許容する点について、実務では常に単一型のリストを使うのが一般的なのだから、型チェッカーもそれを前提にすべきだという主張。Pythonが許しているからといって型検証まで緩くすべきではないと強く批判し、初心者コード向けに最適化された方針ではないかという意見tyの開発者として、「まだリストリテラルの型推論が完成していない」という説明。現状では単に
list[Unknown]を使っており、UnknownがAnyに似たgradual型であるためappendがすべて許可される構造。今後はより精密な推論を計画しており、関連議論のissueリンクを添付 https://github.com/astral-sh/ty/issues/168初心者向け最適化というより、レガシーコードとの互換性のために避けられないという意見。大規模な無型コードに型チェッカーを導入するには、既存コードができるだけそのまま動く必要があり、そうでないと負担が大きいという現実的説明
「Pythonが許していることを無視し、個人的な意見でtoolingを作ろうというのは説得力がない」という反論
pyrefly方式の問題として、「大規模な無型コードベースでは全面導入が難しい」という点。逐一コードを修正しなければならないため、組織内でその作業に合意がなければ簡単ではないという懸念。Metaのように内部で強制できる環境ではよいが、段階的導入を考えるならtyのようなより寛容な方式のほうが現実的。ただし個人的にはmixed型に警告を出してくれるツールを好むという複合的な立場
「実行可能なPythonコードである以上、明示的に型を制限しない限り型エラーにならないのが正しい」という意見。より厳格な静的サブセットが欲しいなら型アノテーションを直接追加すればよいという立場
Pyrefly方式は型推論をより強く追求しているため、実際に大規模な型安全コードでは必要なアノテーションがはるかに少なくて済み、初期導入は大変でも長期的には効率的だという経験者の意見。tyは実質的に
noImplicitAnyオプションが無効になっている状態だという評価本格的なnotebook（ライブコーディング）統合をサポートする型チェッカーへの期待。静的検査によって長いセルを実行する前にエラーを事前に捉えられれば、非常に効率的だという考え
VSCodeのJupyter notebook利用経験を尋ねる声。pylanceのような型チェッカーを適用すると、実験コードではむしろ邪魔になることもあるという指摘
notebook統合やライブコーディング中に即座にフィードバックを得られるVSCodeのLanguage Server体験を勧める意見。notebook統合とライブインタラクティブな型チェックへの要求を満たしてくれると説明
Pyreflyの設計はTypeScriptの型推論方式に似ており、個人的にはより合理的だと感じる一方、モジュール単位の段階的（incremental）導入が理想だと評価。関数単位まで入ると細かすぎて、かえって必要以上だという意見。性能面でもモジュール単位で十分だと判断
プロジェクトに動的要素が多くても、Pyreflyのようなより強い型推論を好むと思うという立場。それによる不便さがあっても、そちらを支持するという意見
現在はbasedpyrightをIDEとCI環境で使っており、基本的には安定性に満足しているとのこと。mypyは単純な型作業さえしばしば失敗する点で好みではない