EuroPython2024参加レポート

青野高大koxudaxiです。私はソフトウェアエンジニアとして企業で働きながら、プライベートではオープンソースソフトウェア(OSS)の開発をしています。今回は、EuroPython 2024で登壇する機会を得て、チェコ・プラハを訪れました。この記事では、私の登壇体験をはじめ、イベントの詳細を紹介します。また、5月に参加したPyCon US 2024との比較を交えながら、現場で得た知見を共有します。

EuroPython 2024について

EuroPython 2024は、2024年7月8日から14日まで、チェコのプラハにあるプラハ国際会議場(Prague Congress Centre)で開催されました。このカンファレンスは、ヨーロッパを中心にPythonに関心を持つ開発者が集まる、ヨーロッパ最大級のPythonカンファレンスです。今回のイベントには、約1,200人以上の参加者が集まりました。

なお、昨年のEuroPython 2023についても、福田隼也さんによる詳細なレポートが公開されています日本からひとりで参加した「EuroPython 2023」スピーカー体験レポート⁠。会場や全体的な雰囲気は昨年と同様であるため、より詳細な会場の様子や基本的なイベント構成については、このレポートも参考になるでしょう。

イベントは以下の日程で行われました。

  • チュートリアル:7月8日~9日
  • トーク&カンファレンス:7月10日~12日
  • スプリントセッション:7月13日~14日

クロージングセッションでの発表によれば、合計1,245枚のチケットが販売されたとのことです。

クロージングセッションで発表された参加者集計結果
クロージングセッションでの参加者集計結果

参加の目的

私の参加の主な目的は、30分のトーク枠での講演と、ヨーロッパで活動する開発者との交流でした。日程の都合上、チュートリアルには参加できませんでしたが、スピーカーディナーから参加し、メインのカンファレンスとスプリントは初日の午前中だけ参加しました。

登壇経験はこれが人生で2回目であり、初回は今年5月に開催されたPyCon US 2024です。このときも今回と同様のトークを行いました。EuroPythonやその他のPythonイベントでは、CfP(Call for Proposals)のプロセスを経て発表者が選ばれます。私のプロポーザルはPyCon US 2024と同じ内容で、倍率は3.8倍と比較的通過しやすい印象を受けました。

スピーカーディナーの前に受付を済ませ名札を受け取る
スピーカーディナーの前に受付を済ませ名札を受け取る
クロージングセッションでのトークとチュートリアルの通過率発表
クロージングセッションでのトークとチュートリアルの通過率発表

多くの開発者との出会いと再会

EuroPython 2024では、世界中から集まった開発者たちと交流する機会に恵まれました。CPythonのコア開発者からオープンソースの貢献者まで、さまざまな背景を持つ人々と知り合えたのは、このイベントならではの醍醐味でした。

オンラインでは味わえない、対面でのコミュニケーションの価値を改めて感じました。実際にコードを見せ合いながら議論したり、休憩時間に雑談する中で新しいアイデアが生まれたりと、とても楽しい時間をすごせました。

私自身、以前のPythonイベントで知り合った人々との再会や、新たな出会いを通じて、たくさんの刺激を受けました。ここでは、特に印象に残った経験をいくつか紹介したいと思います。

Pyodideプロジェクトとの関わり

具体的な例を挙げると、Pyodideの作者であるHood Chathamさんとの再会が印象的でした。Pyodideは、ブラウザ上でPythonインタプリタとその主要なパッケージを動作させるためのプロジェクトです。これは、WebAssemblyを使用してPythonをブラウザで実行可能にする、非常に興味深い取り組みです。

以前PyCon USのスプリントで知り合ったHood Chathamさんと、今回のEuroPythonでも話す機会がありました。私は以前から彼にPython 3.14への対応について質問しようと考えていました。その背景には、現在のPyodideがPython 3.12をターゲットにビルドするようになっており、Python 3.13以降をビルドすることができないという問題がありました[1]。実際に会ってディスカッションを行った結果、オープンスペースという会場内の作業スペースで、Hood Chathamさんに実際にコードを修正してもらい、その場で3.14対応のためのブランチを作成してもらうことができました。

