今こそ Free Threading Python に貢献する絶好のタイミングです
(iz4u.net)今こそ Free Threading Python に貢献する絶好のタイミングです
PyCon US 2025 で現時点までに把握した Free Threading Python について簡単に整理し、貢献についてもまとめてみます。
Free Threading Python とは？
Free Threading Python は、Python の GIL（Global Interpreter Lock）を取り除くことで、マルチスレッド環境での性能向上を目指すプロジェクトです。このプロジェクトは、Python のマルチスレッド性能を改善し、CPU バウンドな処理でより良い性能を提供するために始まりました。
まだ実験段階にあり、再コンパイルしてインストールするか、uv を通じてインストールする必要があります。
現状
私もテストしかしていませんが、ほとんどの純粋な Python ライブラリは利用に問題がないと言われています。ただし、多くの一般的なライブラリは性能や実装上の理由から C/C++ 製のライブラリを呼び出したり、独自拡張として実装したりしているため、こうしたライブラリで Free Threading Python を使うにはいくつかの方法が必要です。
拡張モジュールを使う場合
多くは次の方法を使っており、ポーティングガイド があります。
- C API
- Cython
- PyBind11
- nanonbind
- PyO3
- f2py
CFFI はまだサポートされていませんが、Quansight の fork を使えば対応可能です。
サポートしないという issue はありますが、CFFI は主にインターフェース用途で使われることが多いため、理解できる判断です。fork された CFFI を使えば Free Threading Python は利用できますが、緻密な実装ではないので性能は落ちそうです。
貢献する方法
ここからは深い穴に身を投げるような話ですが、スプリントに参加したときは皆が前向きだったので、今のところはまだ貢献しやすいタイミングだと思います。貢献の方法は次のとおりです。
次を参照して free-threading-python との互換性が高いか確認する
- Free-threaded Python Library Compatibility Checker
- 🧵 Free-Threaded Wheels
- Compatibility Status Tracking#
テスト後に issue を登録する
まず 3.13 free-threading python をインストールし、ライブラリを入れてからテストを回してみます。
可能なら 3.14t バージョンも試すとよいですが、まだベータなのでまずは 3.13 バージョンから試すのがよいです。
ポーティングして PR を送る
ここからは少し難しくなります。マルチスレッドやさまざまなシステムコール、そして C/C++ と Python の内部について、ある程度の理解が必要です。
最も難しい点は、ライブラリ同士に依存関係があることが多く、別のライブラリを使っている場合にそのライブラリがまだ対応していなければ、そこから対応しなければならないことです。
私もスプリントに参加しながら把握した程度ですが、こんな感じになります。
- fastapi -> uvicorn -> uvloop, cryptography, pycares
貢献方法についての記事を書く
まさに今、私がやっていることですが、まだ不十分でしょう。記事を書いていろいろな場所に投稿してみましょう。
free-threading-python の使い方を書く
日本語の記事が不足しているため、性能テストを行い、使い方を書き、整理して記事として公開するとよいでしょう。
なぜ今貢献すべきなのか
私はオープンソースのエコシステムに関わっておよそ 25 年以上になると思います。私は大したオープンソース貢献者ではありませんが、知人には多くの貢献者がおり、CPython Core Developer も 2 人いますし、そのほかにもたくさんいます。そのため、こうした人たちと話しながら得た勘があります。
何もない時期、あるいは大きな変化の時期に貢献するのがよいのです。たとえば Python 初期に貢献されたチャン・ヘさんは、ほかにも多くのことをされましたが、unicode や韓国語 codec などに取り組まれていました。当時は何もなく、主要な貢献者たちは韓国語 codec を知らなかったため、比較的入りやすかったのではないかと思います。そして次の大きな変革は Python 3 への移行時でした。その後は asyncio の領域で、こちらではキム・ジュンギさんが印象に残っていますし、ほかにも多くの方がいます。さて、今また free-threading という新機能が登場しました。私は今こそ貢献するのに最も良い時期だと思います。
ほかの言語では、企業で意思決定されたり、すでに大企業が管理しているフレームワークの中で変更を作ることになるため、簡単ではありません。もちろん Python も非常に入りやすいわけではありませんが、無数のライブラリやフレームワークが存在し、今はそれらを一つずつポーティングしていけるうえ、多くの人手が必要なので、今がそのタイミングです。
12件のコメント
Python が人気だった理由の一つは、こうしたマルチスレッドまで考慮する必要がなかったことが大きいです。そういうところまで考慮しなければならないなら、一般の人には簡単に使えない言語になってしまいますね。
まだオプショナル機能ですし、マルチスレッドも今後ずっとオプションのままである可能性が高いです。（オプションを有効にする、あるいは別途インストールする、など）
私も Type はあまり使わず、free-threading も性能面の課題から多少は使うと思いますが、用途はかなり限定的になりそうです。
オプション扱いとは考えていません。PEP 779 が承認された後は、将来的にデフォルト実装を free-threaded に切り替えることが目標です。
typeのように深く考えずに使ってもいいのでは、くらいの意図でした。ふふ。free threading python、これは本当に簡単な話では決してなさそうですね。まるでパンドラの箱を開けるような感覚です。これまで潜んでいたありとあらゆる同期バグが噴出する可能性があります。それも、ごくまれに実行時に発生するような形で。マルチスレッド開発で頭を悩ませてきた問題が、いよいよ Python でも本格化するのかもしれません。C 系を見ても、thread safe ではない関数を使っている箇所はすぐに問題が起きそうですね。
自動で移植してテストまでしてくれるAgentが出てくるといいですね！
マルチスレッドの問題なので、簡単ではないでしょう。
自分でビルドする必要はなく、deadsnakes や Windows や macOS の公式インストーラーからも簡単にインストールできます！
誤字が多いですね。しくしく こちらでは更新できていないので、ブログのほうは更新しておきました。
こんにちは。Google のおすすめでこの記事が表示されたので、ご連絡しました。私は海外で 5 年間 Python 開発をしており（一般的な開発経験は 13 年です）……今はしばらく韓国で休んでいます。私も貢献したいのですが……もしよければ、メールアドレスを教えていただけますか？ ご連絡して、この件について学びたいです。
私のメールアドレスはjosephroh@naver.comです。ありがとうございます。
メールをお送りしました。ありがとうございます。