ハクソク

世界を動かす技術を、日本語で。

Pyrefly: Pythonのための新しい型チェックツールとIDE体験

373日前原文(engineering.fb.com)

概要

  • Pyrefly は、Rust製の新しいオープンソースPython型チェッカー兼IDE拡張機能。
  • 高性能 な静的型チェックとIDE統合、CLI利用をサポート。
  • コミュニティ主導 で開発されており、GitHubでフィードバックや貢献が可能。
  • 型推論、インクリメンタル更新、IDE連携 など、現代的な機能を重視。
  • 今後の計画 として、バグ修正や機能拡充を進め、正式版リリースを目指す。

Pyrefly: Python型チェックの新時代

Pyreflyの概要と特徴

  • Pyrefly は、Rustで開発された Python用の静的型チェッカー 兼IDE拡張機能であることを発表。
  • Pythonコードの型整合性 を解析し、実行前にエラー検出を支援することを目的とすること。
  • IDE連携およびCLI利用 が可能であり、柔軟なワークフローへの統合を実現すること。
  • オープンソースコミュニティ との連携を重視し、共同開発やPython型システムの向上を目指す提案。
  • 公式Webサイト に詳細情報を掲載し、 pip install pyrefly でインストール可能であることを確認。

はじめかたと導入手順

  • Pyrefly のインストールは、コマンドラインから pip install pyrefly で実行すること。
  • 既存の型チェッカー設定をPyrefly用に 移行すること を推奨。
  • VSCode拡張機能 をダウンロードし、モノレポから小規模プロジェクトまで 高速なIDE体験 を享受すること。
  • GitHub でフィードバックやバグ報告を行い、開発に貢献すること。

Pyrefly開発の背景

  • 2017年、巨大なInstagramコードベースに対応する 型チェッカー開発 を開始した経緯を説明。
  • Pyre 型チェッカー（OCaml製）の経験を活かしつつ、 Pyrefly ではより拡張性やIDE連携、スケーラビリティを重視することを決定。
  • Pyright 等のコミュニティツールも活用しつつ、 新たなアプローチ としてPyreflyをゼロから設計・開発したことを強調。

Pyreflyの設計原則

  • パフォーマンス重視
    • CIでの遅延チェックを排除し、 全てのキーストロークごとに型チェック を実施すること。
    • 1.8百万行/秒 の大規模コードベース対応を実現するため、Rustによる高速処理とインクリメンタル更新を設計原則とすること。
  • IDEファースト設計
    • IDEとCLIの間で 一貫した抽象化 を追求し、後付けではなく初期設計段階から対応すること。
  • 型推論機能
    • 型注釈がないPythonコードにも恩恵をもたらすため、 戻り値やローカル変数の型を自動推論・IDE表示 すること。
    • IDE上で 推論型をダブルクリックで自動挿入 する機能を提供すること。
  • オープンソース志向
    • Python本体や型仕様、PyTorch等の主要ライブラリ同様に PyreflyもMITライセンスで公開 し、GitHubで開発・議論を推奨すること。
    • Discordチャンネル も用意し、より自由なコミュニケーションを促進すること。

今後の展望とコミュニティへの呼びかけ

  • Pythonコミュニティと協力し、 言語進化や開発者体験向上 を推進すること。
  • Pyre時代から PEP提案やオープンソース貢献 を続けてきた経緯を踏まえ、Pyreflyでさらなる発展を目指すこと。
  • Meta は動的言語に型を導入する利点を認識しており、今後も知見やツールを ブログやエコシステム強化 を通じて共有すること。
  • Pyreflyは現時点でアルファ版 だが、今夏の正式リリースを目指してバグ修正や機能追加を継続すること。
  • ユーザーからのフィードバック が不可欠であり、バグ報告や改善要望を積極的に募集すること。
  • Pyreflyがプロジェクトに合わなくても、 型利用やエディタ改善要望 を共有してほしいと呼びかけ。

追加情報・リソース

  • Meta Tech Podcast でPyrefly開発チームの経験や技術詳細を紹介していること。
  • PyCon US で高速型チェックやスレッド化実行について講演したことを案内。
  • Meta Open Sourceサイト、YouTube、各種SNS で最新情報を随時発信していることを提案。

謝辞

  • Pyrefly はMetaの Python Language Tooling Team （Jia Chen, Rebecca Chen, Sam Goldman, David Luo, Kyle Into, Zeina Migeed, Neil Mitchell, Maggie Moss, Conner Nilsen, Aaron Pollack, Teddy Sudol, Steven Troxler, Lucian Wischik, Danny Yang, Sam Zhou）が開発したことを明記。

Hackerたちの意見