さらに、私はこのブランチを基に、現在Draft段階にあるPEP 750[2][3]の試験実装ブランチをPyodideとしてビルドできるようにした新たなPyodideのブランチを作成しました。このブランチを使って、最新のPEP 750の機能をブラウザで体験できるオンラインサイトを構築しました。具体的には、このPyodideのブランチを使ってJupyterliteを構築しています。これにより、ブラウザ上でPEP 750に対応したPythonインタプリタを動作させることが可能になりました。

PEP 750に関する継続的な開発

PyCon US 2024のスプリントセッション中、鈴木たかのりさんによるレポートで紹介されているように、PEP 750の共同著者であるGuido van Rossum氏とPaul Everitt氏、そして私(青野高大)で立ち話をする機会がありました。私はPEP 750の著者ではありませんが、この場で、Draft状態にあるPEP 750の理解を深めるためのチュートリアルサイトや環境の構築について議論しました。

この事前の対話や準備が、今回のEuroPythonでのさらなる議論と開発につながりました。特に、PEP 750の試験実装をGuido van Rossumさんから引き継いだLysandros Nikolaouさんとの対面での意見交換は、非常に有意義なものとなりました。

この活動の結果、PEP 750のDraft版の謝辞(Acknowledgements)セクションに私の名前が掲載されることになりました。こんな形でPythonの発展に関われたことを嬉しく思います。

このように、カンファレンスでの出会いや再会が、具体的なプロジェクトの進展や新たな取り組みにつながることは、対面イベントの大きな魅力のひとつだと感じました。

他の開発者との再会

EuroPythonでは、以前のイベントで出会った開発者との再会も多くありました。たとえば、PyCon USでも一緒に飲んだSamuel Colvinさんと再会することができました。彼の創業した会社pydanticは、OSSを軸とした新興スタートアップですが、大手と並びEuroPythonのプラチナスポンサーとなっており、その取り組みについてはクロージングセッションでも運営から取り上げられていました。

クロージングセッションでのスポンサー紹介
クロージングセッションでのスポンサー紹介

スピーカーディナー

7月9日、スピーカーディナーがプラハの美しい川沿いにあるレストランで開催されました。プラハの夜景を楽しみながら、多くの開発者と意見を交わすことができました。特にヨーロッパ各地からの参加者が多く、ドイツやイギリスなど、電車でプラハまで移動できる地域からのスピーカーが多く見られました。

私が特に印象に残ったのは、さまざまなバックグラウンドを持つ開発者と直接話をすることができたことです。ある開発者は、Pythonでデータウェアハウスを使って大量のデータを効率的に処理する方法に取り組んでおり、その技術的な課題について議論しました。また、ヨーロッパのコミュニティの動向についても聞くことができ、多様な視点を持つことの重要性を再確認しました。

スピーカーディナーの会場となったレストラン
スピーカーディナーの会場となったレストラン

筆者の講演 ―Enhancing Decorators with Type Annotations: Techniques and Best Practices

私の講演「Enhancing Decorators with Type Annotations: Techniques and Best Practices」では、デコレータにおけるタイプアノテーションの活用方法について紹介しました。この講演は、実は5月に開催されたPyCon US 2024での初登壇を経て2回目のものでした。PyCon USでの初めての登壇体験については、別のコラムで詳しく紹介しています。

ここ数年でParamSpecやConcatenateなどの新しいタイプが追加されましたが、それらを包括的に紹介するドキュメントが少ないため、このトークを通じて情報を提供しようと考えました。

会場は300人規模で、ほぼ満席でした。さらに嬉しかったのは、会場だけでなく、ホテルやプラハ駅でも「トークを聴きました」と声をかけていただき、直接感想を聞けたことです。多くの方に興味を持っていただいたことを実感し、とても励みになりました。

今回の登壇は人生で2回目で、1回目は今年5月に開催されたPyCon US 2024で同じ内容のトークを行いました。PyCon USは参加者が多く、会場の規模も大きかったです。

