カンファレンスDay 2

カンファレンス2日目です。

キーノート：Brett Cannon

Brett Cannon氏はPythonのコア開発者の一人で、2019年から2023年までSteering Councilを務めた方です。 このトークではタイトル「Why it took 4 years to get a lock files spec」の通り、Pythonのロックファイルの仕様をまとめるまでに4年かかった話が語られました。

../_images/brett.jpg

Brett Cannon氏

最初に現在のPythonパッケージを作成するためのファイル構成について説明がありました。 pyproject.toml、sdistフォーマット、wheelなどが紹介されました。

そして、パッケージ間の依存関係の指定にはいろいろな書き方があるため、これを解決することはとても難しいそうです。 パッケージのすべての依存関係を記述するファイルとしてrequirements.txt、poetry.lock、pdm.lock、uv.lockがあり、ツールごとにバラバラという状況です。 そこで、Pythonのロックファイルを標準化したが、そのためには4年の月日がかかったとのことです。 標準化されたpylock.tomlファイルの仕様は以下で確認できます。

ロックファイルは以下のような設計方針で仕様を検討したそうです。

  • ソフトウェアで作成し、人間にも読みやすい

  • デフォルトで安全な設定

  • 依存関係の解決をせず素早くインストールできる

  • ロックファイルの生成ツールとインストーラーは異なるツールもありえる

    • インストーラーはPython製である必要はない

  • 単一と複数環境のそれぞれのシナリオに対応する

そしてpylock.tomlの細かいファイル仕様について説明が行われました。 ファイル名のとおりフォーマットはTOML形式です。 ファイルレベルの詳細情報としては以下が必要です。

lock-version = "1.0"
environments = ["..."]
requires-python = "..."
extras = ["..."]
dependency-groups = ["..."]
default-groups = ["..."]
created-by = "..."

そして[[packages]]以下に具体的なパッケージの情報が記述されます。 詳細は上記のファイル仕様を確認してください。

なぜ4年かかったのか

トークの後半ではタイトルの「なぜ仕様の策定に4年かかったのか」の話となります。 はじまりは4年どころか2019年に遡ります。 古いWebサイト（おそらくTwitter）でBrett氏がある人の発言に対して「そのロックファイルはPythonのオフィシャルではなくツール固有のものなので、安定性はツールの作者に聞いて欲しい」と返し、それに対してTzu-ping Chung氏から「交換可能なロックファイルフォーマットの議論をした方がよさそう」と返し、Brett氏が「そうですね、頭の片隅で考えています」という返答をしていました。 ちなみに、Tzu-ping氏はPyCon TaiwanのメンバーでEuroPythonにも参加しており、筆者も仲良くさせてもらっています。

../_images/brett-tp.jpg

ロックファイルについてのやりとり

2019年にrequirements.txt v2についての議論が行われて106ポスト、2020年にも継続して43ポストが投稿されました。

2021年にはPEP 665が提案され、359ポストの議論が行われ、最終的に却下されました。

その後2024年にPEP 751が提案され、974ポストの議論が行われました。 PEP 751は最初の提案から2度の改変を経て、2025年1月に提案したバージョンで承認されました。

ここに至るまで4年間で1,800件以上の投稿があったということで、ものすごく大変な作業だったなと感じました。 こうして作成されたロックファイルの仕様ですが、すでに各種ツールが対応しているそうです。

  • メインのロックファイルとして使用：PDM

  • インストール対応：PDM、uv

  • 生成に対応：PDM、uv、pip

このように長い年月をかけて仕様が策定されたロックファイル（pylock.toml）ですが、すでに各種パッケージング関連のツールも対応しており、今後標準として活用されていくと思われます。 このようにたくさんの人達の議論の上に仕様が策定されるということで、中心を担ったBrett Cannonさんには本当にお疲れ様と思いました。

A new safe external debugger interface for CPython

本トークではPythonのコア開発者でありSteering CouncilのメンバーでもあるPablo Galindo Salgado氏により、CPython 3.14の新機能である安全な外部デバッガー用のインターフェースについて、どのように作成されたか裏側が紹介されました。

Safe external debuggerはPEP 768で提案され、CPython 3.14から有効になります。 この機能により、実行中のCPythonに対して安全にアクセスできるデバッグ用のインターフェースが提供されます。

あわせてPythonのデバッガーであるPDBに、このインターフェースに接続する機能が追加されました。 以下のコマンド例のように-pオプションでプロセスIDを指定すると、そのプロセスのリモートデバッグができます。

python -m pdb -p 1234
../_images/pablo.jpg

Pablo Galindo Salgado氏

現代は脳の検査をするときにはMRIなどが使用できるが、Pythonの動作しているプログラムを調べるにはこの絵のように外から見ることしかできません（面白い絵ですね）。 この状況を改善するためにPEP 768が提案され、機能が追加されました。

