- Rustで書かれた超高速 Python 型チェッカー兼言語サーバーであるtyがベータ版として公開
- mypy、Pyright、Pylanceの代替として設計され、10〜60倍高速な性能を提供
- インクリメンタルアーキテクチャにより、コード修正時に必要な部分だけを再計算し、リアルタイム応答速度を最大化
- 正確性と使いやすさを重視し、交差型、高度な型ナローイング、到達可能性解析など最新の型システム機能をサポート
- Astral は ty をRuff、uvとともに Python エコシステムの中核開発ツールへと発展させる計画
ty 概要
- tyは Astral が開発したPython 型チェッカー兼言語サーバーで、Rust で実装されている
- 既存のmypy、Pyright、Pylanceよりはるかに高速な代替として設計
- Astral の社内プロジェクト全体ですでに利用されており、ベータ段階で外部ユーザーにも推奨されている
- Astral は Python エコシステム向けの高性能開発ツールを作るチームで、uv（パッケージマネージャー）とRuff（リンター兼フォーマッター）で知られている
性能とアーキテクチャ
- ty は言語サーバー中心の構造で設計されており、ファイル修正時に必要な演算だけを再実行するインクリメンタル処理方式を採用
- このため、エディター内でのリアルタイム更新速度が非常に速い
- キャッシュなしで実行した場合でもmypy および Pyright より 10〜60 倍高速
- 例: PyTorch リポジトリの主要ファイルを修正した際、診断の再計算速度は4.7msで、Pyright（386ms）より 80 倍、Pyrefly（2.38秒）より 500 倍高速
- 大規模プロジェクトでもインクリメンタル更新時の性能差は数十倍以上に達する
型システムと正確性
- ty は交差型（intersection types）、高度な型ナローイング（advanced type narrowing）、**型ベースの到達可能性解析（reachability analysis）**などをサポート
- これらの機能により正確な型フィードバックを提供し、不要な誤検知（false positive）を減らす
- 目標は単なる速度向上ではなく、正確性とユーザー体験をともに改善した型チェッカーの構築
診断システム
- ty はRust コンパイラのエラーメッセージシステムに着想を得た高度な診断システムを含む
- 単一の診断メッセージ内で複数ファイルの文脈をあわせて提示し、問題の原因と解決の方向性を明確に示す
- 例: 誤った辞書キーの代入時に、型不一致の位置と宣言位置をあわせて表示
- 診断出力は ty の中核インターフェースであり、人間にも AI にも理解しやすい構造で設計されている
言語サーバー機能
- ty はVS Code、Cursorなど LSP（Language Server Protocol）をサポートするあらゆるエディターで利用可能
- 定義へ移動、シンボル名の変更、自動補完、自動インポート、セマンティックシンタックスハイライト、インレイヒントなど、モダンな言語サーバー機能をすべてサポート
- VS Code 拡張機能でインストールでき、CLI も
uv tool install ty@latest コマンドでインストール可能
今後の計画
- ベータ以降の短期目標は安定性の強化とバグ修正、Python 型仕様の完成、Pydantic と Django のサポート
- 長期的には ty を Astral ツールチェーンの意味ベース機能エンジンへ拡張
- デッドコード削除、未使用依存関係の検出、セキュリティ脆弱性（CVE）の到達可能性解析、型認識リンティングなどの機能を予定
- Astral は ty を継続的に改善し、Python を最も生産的なプログラミングエコシステムにすることを目標としている
謝辞
- ty の開発には数十人のオープンソース貢献者が参加しており、MIT ライセンスで公開されている
- Salsa、Elixir、Python typing コミュニティのさまざまな人物やチームが技術的な協力とインスピレーションを提供
- Astral の中核チームは型理論、Python ランタイムの意味論、エコシステムの利用パターンへの深い理解をもとに ty を開発した
2件のコメント
AstralはPython派なのか、それともRust派なのか…
アストラルってことだね〜
Hacker Newsの意見
この比較表にTyが追加されるといいなと思う
Python typing conformance結果表を見ると、Pyrightの性能を過小評価すべきではないと思う
EmacsでTy（LSP）を少し使ってみたが、かなりよく動く。ただ、メソッドシグネチャが表示されるときに一部パラメータの型注釈が少し冗長に見えるのがやや気になる
それでも長期的にはTyを使う可能性が高いと思う。最初のベータ版リリースおめでとう
実際のユーザーが重要視する点とは距離がある。（私はPython Typing Councilで仕様とテストを一緒に作っていた）
それでも私はuvの満足しているユーザーなので、Tyが十分安定したら移行するつもり
Astralは素晴らしいツールを作っているので、破壊的な収益化なしにうまく成長してほしい
結局既存ツールに戻らなければならない場合が出てくる。私にとっては速度より正確な型検査のほうが重要だ
Astralチームに感謝している。私たちはPydanticを多用しているので、Tyの正式リリースで1級サポートが予定されていると聞いて期待している
現在はPyrightとMypyを一緒に回しているが、それぞれ異なるエラーを見つけるので重複しているように感じる
この表によればPyrightがsupersetだというが、実際の経験は違った
2年前の分析なので今は違うかもしれない。大規模コードベースでPyrightひとつに統合した事例があるのか気になる
mypyのほうがより柔軟かつ正確に推論する場合が多く、Pyrightはfalse positiveが多かったので無効にしたこともある
最近はPyrightもかなり進化しているだろうが、BasedPyrightはむしろ非生産的だった
コミュニティではmypyをけなしてPyrightを称賛する雰囲気が強いが、私の経験とはやや違う
主に注釈の意味論に焦点を当てているため、型チェッカー選びの基準にするには不適切だ
（私もPython Typing Councilでこの仕様とテストを作っていた）
タイトルは「Tyベータリリース発表」のほうが適切だった気がする
私はPyreflyをPyrightより好んでいたが、最近のバグのせいで以前のバージョンに固定しなければならず不便だった
Tyをインストールしようとしたら、Cursorのバージョン互換性エラーが発生した
いまだに1つの言語にこれほど多くの型チェッカーが存在する理由がわからない
ライブラリ作者はすべてのチェッカーについてテストしなければならないのか？ 開発者は特定のチェッカーをサポートするライブラリだけを使うべきなのか？
パッケージ境界では明示的な型が必要だが、内部コードでは曖昧さが多い
Astralは特にインクリメンタル処理性能を主要な設計目標にしている
必要なら自分でtype stubを提供して互換性を確保することもできる
Tyが「型チェッカーを満たすために注釈を追加する必要はない」という立場を取っているのが気に入った
以前のチェッカーは些細な警告で煩わしかったが、Tyは実際の論理的なエラーをうまく見つけてくれる
Tyが**言語サーバー（LSP）**の役割も果たすことを今日初めて知った
つまり、NeovimやVSCodeでmypyとPyrightの両方を置き換えられる
Django対応はどうなのか気になる。Djangoはマジックコードが多く、型チェッカーには扱いにくい
Djangoを使っているなら、しばらくはmypyかPyrightを維持したほうがよい
Tyが速くなくても、**交差型（A & B）**のサポートだけで使う価値があると思う
標準のPython型システムに欠けていた機能なので歓迎したい
Rubyにもuvみたいなものがあるのか気になる。PythonやTypeScriptではuvやbunを使っているが、Rubyは遅れている感じがする