それに対して、EuroPython 2024は開発者同士の距離が近く、親しみやすい雰囲気が特徴でした。今回は、前回ほど緊張せずに講演に臨むことができましたが、それでも多くの人の前で話すのは非常に貴重な経験でした。

著者の登壇の様子
著者の登壇の様子

印象に残ったキーノート

キーノートはカンファレンス期間中の3日間にそれぞれ朝晩2コマずつあり、合計6つありました。今回は印象に残ったキーノート2つを紹介します。

The Catch in Rye: Seeding Change and Lessons Learned

キーノートスピーカーのArmin Ronacherさんは、FlaskなどのPythonのOSSで知られています。最近はRustを使った開発に取り組んでおり、Ryeは彼が久々にPythonコミュニティで注目を集めたプロジェクトです。Pythonのパッケージ管理ツールには改善の余地があり、彼はRyeを開発することで、その議論を活発化させました。このトークでは、Ryeの開発経緯、既存のパッケージマネージャーの課題、そしてRyeの管理がAstralへ移管された経緯について詳しく語られました。

Ronacherさんは、Rustについて以下のような観点を共有しました。

  • Rustは非常に複雑な言語だが、プログラマーとしては驚くほど生産性が高い
  • Rustのエコシステムは優れた開発者体験(DX)を提供している
  • 言語設計において後方互換性を重視しつつ、イノベーションと進歩も大切にしている

またRyeプロジェクトの背景について、Ronacherさんは2014年ごろの状況を説明しました。

  • 当時、彼がRustを本格的に使い始めた頃は、Python 2を活発に使用していた時期だった
  • Cargoのようなパッケージマネージャーはまだ存在せず、Python 3の採用も非常に遅く進んでいた

Ryeプロジェクトのその後の展開について触れられました。

  • RonacherさんはRyeプロジェクトの管理と開発の責任をAstralに引き継ぎました。
  • Astralは新しいPythonパッケージマネージャー「uv」を開発しています。
  • uvは現在、pip-tools/pip/venvの代替となることを目指しています。
  • 将来的に、uvはRyeの機能を吸収し、その精神を引き継ぐ形で発展していく予定です。

これらの情報は2024年2月に公開されたブログ記事で確認できます。

さらに、Pythonのビルドとパッケージング環境の現状について言及がありました。

  • PEP 711で提案されているPyBI(Python Binary Interface)の必要性
  • 既存のビルドツール(indygregビルドなど)が抱えるポータビリティの問題
  • 非公式プロジェクトの限界

このキーノートは、Pythonエコシステムの現状と今後の展望を浮き彫りにする内容でした。Ronacherさんが語った経験は、パッケージ管理の難しさと、それを解決しようとする開発者の苦心を如実に示していました。

特に印象的だったのは、RustとPythonという異なる言語での経験が、新たなツール開発にどのように活かされたかという点です。実際、最近ではpolarsやpydanticなど、パフォーマンスが重要な部分にRustを採用するPythonライブラリが増えています。この異なる言語間での知見の応用は、今後のPython開発にも大きな影響を与えそうです。

また、Ryeの開発からuvへの移行を決断した背景には、個人プロジェクトの限界と、コミュニティ主導の開発の重要性への深い理解があったことがわかりました。私自身も複数のOSSプロジェクトをメンテナンスしているので、個人での管理の難しさには強く共感します。Ronacherさんの決断は、オープンソースの持続可能性について、多くの開発者に新たな視点を提供したのではないでしょうか。

Ronacherさんの話を聞きながら、Pythonコミュニティの結束力と、常に進化を求める姿勢を再認識しました。今回のキーノートは、私たち開発者一人一人が、エコシステムの発展にどう貢献できるかを考えるきっかけになったように思います。個人の努力だけでなく、コミュニティ全体で支え合うことの重要性を改めて感じました。

RonacherさんとAstralとの関係についてのスライド
RonacherさんとAstralとの関係についてのスライド