以降はリモートデバッグがどのように動作するか、内部の動作が詳細に説明されました。 そしてデモが行われ、動作しているプロセスにデバッガーがアクセスするとそこで処理が止まり、安全に内部の情報を取得できることが確認できました。

CPython 3.14の新機能により、動作しているプログラムのデバッグが便利にできそうで楽しみです。

Performance improvements in 3.14 and maybe 3.15

Mark Shannon氏はCPythonのコア開発者で、Faster CPythonというPythonを高速化するチームをリードしています。 今回のトークでは3.14と3.15でのCPythonのパフォーマンス改善について語られました。

../_images/mark.jpg

Mark Shannon氏

上の画像のスライドにあるように、CPythonの高速化には「銀の弾丸はない」ということが語られていました。 CPythonでどの処理にどれだけの時間を使っているかを調べてみると以下の様になります。 まんべんなく時間を使っているため、どこか一カ所（例えばインタープリター）を速くしただけではパフォーマンスは大きく改善しないということです。

  • インタープリター：20%

  • JIT：9%

  • メモリの割り当てと解除：20%

  • GC：12%

  • lookupとdynamic：15%

  • それ以外：32%

CPython 3.15では「Top-of-stack Caching」という仕組みが入る見込みで、c = a + bというコードを例に、スタックの読み込みと書き込みの回数がキャッシュによって減るということが示されました。 以下の様な単純なコードを例にして実行してみると、Python 3.10では28452ms、Top-of-stack Cachingに対応したPythonでは64msとなっていました （ただこれはPython 3.10と比べているので、Python 3.14と比べた場合にパフォーマンスがどこまで改善しているのかが気になりました）。

import time

def loop(n):
    t = 0
    if n < 0:
        raise ValueError  # Put breakpoint here
    for i in range(n):
        t += 1
    return t

t = time.monotonic_ns()
loop(10_000_000)
d = time.monotonic_ns() - t
print (f"{d/1000_000:.0f} ms")

他にはCPython 3.14ではIncremental garbage collectionが導入され、少しGCが速くなり、一時停止の時間も短くなるとのことです。 3.15では”Candidate root” garbage collectionが導入されるかもとのことです。

最後にCPythonの継続的なパフォーマンス改善のために資金を提供して欲しいという呼びかけがありました。 Pythonの運用に多額の費用をかけていて、パフォーマンス向上から利益が得られる会社は、ぜひ話をしにきてほしい、とのことです。

CPythonは継続的にパフォーマンスが改善していますが、そのためにはコア開発者の方々の貢献が必要です。 資金の援助は重要な問題だなと感じました。

コラム：EuroPythonとコミュニティブース

このコラムはPython Asia Organization(PAO)の寺田(@terapyon)がお届けします。

EuroPythonには、 Community Organisers Activities として4つの企画がありました。

  • Community Organisers Open Space (コミュニティ主催者向けオープンスペース)

  • Community Organisers Lunch (コミュニティ主催者向け専用ランチスペース)

  • Community Booths (コミュニティ用のブース)

  • PyLadies Open Space & Lunch (PyLadiesオープンスペースとランチ)

私は、PyLadiesに所属してないので、それ以外の3つに参加してきました。

ブースはカンファレンス中の3日間設置できました。企業ブースとは少し離れた場所に設置され、全部で8個のコミュニティーが出展し、コミュニティの説明をしたりステッカーを配布していました。 私は、PAOとしてこのブースを設置することも一つの目的としてEuroPythonに参加しました。 PAOのブースは、アジアから参加した、主に日本や台湾のメンバーが担当し、アジア地区のPyConのことを紹介し、アジアからのお菓子を配ったり、寄付を集めました。この活動は2025年5月に開催されたPyCon US 2025のブースと同じようなものです。その時の様子は、PyCon US 2025カンファレンス開幕まで/1日目レポート のPAOブースコラムを御覧ください。

../_images/euro-pao-booth.jpg

PAOブース（左が寺田、右はTzu-ping氏）

初めてのEuroPythonへの参加でしたが、主催者はもちろんのこと参加者も非常にフレンドリーでした。ブースでは丁寧なサポートをしていただいたり、参加者も気さくに声を掛けていただき、大変有意義な時間を過ごせました。

時間や費用がかかりますが、来年もチャンスがあれば参加したいと思っています。

コミュニティ主催者向けのオープンスペースとコミュニティ主催者向け専用ランチスペースについては、続きのDay 3レポートを参照してください。

キーノート：Sebastián Ramírez

カンファレンス2日目夕方のキーノートスピーカーは、FastAPIの作者であるSebastián Ramírez氏です。 このキーノートでは「Behind the scenes of FastAPI and friends for developers and builders」と題して、FastAPIを作成して広めていく過程でSebastián氏がどのようなことをしてきたか、という内容が語られました。 Sebastián氏はEuroPythonに参加することは初めてだそうです。 トークの冒頭で「今日は話すことがたくさんあるので、Pabloより速くしゃべるよ」と言って会場の笑いをとっていました。 Pablo氏は早口だと筆者も思っていましたが、共通認識のようです。

