June 01, 2025

PyCon US 2025 初参加

橘祐一郎（@whitphx）です。今年初めてPyCon USに参加しました。過去のPyCon USの参加者から話を聞いていて、他のPyConとは規模も体験も段違いらしいということで、ぜひ参加したいと思っていました。今まではほとんど、特に海外のPyConにはスピーカーとして参加するようにしていましたが、今回は一般参加です。

PyCon USではたくさんのイベントやトークに参加しましたが、ここではせっかくなので日本からの参加者の中ではおそらく私だけが書ける内容をコラムにしようと思います。

Wasm Summit

トークの行われる3日間の前に、チュートリアルなどのための期間が2日間あり、Summitというタイプのイベントもそこで行われます。私はその中の一つ、WebAssembly Summitに参加しました。若干背伸び気味の参加でしたが、自分と同じような関心を持っている方と繋がれたりと実りのあるイベントでした。

自分はもともとPyodide（WebAssembly向けにビルドされブラウザやNodeJSで動くCPython）を利用したOSSをいくつか開発しています。 PyCon USのイベント情報を眺めていたら”WebAssembly Summit”の名前が目について、その存在を知りました。イベント情報には初心者向けではない旨、Pythonに限らずC,JS,Wasm,コンパイラなどに関する知識があればより楽しめる旨が注意書きされていて気後れしましたが、気になっているのに参加しないのも後悔するだろうと思い申し込みました。希望者は発表の機会があります。せっかく初参加なので、自己紹介を兼ねて発表を申し込みました。

いざ部屋に行ってみると、参加者は10名ほどでした。午前中は希望者が発表する時間で、午後にそれを踏まえて自由に議論を膨らませるという構成でした。

注意書きの通り技術的に尖った発表が多かったです。例えば、Pyodideのアプローチ（CPythonインタプリタをWasm向けにビルドする）の代わりに、より実行時オーバーヘッドを減らすためにPythonのバイトコードを直接Wasmにコンパイルするというアプローチの発表がありました。これは大学で研究されている方で、アカデミックな学会の雰囲気でした。また当然の如くPyodideの作者の方も発表していて、直近の進捗や今後の展望について話されていました。

私の発表は、自分の作っている、Pythonだけで書けてサーバサイド不要で動作するWeb UIフレームワークStliteとGradio-Liteの紹介と、そこから派生して最近取り組み始めているブラウザで実行する機械学習（WebML）関連の話題や個人的な展望を軽く話すトークです。

自分の発表はWasm Pythonそのものに関連する技術に触れるものではないためどう捉えられるか不安でしたが、MCの方が親切に進行してくれました。また、この場には Anaconda の PyScript プロジェクトの方が多く参加していて、その中の1人がかなり興味を持って話しかけてくれました。その方は PyScript の文脈で、ツールチェインやAIなどを含めたアプリケーションの拡充などに関心があるようで、自分の興味・発表内容ともかなり親和的でした。

午後の議論タイム（unconference）ではWasm周辺の技術的な話題が中心で、正直自分はほとんど聞くだけでしたが、小さいテーブルの方で上記の PyScript の方と議論を深められたのが収穫です。

総じて、Summitの名の通りかなり少数精鋭の感があるイベントで若干場違いな気持ちを勝手に感じてしまったものの、場の雰囲気は包摂的でそれなりに受け入れてもらえたと思います。自分と重なる興味関心のある方とも繋がれました。勇気を出して参加してみて良かったと思います。

Sprint: First-time CPython Contributions

スプリントでは、First-time CPython Contributionsのテーブルに参加しました。 CPythonのリポジトリへの貢献を初めてやってみようというテーブルで、CPython開発者の方がその場にいて親切に導入してくれたり、議論や相談に乗ってくれます。これがあるのはPyCon USとEuroPythonくらいではないかと思います。せっかくPyCon USに来たので飛び込んでみました。結果的に、3.13から導入された新しいREPLに関する issue に取り組み、PRを出してマージされるところまでできました。

当日部屋に行って、スプリントリーダーらしき人に声をかけつつまだ始まったばかりという気配のテーブルを選んで席に着くと、軽く流れを説明してくれました。始め方に関してはドキュメントにまとまっていて、PyCon USのブログのスプリントに関する記事でスプリントに関する一般的な情報をおさらいし、技術的な部分はPython Developer’s Guideに従ってセットアップしていきます。