Live Coding Music with PyRepl in Python 3.13

Łukasz LangasさんはCPythonの開発者で、Python 3.8と3.9のリリースマネージャーを務めました。Python 3.13を使ったライブコーディングのデモが行われました。Python 3.13から新しく実装されたPyRepl(対話シェル)を用いてリアルタイムで音楽を生成し、その過程を解説しました。Łukasz Langaさんは、この新機能の実装における主要な貢献者でもあります。

一般的に人前での発表でライブデモをするとリスクはつきものです。直前まで動いていたソフトが動かないなどよくおきますが、このトークでは全編にわたり対話シェルのみで音楽を組み立てていき、対話シェルの補完機能を書き換えるなど高度なことを実践されていました。

Python 3.13の新しい対話シェル(PyRepl)

Python 3.13では従来の対話シェルが大幅に改良され、新しいインタラクティブシェル「PyRepl」が導入されました。この新しいシェルは、UNIX系システム(LinuxやmacOS)およびWindowsで使用でき、以下の新機能をサポートしています:

  • カラープロンプト:プロンプトが色付けされ、視覚的に見やすくなっています。
  • マルチライン編集と履歴保存:コードのマルチライン編集が可能になり、履歴の保存もサポートされました。
  • インタラクティブヘルプの閲覧F1キーを使用して、コマンド履歴とは別にインタラクティブなヘルプを閲覧できます。
  • 履歴閲覧機能F2キーで出力や>>>および...プロンプトをスキップして履歴を閲覧できます。
  • ペーストモードF3キーで「ペーストモード」を有効にすると、大きなコードブロックの貼り付けが容易になりますF3キーを再度押すと通常のプロンプトに戻ります⁠⁠。
  • 簡略化されたコマンド実行:help、exit、quit などのREPL固有のコマンドを、括弧を使わずに直接実行できます。

この新しい対話シェルはより高度なインタラクションを可能にし、開発者の生産性を向上させることを目指しています。

PyReplの実装はPyPyプロジェクトのコードをベースにしており、Pablo Galindo Salgadoさん、Łukasz Langaさん、Lysandros Nikolaouさんの貢献によって実現されました。Windowsのサポートは、Dino ViehlandさんとAnthony Shawさんによって提供されています。

PyReplはPythonの対話シェルを大幅に改善する新機能ですが、まだ開発段階にあり、いくつかの課題が残っています。これは、CPythonにコントリビュートする絶好の機会と言えるでしょう。実際に、今回のEuroPythonのスプリントでもいくつかの修正が行われていました[4]。私自身も5月のPyCon USで小さなバグフィックスを行い、マージされた経験があります[5]

このように、新機能の改善に貢献できる機会が多くあることは、Pythonコミュニティの活発さと、オープンソース開発の醍醐味を実感させてくれます。PyReplの開発に参加することで、Pythonの中核的な部分に貢献できる可能性があり、興味のある開発者にとっては魅力的な挑戦となるでしょう。

デモを円滑に行うため、autoimport関数について説明しているところ
デモを円滑に行うため、autoimport関数について説明しているところ

面白かったトーク

Lessons Learned from Maintaining Open Source Python Projects

このトークでは、オープンソースプロジェクトの維持管理に関する教訓が共有され、多くの実践的なアドバイスが提供されました。特にコミュニティの構築やコントリビューターのモチベーション維持の重要性について強調していました。この内容は、OSS開発に携わる多くの人々にとって非常に参考になるものでした。私もいくつかのOSSプロジェクトをメンテナンスしており、苦労や難しいところなど日々感じています。

中でも、私が特に共感したのは、バグレポートの作成に関するスライドです。このスライドには、OSSメンテナーがバグの再現や修正に必要な項目が詳しく並べられていました。

OSSメンテナーは、バグを修正するためにまずバグの原因を理解する必要があります。その上で、バグが本当に修正されたことを確認するため、発生時と同じ条件で再現テストを行います。また、ライブラリなどのソフトウェアは、特定のOSやPythonバージョンに依存して発生するバグが多いため、事前にその情報を得ることで、メンテナーの作業効率は大幅に向上します。