これは公式発表だけど、Pyreflyについては数週間前に話題になってたよね: https://news.ycombinator.com/item?id=43831524 「今日はPyreflyをアルファ版としてリリースします。同時に、アルファラベルを外すために、バグや機能の長いリストを片付けるのに忙しいです。夏にはアルファを外せるように頑張ります。」

たぶんクールなんだろうけど、FBには全然興味ないな。AGIでも出さない限り、無理だと思うし、出たとしてもスルーしちゃうかな。

└

同意だわ。今のところ、マーク・ザッカーバーグがやってることには全く賛同できない。

└

もし彼らがメタバースを実現したらどうなるんだろう？ ;)

今、Pythonのための型チェッカーには少なくとも3つのRustベースの競合がいるみたいだね（Microsoft、Facebook、Astral）。もちろん、mypyもまだあるけど。

└

みんな静的型チェッカーだよね？ランタイム用のはないの？

└

近いけど、Microsoftの型チェッカーPyrightはTypeScriptだよ。でも、私にはmypyよりもまだ速いかな。

PyreからPyreflyへの移行についてもっと知りたいな、特にRustでの書き直しについて。あれは単にあまり知られてない言語から流行りの言語に乗り換えただけなのかな？Rustから得た特定の利点があったのかな？

└

こんにちは！この質問についてはFAQで触れていて、もう少し進んだら私たちの経験について長めのブログ記事も書けると思うよ：https://pyrefly.org/en/docs/pyrefly-faq/#why-rust

Metaの「Python Language Tooling Team」のことがちょっと心配だな、uvがすごく人気だから、tyがこの分野で勝つ可能性もあると思う。だから気をつけないと、これがAtomやFlowみたいになっちゃうかも。もっと人気のある外部のオープンソース版に取って代わられて、ディレクターやVPたちが「このチームが存在するのは残念だな。彼らを排除してオープンソースのやつに切り替えられないかな？」ってつぶやくことになるかも。マネージャー（アーロン・ポラック？）が気をつけておくべきことかもね…。

└

JSXはFacebookから出てきた中で一番好きなものだな（唯一の良いものでもあるけど）。

└

ケビン、こんにちは！FBにいたときにちょっとだけ重なったよね、Flowで働いてた時。連絡くれて嬉しいよ！今はPyreflyに取り組んでるけど、Flowには長いこと関わってたんだ。ちなみに、Flowとは違うアプローチを取っていて、オープンソースとコミュニティビルディングを明確に優先してるんだ。これ、二人とも大事にしてることだよね。もちろん、何が起こるかわからないし、大企業のインフラ投資には最近かなりの変動があったけど、正しいスタートを切ってると思ってるよ。じゃあね、サム

└

メタはオープンソースプロジェクト、特に開発ツールの管理にかなり力を入れてるみたいだね。少なくとも、gitのメンテナーたちがモノレポのやり方を間違ってるって言って、スケール修正を上流に送るのを拒否したことから始まったんじゃないかな。それがきっかけで、メルクリウムに移行したんだ（彼らは貢献を喜んで受け入れてたし）。内部ツールの変化の速さを考えると、自分のプロジェクトを持つことが理にかなうのがわかるよね。

└

Angularみたいなもんだね。

「Rustで書かれている」って、なんでそんなに重要な特徴なの？誰が気にするの？俺の型チェッカーはメモリ保護があってコンパイルもされてるけど、埋め込みシステムやミッションクリティカルなサービスで使ってるわけじゃないし。「Erlangで書かれている」ってのと同じようなもんだよね。パフォーマンスが重要じゃないコードは、Pythonで書かれてる方がいいな。そうすれば、もっと多くのコミュニティがサポートしたり拡張したりできるし。

└

「目に見えて速い」のショートカット。オープンソースのRustはまだレビュー可能だよ。

└

「[ツールの説明] rust」で検索すれば、パフォーマンスが良くて質の高いソフトウェアを見つけやすくなるから、個人的には全然気にしない！日常的に使ってるツールの95%がRustで書かれてるから、新しいのを見つけるのが大好きで、ほとんどが期待を裏切らないんだよね。

└

GitHubのオープンソースプロジェクトの70%は、自分が書いた言語で書かれているって言ってる気がする。

└

Rustを使ったことある？ユーザーとしては、スピードと安全性が良いよね。でも開発者としては、Rustのプロジェクトはハッキングしやすくて貢献もしやすい。これがAstralの魅力なんだよね。Pythonの方がRustよりも詳しいけど、Rustのプロジェクトをハッキングする方がずっと簡単だよ。Astralの魅力は、Rust品質のツールをPythonにも持ってこようとしてるところだね。

└