../_images/sebastian.jpg

Sebastián Ramírez氏（スライドのイラストがかわいい）

トークの前半はFastAPI自体の簡単な紹介です。 Webフレームワークとして非常に多くのGitHubスターを持っており、日々大量にダウンロードされています。 Python Developer Surveyの調査でも利用が伸びており、PythonでWeb APIを構築するためのフレームワークとして広く利用されていることがわかります。

次にSebastián氏の過去について振り返ります。 コロンビア出身のSebastián氏は幼稚園の段階でドロップアウトしたそうです。 その後は自宅で勉強しながら、コンピューター、ビデオ編集、楽曲制作、グラフィックデザイン、Web開発、親の仕事用のシステム開発をしていたそうです。 コンピューターにはまり、cousera、edX、Udacityのようなオンラインコースで世界中の人と一緒に学んだそうです。 似たようなプロダクトを0から開発することを繰り返す中で、似たような複雑な処理があることに気づきました。 このような問題を解決するために、FastAPIなどのプロダクトを開発していると述べました。

プロダクトを開発するためのTipsとしてたくさんのポイントが示されました。 「メンテナーではなく、ユーザーのために最適化する」では以下のTipsが紹介されました。

  • ユーザーの視点を持つ

  • まずUXをデザインし、それに合わせて内部を作成する

  • 型ヒントを指定してオートコンプリートに対応する

  • 型ヒントに依存したインラインエラー

  • 明示的な引数にする、**kwargsは使わない

「新しいユーザーを捕まえる」ためのTipsは以下です。

  • 新鮮な目を持つ

  • 情報の空白になっている箇所を見つける

  • 初心者から意見を取り入れる

「情報の重複を減らす」ためのTipsは以下です。

  • コードの重複のことではない

  • 変数や設定の重複を減らす

  • 情報の重複は「キャッシュ」である

  • 重複が必要な情報は近くに配置する

  • 同期されない状態を減らす

「よいドキュメントを書く」では非常にたくさんのTipsが示されました。

  • 事前に説明すべきことは何か？

  • コンセプトを表すグラフ

  • すべてを説明する

  • 読み直して書き直して、きれいにする、文章を削る

  • コンセプトの重複を減らす

  • ユーザーが最小限の努力で最大の価値を得られるようにする

  • 空白、画像、絵文字、メモを入れて読みやすくする

  • 用語と概念の一貫性を保つ

  • 用語と概念のスタイルを設定する

  • パワーユーザーにも対応する

  • ドキュメント主導で開発する

  • ドキュメント上でサンプルコードがテストできる

トークの後半では大規模プロジェクトを管理するためのTipsがいくつも示されました。 ここでは作業量、課題の管理、プルリクエストの処理、レビューの進め方などが説明されました。 また、大規模プロジェクトの運営は「得るものもあれば、痛みを伴うこともある（Yes gain, yes pain）」とまとめられました。 最後に「問題を解決しよう（Solve a problem）」と伝えてトークが締めくくられました。

人気があり大規模プロジェクトでもあるFastAPIの作者Sebastián氏から示された多数のTipsは、「確かにそれ大事だよな」と思わせる説得力のあるものでした。 そして、一つ一つは当たり前のことだったりするんですが、その当たり前のことを当たり前にやり続けているであろうSebastián氏とFastAPIチームのすごさを感じました。

なおSebastián氏はPyCon JP 2025にキーノートスピーカーとして来日します。 本トークのような素晴らしいトークが聞けると思います。 筆者も日本での再会を楽しみにしています。

ソーシャルイベント

この日はSocial Eventです。 会場はStřelecký Islandという川の中にある島です。 ちなみに、この島がある川がヴルタヴァ川（モルダウ）です。

../_images/island.jpg

Social Event会場の島

../_images/social.jpg

Social Event会場の入り口

Social Eventでは食事が提供され、ドリンクも最初の1杯は無料です。 Bubenečという地元のクラフトビールがお店を出していたので、ここのビールを飲んでいました。

いろんな人と話をしましたが、途中であいにくの雨となり、テントがあるところからあまり動けなくなったのが残念です。 途中で入り口にもなっている建物の方にも行ったんですが、なぜか台湾と韓国から来たメンバーが3DSでマリオカートで遊んでました。 なぜここでマリオカートを…

他のビールも飲みたいなと思い、会場を後にしてSibeeriaというクラフトビールの店に行きました。 この店は日本に海外唯一の支店があり、チェコのクラフトビール情報を仕入れようと事前に訪問していました[1]。 無事チェコのSibeeriaに行くことができたので、個人的には大満足です。

../_images/sibeeria.jpg

チェコのSibeeriaに来たぞ！