バグレポートを作成する際の具体的な項目についての説明
バグレポートを作成する際の具体的な項目についての説明

※以下はスライドの日本語訳です。

バグレポートの作成 - ユーザーへのヒント

再現しやすいレポートを作成する

  • 常に最初に確認すること:既に開いている問題がないか確認してください。
  • Dockerイメージ:問題を再現するイメージを用意しましょう。
  • GitHubリポジトリ:問題を再現するために必要なすべてのファイルを含むリポジトリを用意してください。
  • 詳細な説明
    • 使用している環境(OS、Pythonのバージョン、インストールされているパッケージ)
    • パッケージのインストール方法(PyPIまたはOSのパッケージマネージャー)
    • エラーの完全なスタックトレース
  • 情報量の判断:少なすぎる情報よりも多めの情報を含めることを心掛けてください。ただし、少なくともテンプレートで要求される情報は共有してください。

Tales from the Abyss: Some of the Most Obscure CPython Bugs

このトークでは、CPythonにおける珍しいバグについての話が展開され、参加者を引き込みました。スピーカーのPablo Galindo SalgadoさんはPython 3.10および3.11のリリースマネージャーでした。彼は長年のCPythonの開発経験から特に難解だったバグの事例を紹介し、その解決方法や得られた教訓を共有しました。ユーモアを交えたプレゼンテーションは聴衆を楽しませつつ、技術的な深みも提供し、多くの参加者が共感と驚きを持って聞き入っていました。

特定のアーキテクチャにおけるバグの事例

Pabloさんは特定のアーキテクチャ(arm64)でのみ発生するCPythonのバグの事例を紹介しました。このバグは、エラー処理に関する一見単純なコードが、異なるアーキテクチャ上で予期せぬ動作をする例です。

具体的には、エラーが発生した場合に-1を返す関数があり、その戻り値を別の変数に代入するコードがありました。大半のアーキテクチャでは想定通りに動作しますが、arm64アーキテクチャでは予期せぬ値(255)が代入されてしまうのです。このバグは、プログラミング言語やコンパイラが異なるハードウェアアーキテクチャ上でどのように動作するかを考慮することの重要性を示しています。また、クロスプラットフォーム開発における課題の一例でもあります。

Pabloさんは、このようなバグを防ぐための方法として、可能な限りC言語の使用を避けることを提案し、会場の笑いを誘いました。

バグの解決策としてC言語の使用を避けることを提案して会場の笑いを誘った
バグの解決策としてC言語の使用を避けることを提案して会場の笑いを誘った

技術的な詳細

以下は問題のコードの簡略版です。

int get_token() {  
    if (ERROR) {  
        return -1;  
    }  
}

char token = get_token();

arm64アーキテクチャでは、get_token関数の戻り値(int型の-1)がchar型の変数tokenに代入される際、予期せずunsigned charとして扱われ、結果として255が代入されます。一方、他のアーキテクチャ(x86_64など)では期待通りsigned charとして扱われ、-1が代入されます。

このバグは、データ型の扱いやメモリ表現が異なるアーキテクチャ間で発生する微妙な違いを示しています。

ソーシャルイベント

7月11日木曜日、午後7時からソーシャルイベントが開催されました。会場はガブリエル・ロシという、19世紀に建てられたネオロマネスク様式の修道院でした。歴史的な建造物の中で現代のテクノロジーについて語り合うという、不思議な融合感を味わいました。

チェコ名産のビールや軽食を取りながら、自由な雰囲気で交流しました。特に印象的だったのは、各国のPythonコミュニティの代表者たちとの会話です。彼らから各地域でのPythonの普及状況や、直面している課題について聞くことができ、グローバルな視点でPythonエコシステムを考える良い機会となりました。

ライブミュージックやアクティビティもあり、技術的な話題だけでなく、文化交流の場としても非常に楽しめました。ヨーロッパの夏は日が長いため、外でも明るく、庭園でのネットワーキングも活発に行われていました。

