Pyrefly - Python向けの新しい型チェッカーとIDE体験

• MetaのPyreflyは、Rustで開発されたオープンソースのPython型チェッカーであり、IDE拡張機能でもある
• 超高速な解析性能とIDE統合機能を備え、Pyreの限界を克服するために開発された
• 自動型推論と大規模コードベースのサポートを重視し、オープンソースの哲学を原則としている
• Pythonコミュニティとの協業と貢献を通じて、エコシステム全体の型システム改善を目指している
• 現在はアルファ版を公開しており、コミュニティからのフィードバックと貢献を積極的に募っている

---

紹介

• Pyreflyは、MetaがRustで開発したPython静的型チェッカーであり、IDE拡張のオープンソースプロジェクトでもある
• コード実行前に型の一貫性を検証することで、エラーの事前検出を支援する
• IDE統合とCLIの両方に対応し、柔軟なワークフローを提供する
• オープンソースコミュニティとの協業を通じて、Pythonの型システムや各種ライブラリの発展に貢献することを目標としている

Pyrefly開発の背景

• 2017年、MetaはInstagramの大規模なPythonコードベースのために、新しい型チェッカー（後のPyre）を開発した
• PyreはHackやFlowなどの堅牢な設計を参考にし、性能のためにOCamlで実装された
• 時間の経過とともに、型システムの進化やIDE連携へのニーズが高まり、限界が生じた
• Pyrightなどのコミュニティ製ツールも利用したが、大規模コード探索や型エクスポートなどの要件を満たすには限界があり、Pyreflyの開発に至った

Pyreflyの主要原則

• 1. 性能

  • 開発者には、コードを書いた直後にキー入力のたびに高速な型チェックが必要である
  • Pyreflyは、超大規模コードベースでも毎秒180万行を検査できる高性能なRust実装の構造を備えている

• 2. IDE中心の設計

  • IDEとCLIが同じ見え方を保てるよう、最初から抽象化設計を行っている
  • Pyreでは後付けの補完だったが、Pyreflyでは設計段階から一貫性を重視している

• 3. インファレンス（推論）

  • 注釈がなく型が明示されていないPythonコードでも、自動で型推論を行える
  • 戻り値やローカル変数の型をIDEに表示し、より良いコード作成のためにダブルクリックで推論型を自動挿入できる

• 4. オープンソース

  • PyreflyはMITライセンスでGitHub上に公開されており、コミュニティからのPRやIssue報告を歓迎している
  • PythonエコシステムやMetaの主要ライブラリ（PyTorchなど）と連携しつつ、Discordチャンネルを通じた活発なコミュニケーションを目指している

Pyreflyの未来

• コミュニティとともに、Python言語と開発者体験の改善を目標に取り組んでいる
• Pyre開発初期からコードのオープンソース化とPEPへの貢献を続けており、Pyreflyでも多様な開発者・ライブラリ・初心者に対して型活用の利点を最大化する計画である
• Metaは、動的言語における型活用の経験と成果をもとにさまざまな知見を共有し、エコシステムの型品質向上を進める予定である
• 現在のPyreflyはアルファ版だが、この夏の正式ローンチを目標に、継続的なバグ修正と機能追加を進めている
• コミュニティからのフィードバックは非常に重要であり、Pyreflyの利用後にはIssue報告や改善要望を積極的に寄せてほしいとしている

Pyreflyアルファ版の活用とコミュニティ案内

• Pyreflyの開発過程や技術的な詳細は、Meta Tech PodcastやPyCon USでの発表などで公開されている
• Meta Open Source関連サイト、YouTube、Facebook、Threads、X、LinkedInなど、さまざまなチャンネルを通じて追加情報を提供している

[GN⁺]

Hacker Newsのコメント

• Metaの「Python Language Tooling Team」の立場を思うと少し不安になる、uvの人気が非常に高いため、この分野ではtyが勝ちそうな予感がある、下手をするとAtomやFlowのように社内チームが外部オープンソースに押されて、上層部で「このチームは本当に必要ないのでは？ オープンソースに切り替えよう」という空気が生まれる可能性がある、管理者（Aaron Pollack?）が気を配るべき点だと思う
  • Kevinです、はじめまして。以前Flowで働いていて、今はPyreflyチームで活動しています。今回はFlowとは異なるアプローチを取っており、オープンソースとコミュニティ構築を明確に優先事項にしています。最近は各社のインフラ投資に関連して変動が大きかったですが、現時点では正しい旅の出発点に立てていると信じています。応援ありがとうございます
  • Metaは特に開発ツールのオープンソースプロジェクトに対するコントロールを非常に重視しているという意見、以前gitのメンテナーがmonorepoの活用について問題点を指摘し、その改善案をupstreamが拒否したことでmercurialへの移行が行われ、mercurial側は喜んで貢献を受け入れたという逸話、社内ツールの変化速度が非常に速いため、自前のプロジェクトを所有するのは合理的だという説明
  • Facebook発のものではJSXが一番好きだという話（おそらく唯一まともだと思う点）