セットアップと並行して、取り組む issue を見つけるように促されました。自分で見つけたバグや機能要望から出発するのではなく、OSS への貢献そのものを目的にして issue から探し始めるというのはほぼ初めての経験でした。 CPython リポジトリではこういう場で初心者が取り組みやすいissueに easy label が付いています。しかし実際には easy の issue の数はスプリント参加者数に対して足りておらず、すぐに売り切れてしまいました。同じテーブルの参加者も同様に困っており、スプリントリーダーに相談してみても、こればかりはどうしようもないという感じでした。

仕方がないので easy 以外のissueからできそうなものを探しました。とはいえissueは5k+個あるので、適当な条件で絞ります。

easy labelのissueを眺めた時に（ドキュメント修正以外では）この topic-repl の付いたissueが多い印象だったので、この label で検索しました。3.13から入った新しいREPLは実装言語がPythonになったのでCを書かなくても貢献できそうという見込みもありました。
数年経っているようなissueは除くようにというアドバイスを受けました。長く残っているということは解決が難しい可能性が高いからです。
コメント数が多いissueはすでに誰かが取り組んでいる可能性が高いので、今回の目的からは除外します。同様に assignee がいるissueも当然除外します。

その結果 https://github.com/python/cpython/issues/127960 を見つけました。新しいREPLでは relative import の挙動が従来のREPLと違っているという指摘です。自分の手元で最新のコミットでも問題を再現できることを確認し、修正点のアテをつけてから issue に自分がスプリントで取り組みたい旨のコメントを残しました。

早々に関連する箇所を見つけ、issue に書かれている内容を直すだけならPythonコードに1行足すだけで良いことが分かりました。

しかしその修正はなんともその場限りで、問題の根本的な原因を探って一貫性のある修正を模索するうちに、Cコードの修正にまで手が及んでしまいました。さらに、テストコードで担保されている、つまり実装者が意図してその挙動を選択したデザインに対しても修正が必要なことが分かりました。コア開発者が当初意図したのと違う方向に大きな修正を頑張っても手戻りのリスクが大きいため、この時点でスプリントリーダーに相談しました。すると、PyREPLのメイン実装者のPabloにその場で繋いでくれました。こういうことが気軽に起きるのが現地開催のスプリントの良い点です。

Pablo に上記の懸念を伝えると、以下のような返答でした。

issue としてはエッジケース寄りなのであまり大きな修正は労力の割に合わないだろうから無理しなくてもよく、現状を正として、ここでの議論をコメントに残しつつ issue を close するのも選択肢である。
一方で私が実装を頑張るなら上記の実装方針には同意できるしレビューするのも問題ない。

私としてはせっかくなのでまず実装を頑張ってみて、どうしようもなくなったら妥協してissueに議論の過程だけ残して撤退することにし、Pabloにもその方針を伝えました。

撤退も視野に入れつつ最初の実装を終えていざPRを出してみると、別のコア開発者Łukaszが議論に加わってくれて、私の実装方針を支持してくれました。またTomasが、PyREPLのimport文の挙動を変えるとautocompleteにも修正が必要である点を指摘してくれました。作業2日目にこれらの後押しを受けて実装とテストコードを拡充し、最終的にマージされるところまで至りました。

CPythonプロジェクトでは、出したPRをマージするまでにContributor License Agreement (CLA)　へのサインが求められます。これは大きめのOSSでは割と一般的な手続きかと思います。 CPythonではCLAへのサインを含む必要な手続きや実装上の作業（リリースブランチへのバックポートなど）がbotで自動化されていて、ほぼ追加の労力なしに出したPRがマージ可能な状態になりました。特にスプリントは多くの初参加者が短期間で成果をあげないといけない特殊な状況ですが、このような自動化はそのハードルを下げるのに一役買っているでしょう。

プログラミング言語そのもものリポジトリに自分のコードが入るは初めての経験でした。このスプリントは、CPythonのような大きなOSSに対して何らかの貢献を始めるために、とても優れた機会を設計しているなと感じます。

また月並みな感想ですが、最近のAIの性能向上によって、CPythonのようなプロジェクトの実装に新しく参加するハードルは下がっていると実感しました。この時自分はCursorを使っていましたが、AIがコードリーディングの速度をかなり上げてくれたと感じます。それなりに長いCのコードを依存関係をジャンプしながら全容を把握する代わりに、AI chat に説明させることでかなり短時間でコードベースを把握してスプリントの1日目中に進められたと思います。一方でCPython程度に複雑なコードベースに対して、例えば上記 issue をそのままAIに投げてマージに値するコードを書かせるのはまだ難しそうです。