パフォーマンスが重要でないコードはPythonで書いてほしいな。タイプチェッカーはパフォーマンスが重要なコードだよ。Pylintはただのリンターだけど、Pythonで書かれていて、ソースコードを行ごとにリンティングするのを見てみて。変更した行の後にリンティングを更新するのに30秒かかることもあるくらい遅いんだ。

└

LSPはパフォーマンスが重要なコードだよ。IDEの応答性や、LSPが扱えるプロジェクトの範囲に直接影響するからね。RustはCPUとメモリの効率が良くて、Pythonとは全然違うよ。（OCaml / ReasonやHaskellでも良かったかもしれないけど、どちらもかなり速くて効率的で、タイプチェッカーを書くのに便利なんだ。ただ、貢献者の範囲はかなり狭くなるけどね。）

└

なんで「Rustで書かれている」って特徴として挙げられるの？誰が気にするの？もし「純粋主義者」なら、Python以外のツールが関わるのは不満かもしれないけど。オープンソース全体で「純粋主義者」があまり見られないから、ちょっと皮肉っぽく言ってるけど、Python自体がその一例だよね。

└

なんで「Rustで書かれている」って特徴として挙げられるの？誰が気にするの？たくさんの人が気にしてるよ。正しいかどうかは別として、「Rustで書かれている」はPythonコミュニティで「代替よりもずっと速い」と同義になっちゃったと思う。

ここで書かれているRustのコードはすごくわかりやすいけど、新しいPythonツールがRustで書かれているのはちょっと心配だな。N言語問題にまた新たなベクトルが加わるし。Mojoがここで何か提供できることを願ってるよ。

└

Pythonエコシステムでは、Pythonが対応できるところではPythonを使い、対応できないところでは高性能な言語を使うのが自然だよね。Pythonの周りで広く使われている高性能な言語は2つ、RustとCだね。だからN=3だ。（個人的には、Cはアプリケーションプログラミングから完全にフェーズアウトされるべきだと思うから、Nは2になるけど、それはすごく長いプロセスだし、Pythonが収束する前にレガシー言語になっちゃうかも。）

└

残念だけど、もう手遅れな気がするし、Rustは今や重要な地位を築いたと思う。個人的には見た目がちょっと気に入らないけど、Pythonとの統合やツール面ではRustがデフォルトのCの代替になっちゃったみたい。Pythonの開発者たちは、もっと表面的にPythonっぽいNimとか、CっぽいZigみたいなものを好むと思ったけど、そういうプロジェクトはあまり注目されてないから、こうなっちゃったんだよね。最近はRustに興味を持ってる若い開発者がCよりも多いんじゃないかな。Mojoにはあまり期待してないけど、AI/LLMの流行に深く埋もれてる感じがして、Pythonの開発者にとっては有用な言語拡張として提示されてないから。

みんな、こんにちは！メタのPyreflyチームで働いてるよ。ここで挙げられた質問のいくつかはFAQでカバーしてるから、見てみてね：https://pyrefly.org/en/docs/pyrefly-faq/。他の質問にも答えられるかもしれないから、よろしく！

└

Slackでは、内部でRustベースのHack型タイプチェッカーを使ってるんだけど、OCamlのやつより約20%速いんだ（両方使ってる）。Pyreよりも速くなった？つまり、何か見逃してる？

Vim/Neovimへの統合手順が見つかって嬉しい！: https://pyrefly.org/en/docs/IDE/#other-editors

本当に必要なプロジェクトでpyreflyを試してみたんだけど、関数内でグローバルなint変数に新しい値を代入しようとしたら文句を言われたんだ。関数には「global」ステートメントがあったはずなのに、これでOKになると思ったんだけど。グローバル変数やそれに代入するのは、良いソフトウェアには問題があるのはわかってるけど、PyreflyがPythonよりも厳しいところに驚いてる。タイプチェックの問題とは思えないんだけどね。でも、他の問題リストはちゃんと見つけてくれたから、まだ全部は処理しきれてない。データ構造を作るために、100個くらいのデータアイテムが重なり合った階層、タプル、辞書、リストを使って、趣味的なプログラムを急いで作ろうとして、10日前に諦めちゃったんだ。混乱を制御するためには、束縛と規律が必要かもと思って、SQLiteを使って関数間のデータフローを管理するために、たくさんの小さなテーブルを作って、オプションフィールドはなしで書き直してるんだけど、これって賢い選択かな？

└

試してくれてありがとう！もし何か問題があったら、GitHubのイシューを立てるか、Discordでメッセージを送って教えてね。Pyreflyはまだアルファソフトウェアだから、バグは予想されるけど、君のフィードバックはすごく貴重だよ。