• MetaのPyreflyチームで働いているという自己紹介、FAQで多くの質問をカバーしているので参照してほしいというリンク案内、追加の質問にも答えられるという親切な姿勢と関心への感謝
• 最近Rustで書かれたPython型チェッカーが3つ（Microsoft、Facebook、Astral）登場しており、既存のmypyも依然として存在しているという観察
  • Microsoftの型チェッカーPyrightはTypeScriptベースだという訂正、それでもmypyより速いという個人的な経験の共有
  • どれも静的型チェッカーなのかという質問、ランタイム向けのものはないという言及
• 今回が正式発表だが、Pyreflyは数週間前にすでに議論されていたという情報、現在はアルファ段階として公開中で、バグ修正と機能開発に集中し、夏にはアルファのラベルを外すのが目標だというチームの公式見解の引用
• ここに書かれているRustコードはとても理解しやすいが、最近Pythonツールが次々とRustで書かれていることへの懸念と、また別のN個の言語問題が起きるのではという不安の表明、Mojoがここで何かしてくれることを期待する気持ち
  • Pythonエコシステムでは、Pythonで十分対応できる領域ではPythonを使い、高性能が必要な部分ではRustやCのような言語を使うのが自然な流れだという説明、結局N=3（Python、Rust、C）であり、ただしCは長期的にはアプリケーションプログラミングから徐々に消えていってほしいという願い、とはいえ実際には長い時間がかかる見通しで、むしろPython自体がレガシーになるかもしれないという考え
• Vim/Neovimへの統合方法が案内されていてうれしいという反応、関連リンクの案内
• Rustで書かれていることがなぜそんなに大きな利点のように語られるのか疑問だという意見、大半の人は組み込みシステムやミッションクリティカルなサービスで型チェッカーを動かすわけではなく、「Erlangで書かれている」と言われるのと似た感覚だという話、性能が重要なコードでないならPythonで書いた方が、より多くのコミュニティ参加や拡張が可能なのに、なぜそこまでRustにこだわるのかという疑問
  • Rustを使った経験の共有、ユーザーとしては速度と安全性、開発者としては貢献のしやすさが利点だという言及、Astralの魅力もこうしたRustベースのツールをPythonにもたらしている点にあると思う、RustよりPythonの方がよく知っているが、それでもRustプロジェクトの方が貢献しやすいと感じる、Rust品質のツールをPythonに移植することが全体的な目的だという見解
  • LSP(Language Server Protocol)は性能が非常に重要なコードだと思う、IDEの応答性に直接影響する。RustはCPUとメモリの両方で効率が高い。もしOCaml、Reason、Haskellなどで書かれていたとしても速度や効率は十分出るだろうが、貢献者の母集団が非常に限られる点を強調
  • 「[ツール説明] rust」で検索すると高性能なソフトウェアを簡単に見つけられるのがうれしい、使っているツールの約95%がRustで書かれているが大半に満足しているという経験の共有
  • Rustは「目に見えて速い」という意味の略語のように使われている、オープンソースのRustなら依然としてレビュー可能だという強調
  • Pythonで書かれた型チェッカーは性能が不足するという説明、たとえばPylintのようなPython製リンターはコード行ごとに1つずつチェックして30秒以上かかることもあるなど、性能が重要な領域だという主張
• PyreからPyreflyへの移行と、Rustへの全面的な書き直しに対する興味、あまり知られていない言語からトレンディなRustへ移ったことによる具体的な利点や動機が気になるという意見
  • その質問はFAQで扱っているという案内、経験がさらに蓄積したら長めのブログ記事でも語ってみたいという言及、リンク案内
• 一度にあまりにも多くを解決しようとしているプロジェクトに感じるという意見
• VS Codeを見て興味を失ったという意見、なぜ人々がVS CodeをPython用IDEとして適切だと考えるのか理解できないという立場、PyCharmのような本物のIDEがあるのにVS Codeを使う理由がないという考え
  • pyreflyはvscodeだけに縛られているわけではないこと、いろいろな人にいろいろな好みがあることをもう少し考慮してほしいというお願い、pycharmも絶対的に優れているわけではない、自分はvscodeのリモート開発が便利で、pycharmがいまひとつだということをわざわざインターネットに書きたいとは思わないという意見