「昨年、誰かが『これはしないでください』と言った人はいませんでした」。デビッド・ヒューイットは、PyCon US 2025 での試行を経て、Python Language Summit に戻り、Python のコア開発者が Rust に何を求めているのか、また、Rust for CPython プロジェクトがどのように進み、CPython プロジェクトに恒久的に組み込まれるかについて、提案されたスケジュール、段階、および成功基準について議論を求めました。
デビッドは、Rust for CPython プロジェクトチームの「アンバサダー」として活動しており、このチームは現在、コア開発者であるキリル・ポドプリゴラとエマ・スミスが、Rust for CPython の PEP 草案の著者として率いています。エマも、PyCon US 2026 で Rust for CPython プロジェクトについて講演しました。このチームは、Discord チャンネルで約 60 人の開発者で構成されており、その中には「Python のコア開発者の一部」と「Rust プロジェクトからの代表者」が含まれています。このチームは、Android や Linux カーネルなど、既存のコードベースに Rust を統合した過去のプロジェクトの経験があり、「もしプロジェクトが進むのであれば、その作業に興奮しており、支援したいと考えています」。
なぜ Rust なのか？
Rust を採用することで CPython に具体的にどのようなメリットがあるのかについて、デビッドは、「type-crash」というラベルが付いた問題の数が、時間とともに着実に増加していることを指摘しました。「私たちは、いくつかの大きな技術的な賭けをしています」と彼は述べ、新しいパーサー、JIT コンパイラ、およびスレッド処理について言及しました。これらの大規模で複雑な機能が、GitHub でより多くのクラッシュ報告が提出される理由の一つである可能性があり、Rust はその解決策となり得るかもしれません。デビッドは、ジェフ・ヴァンダー・ストープが Android における Rust を「迅速に開発し、問題を解決する」と表現したこと、そして、Android が Rust を採用してからの経験として、「同じサイズのパッチに対する修正回数が減少した」ことを説明しました。
Rust と Python は、PyO3 や Maturin などのパッケージを通じて、すでに Python エコシステムで連携しています。デビッドはまた、多くのテクノロジー企業が、新しいツールとしてだけでなく、「Rust を採用するという賭け」として選択していることを強調しました。
しかし、Rust を CPython に採用することは、必ずしも順風満帆ではありません。デビッドとチームが認識している懸念点もまだ存在します。
1年前の最大の懸念事項の一つは、RustがCPythonと比較して、対応しているプラットフォームが少ないという点でした。CPythonは、執筆時点では、Tier 1、2、または3のいずれかに分類される20種類の異なるアーキテクチャとプラットフォームを公式にサポートしています。David氏は、Rustのプラットフォーム対応状況は「昨年から拡大しており」、その点が「ますます懸念事項ではなくなってきている」と述べました。提案では、Pythonのディストリビューターに、Python 3.16（2027年10月）でオプションのRustサポートを試してもらい、プラットフォーム固有の問題を、Python 3.17のリリース時期（2028年10月）までに報告し、解決できるようにすることを求めています。
David氏は、Rustをプロジェクトに導入することは、技術的な課題であると同時に、社会的な課題でもあると認識しています。Rustの知識は、「CPythonの中核開発者全体に普及しているわけではない」ため、CPythonの「小さな部分」に焦点を当て、段階的なアプローチを取ることで、この問題を部分的に緩和することができます。なぜなら、「100万行のCコードを一度に移植することはできない」からです。
David氏は、Rustを使用すること自体が、移植されたコードがバグやセキュリティの問題から完全に解放されることを意味するわけではないことを明確にしました。Rustは、一般的にバグを引き起こす問題のクラスを軽減しますが、コードには依然として正当性の問題が存在する可能性があります。この問題を軽減するために、チームは、プロパティベースのテスト、ファジング、および移植プロセス中に「慎重なエンジニアリング手法」を採用することを提案しています。
提案されている最初のRustモジュール：zlib
以下は、CPythonに「大きな改善」をもたらすRust for CPythonプロジェクトの提案されたスケジュールです。Rustの成功基準を定義するPEPは、2026年末に公開される予定です。このスケジュールに基づくと、Pythonに最初に組み込まれるRustコードは、完全にオプションであり、既存のCコードが代替手段として残されるPython 3.16（2027年10月）になる予定です。RustがCPythonのビルドに必須となるのは、少なくとも3年後の2029年のPython 3.18になる可能性があります。
開発ロードマップには、ビルドシステムとCIが含まれており、2026年夏にはRust APIのプロトタイプが実装される予定です。2026年末には、成功基準を定義するPEPが策定されます。また、zlibモジュールのオプションのRustバックエンドと、Python 3.16（2027年10月）で利用可能なプライベートRust APIが提供されます。さらに、Python 3.17（2028年10月）では、プラットフォームの問題を解決し、Rustをより多くの場所（io、json、xml、memoryview、parserなど）で利用できるようにします。そして、将来のPythonバージョン（2029年10月以降）では、Rustによるビルドが必須となり、パブリックなRust APIが公開される予定です。
CPythonチームのRustチームは、最初のターゲットとしてzlibモジュールを選択しました。その理由は、「大幅な改善」を「小さな範囲」で実現したかったためです。提案されているRustの実装では、zlib-rsが使用されます。これは、「Firefox、uv、Cargoなどのプロジェクトで広範にテストされ、利用されており、多くのプラットフォームでzlibやzlib-ngよりも高速である」とされています。また、このモジュールは、外部のCargoパッケージを使用する必要があるため、ビルドプロセスのこの側面を設計し、テストする必要があるという理由でも選択されました。
この小さな変更は大きな影響を与えます。zlibの圧縮アルゴリズムは「Pythonのパッケージングで広く使用されている」ため、提案が採用されれば、「Python 3.16でのpip installの速度が大幅に向上する」可能性があります。
Rust APIの概要
Davidは、PythonからRust APIを呼び出すRustコードの例を示しました。このAPIは、Rustの属性（#[pyfunction]）を使用し、C関数引数をPythonicな関数構文から自動的に生成するための開発ツールであるArgument Clinicに似たものになる予定です。Rustの関数は常に、スレッドとインタプリタの状態（Python<'_>）を受け取り、オブジェクトの周りにスマートポインタ（Py<...>）を使用し、Resultのenumを使用してRustのエラー処理を行い、結果またはエラーを返します。
```
#[pyfunction(signature = ( data, / , wbits = MAX_WBITS , bufsize = DEF_BUF_SIZE , ))] fn decompress ( py : Python <' _ >, data : Py < PyObject >, wbits : c_int, bufsize : isize ) -> PyResult < Py < PyBytes >, PyErrRaised > { // buf はスコープ終了時に自動的に解放される let buf = PyObject :: get_buffer (py, & data) ? ; let decoded = /* ... */ ; Ok ( PyBytes :: new (py, & decoded)) }
上記の例では、バッファが割り当てられ、C言語で同じ関数を記述する場合のように手動で解放する代わりに、スコープ終了時に自動的に解放される様子が示されています。
提案された成功基準
デビッドは、成功基準について説明しました。Rust for CPythonプロジェクトが、ロードマップの新しい段階に進み、最終的にCPythonの構築に不可欠な要素となるためには、どのようなことを示す必要があるのでしょうか？「以前の大規模な変更（JITやマルチスレッドなど）では、追加される複雑さを受け入れるために満たすべき成功基準を明確に定義しました」とデビッドは説明しました。「今回も同様のことを行う必要があると思います。それらの基準はどのようなものでしょうか？」
デビッドは、コア開発者に対して以下の提案をしました。
重要：アクティブなコア開発者の過半数が、Rust APIを使用して機能を実装することに賛成していること。
CPythonのパフォーマンスベンチマークにおいて、意味のある低下がないこと。
すべてのプラットフォームで、Rustによるサポートが提供されていること。CPythonを構築するディストリビューターにとって、Rustのサポートを追加することが容易であるという印象を与えること。
デビッドは、最初の項目は「慣れている」ではなく「オープン（開放的）」であると述べ、Rustを実験段階から移行するかどうかを決定する際に、Pythonのコア開発者がCPythonへの貢献においてRustをどのように使用しているかについて調査を行う計画があると述べました。
議論
```
新しいRust APIのデザインについて、C APIのユーザーにとって「馴染みやすい」ようにするかどうかという議論の中で、トーマス・ウーターズ氏は、「過去の遺物（ダイナソー）のために妥協する」べきではないと意見を述べました。彼は自身もその一部であるとしながら、Rust APIは最初から根本的に設計されるべきかどうかを問うべきだと提案しました。デビッド氏は、リソースをスコープ終了時に解放するなど、「Rustの特性を活かせる場所」はあるものの、一方で「最適な選択肢ではない」Rustらしい設計もあると答えました。デビッド氏は、コア開発者が作業中にC APIとRust APIの両方を同時に検討することは妥当だと指摘しました。「我々は、自分たち自身も含めた、対象となるユーザーを常に意識すべきです」。
ラリー・ハスティングス氏は、Rust for CPythonプロジェクトがなぜ「書き換え」ではないのかと問い、チームには「フォークとして成功をアピールする」べきだと提案しました。デビッド氏は、「RustPythonはすでに存在している」こと、そしてRust for CPythonチームはすでにそのプロジェクトの貢献者と話し合っていることを認めました。「RustPythonはCPythonほどパフォーマンスは高くないが、我々が設計するAPIの参考になる可能性がある」。
ラリーはまた、「CPythonの開発にRustを学ぶことにあまり乗り気ではない」と述べました。デビッド氏は、CPythonにはRustで記述するべきではない領域が数多くあると説明しました。「CPythonは、RustのためだけにRustで書かれるべきではありません」。彼は、「CPythonは、一定期間、デュアル言語のプロジェクトとして機能するでしょう」。しかし、デビッド氏は、「Rustが常にオプションであるとは言えない」と注意を促しました。なぜなら、Rust for CPythonプロジェクトのロードマップにある項目の一つとして、ビルドプロセスに必須の要素としてRustを取り込み、パブリックなRust APIを提供することが含まれているからです。
パブロ・ガリンド・サルガド氏は、将来のことに懸念を示し、「Cargoからの依存関係に頼ることになる」と指摘しました。これは「大きな問題」であり、プロジェクトにとって「致命的な問題」になる可能性があると述べています。「私たちは依存関係を外部から調達しており、非常に厳選されたものだけを使用しています」と彼は述べ、そのプロジェクトのいずれかに脆弱性が報告されるたびに、リリース担当者が新しいバージョンをリリースする必要があり、それが「大変な作業」になる可能性があると指摘しました。「現在、私たちはAPIと基本的な機能に焦点を当てています」と彼は付け加え、多くのRustの依存関係を組み込むという課題はまだ解決されていないと強調しました。
デビッド氏は、チームは「できるだけ外部依存関係を少なくするべきだ」と答えました。「zlib-rsはたった一つの依存関係です」と述べ、Rustのソースコードは外部から取り込むため、「CPythonのビルドにCargoは不要になる」と説明しました。また、デビッド氏は「Cargoは依存関係を外部から取り込むための比較的シンプルなシステムを備えています」と述べ、CPythonのRustによるプロトタイプでは、このシステムが使用されていると付け加えました。外部から取り込んだソースコードは「CPythonのツリーには含まれません」。ルカシュ・ランガ氏は、「依存関係は別々に管理する方が良い」と同意し、cpython-source-depsというリポジトリを例に挙げました。トーマス氏は、これはそのリポジトリの新しい使い方になることを全員に思い出させました。現在、このリポジトリはCPythonのバイナリインストーラーのみに使用されています。