ソーシャルイベントはカンファレンスチケットに含まれないオプションイベントでしたが、多くの人が参加していました。この高い参加率は、対面のコミュニケーションの重要性を再認識させるものでした。

ヨーロッパの夜は明るいので外でも会話を楽しんだ
ヨーロッパの夜は明るいので外でも会話を楽しんだ

スプリントセッション

7月13日と14日に行われたスプリントセッションでは、参加者が特定のプロジェクトに取り組みました。私はCPythonのプロジェクトに参加しました。スケジュールの都合で個人的にはスプリントに半日しか参加できませんでしたが、CPythonコアデベロッパーのLysandros Nikolaouさんと一緒に、新しいPEPの進め方について意見を交換しました。

スプリントの様子
スプリントの様子1 スプリントの様子2

PyCon US 2024と比べて

PyCon US 2024は、アメリカで開催された大規模なイベントでした。EuroPython 2024と比較すると、より商業的な雰囲気があり、スポンサーシップや企業のブースが多く見られました。また、PyCon USはPSF(Python Software Foundation)主催ということもあり、今後のコミュニティやPython本体の開発方針についての言及も多く見られました。

一方、EuroPython 2024はコミュニティやPythonの今後の開発方針を示すということはなく、開発者目線でユーモアあふれる体験談や技術的にコアな話が飛び交う場でした。廊下や食事中での雑談も、普段の業務での課題についての議論や、Pythonの具体的な実装の話題などカンファレンスで技術的な学びを得ようという人たちが多く見受けられました。

遠方支援(FinAid)

EuroPythonなどの国際的なPythonのカンファレンスでは、参加者に対する遠方支援(FinAid)制度が提供されています。これにより、地理的な制約を超えて参加者がイベントに参加できるようサポートしています。

私も日本からチェコへの旅費の補助を目指してFinAidに応募しましたが、今回はイベントチケットのみの提供にとどまり、残念ながら旅費の支援は受けられませんでした。それでも、イベント期間中は昼食やコーヒーが無料で提供され、チェコの物価も比較的安価であることから、東京と同程度の費用で滞在できました。

私は日常のOSS活動において、複数の企業や個人からGitHub Sponsorsを通じて資金援助をいただいており、今回もその支援のおかげで飛行機代やホテル代をカバーすることができました。

ちなみにPyCon USでは、ビッグテックなどの企業から多くの支援を受けているため、資金援助を通して飛行機代や宿泊費を補うことができました。

参加者支援の実績発表
参加者支援の実績発表
イベントの参加者の数はチェコ、ドイツ、イギリスの順
イベントの参加者の数はチェコ、ドイツ、イギリスの順

さいごに

結論として、このEuroPythonへの参加は非常に有意義であり、多くの人々とつながることができました。現地で知り合ったとヨーロッパのエンジニアと夕食をともにすることもできましたし、多くの人と連絡先を交換することもできました。

正直、トークを聴くだけであれば多くのイベントであとから動画が配信されるため、海外イベントへの参加の意義をあまり感じないかもしれません。しかし、普段接する機会のない優れたエンジニアたちとの雑談や、具体的なプロジェクトについてのディスカッションは、非常に貴重で、お金では買えない価値を提供してくれると実感しました。

GitHubなどでソースコードを見ることはできますが、実際にリアルタイムでコーディングされる様子を間近で体験することは、イベントに参加しないとできない特別な経験です。時間や、金銭的な制約があるので毎回このようなカンファレンスに参加することこと難しいですが、工夫をしてできるかぎり参加したいと強く思いました。

また、海外カンファレンスへの参加を検討している方々へのアドバイスとして、事前準備の重要性を強調したいと思います。特に、興味のあるトピックや話したい人のリストを作成し、限られた時間を最大限に活用することをお勧めします。

Pythonコミュニティの発展と、自身の技術的成長のために、今後も機会を見つけて国際的なイベントに参加し続けたいと思います。

おすすめ記事

記事・ニュース一覧