一時的なABIの変更

マーク・シャノン氏による

なぜ、安定したABIを変更する必要があるのか？ それは、PyObjectヘッダーに現在使用できない32ビットの空き領域があるからです。

struct _object { Py_ssize_t ob_refcnt; // マーク氏は、この構造体の上位ビットを使用したいと考えています。 PyTypeObject * ob_type; };

PEP 683がPython 3.12で採用されて以来、ob_refcntは実質的に32ビットの整数として扱われていますが、これらのビットは依然として他の用途には利用できず、互換性の問題を避けるための措置です。
もしPythonのコアチームがこれらのビットを別の用途に再利用できれば、マーク氏はより優れたガベージコレクタや高速なメモリ割り当てを実装できる可能性があります。

安定したABIを変更することは「比較的簡単ですが、おそらく苦痛を伴うでしょう」という言葉は、ユーザーがコードを移植したり、再コンパイルしたり、複数のABIをサポートする必要があることを指しています。

「まあ…いずれそうなりますよ」とマーク氏は述べ、free-threadingのためのabi3とabi3tについて、そして安定したABIに依存するPythonパッケージが新しいabi3t ABIに移行する必要があることを示唆しました。

トーマス・ワウテルス氏は、最終的に安定したABIがabi3tのみになるまで待つという回答をしました。
free-threadingのPythonは、オブジェクトのレイアウトに関して、安定したABIとの互換性を保証していません。一方、free-threadingではないPythonでは、ob_refcntに関する詳細が安定したABIで公開されています。

既存の安定したABIを変更することに対する強い意欲は見られませんでした。
free-threadingがPythonの新しいデフォルトになった後、オブジェクトヘッダーの内部構造を公開する安定したABIは廃止され、マーク氏とそのチームはオブジェクトヘッダーに対する変更をより自由にできるようになります。ただ、辛抱強く待つ必要があります！

より安全で汎用的な中断機能

ダニエレ・パルメジアーニ氏による

ダニエレ氏は、現在のPythonにおけるスレッドを使用した構造化された並行処理の実装における課題を提示しました。それは、失敗したタスクやキャンセルされたタスクを安全に中断できないことです。

例えば、あるウェブリクエストの結果として、2つのI/Oバウンドな並列データベースクエリ（タスクAとタスクB）が送信されたとします。もしタスクAがエラーで早期に終了した場合、タスクBの結果は不要になります。なぜなら、例外が発生するからです。
しかし、現状ではタスクBをキャンセルする方法はありません。そのため、タスクBの結果を待機し、タスクAからの例外を伝播する前に破棄しています。

割り込みは、このキャンセルメカニズムを実装する一つの方法です。
ダニエレは、割り込みによるキャンセル機能を実装するための仕組みは「CPythonには既に存在しますが、Pythonレベルでは公開されていません」と説明しました。そして、なぜこの機能が公開されていないのか？それは、この機能が「危険な落とし穴」の大きな原因になるからです。

ダニエレは、危険な機能を直接公開するのではなく、ユーザーが安全に割り込みを処理する方法を提供したいと考えています。そのために、ダニエレは、割り込みの影響を受けない「保護されたスコープ」を追加することを提案しています。このスコープでは、コンテキストマネージャーの`__enter__()`メソッドと`__exit__()`メソッドが割り込みから保護され、確実に実行されることが保証されます。

「現在、割り込みがある状態で、コンテキストマネージャーのクリーンアップ処理に本当に頼ることはできません」。
`signal`モジュールのドキュメントを読むと、シグナルは安全ではないため、無効にすることを推奨しています。「シグナルのドキュメントにそのような記述があるのは少し奇妙です」。

「これはパフォーマンスに良いことですか？いいえ、より多くのバイトコードを追加します」とダニエレはプレゼンテーションを締めくくり、「しかし、マーク・シャノンを喜ばせるようにしました」。ダニエレは、この機能の実装に興味のある人に、ぜひ連絡するように呼びかけました。

EktuPy、Scratch、そしてPython
クシャル・ダス著

クシャル・ダスは、Scratchを使ってプログラミングを学ぶ若いプログラマーたちにPythonを教えるためのプロジェクトに関する短いプレゼンテーションを行いました。Scratchは、テキストではなくブロックを使ってアニメーション、ゲーム、その他のメディア関連プログラムを作成するプログラミング言語です。

EktuPyは、Scratchで人気のあった多くの機能を搭載しており、ゲームやアニメーションなどのメディアに重点を置いたり、「リミックス」の概念を取り入れたりすることで、初心者プログラマーが圧倒されるような空白のキャンバスではなく、すぐに使い始められる基盤を提供します。EktuPyは、ブロックベースのプログラミング言語と、Pythonのようなテキストベースの言語との間のギャップを埋めることを目指しています。

CPythonのAGENTS.mdファイルについて

Gregory P. SmithとŁukasz Langaによる

CPythonは、他の多くのオープンソースプロジェクトと同様に、LLMエージェントを使用している人々からの多くの貢献を受けています。Gregory P. SmithとŁukasz Langaは、CPythonのリポジトリにシンプルなAGENTS.mdファイルを追加することについて、コア開発者から意見を聞きたいと考えました。目的は、CPythonへの貢献方法に関する基本的なガイダンス（例えば、開発者ガイドへのリンクなど）を提供することで、エージェントを使用して作成される多数のプルリクエストの品質を向上させることでした。

Gregは「リポジトリにAGENTS.mdを追加することに反対する人はいるか？」と問いかけましたが、コア開発者の中から反対する人がいませんでした。「思ったよりも簡単だった」。Thomas Woutersは、「AGENTS.mdファイルが必要になるのは残念だ」とコメントしました。

別の問題として、AGENTS.mdファイルは、新しいものを追加したいと考えている人々からの多くの外部からの貢献を受けやすいという点が挙げられました。Gregは、ファイルは非常にシンプルに保たれ、「ほとんど変更されない」ようにすると明言し、コアチームが「ファイルを変更するプルリクエストを却下する」ことを提案しました。

Seth Larsonは、貢献の改善を定量化することについて質問し、Pythonセキュリティレスポンステチームでは、LLMによって生成されたレポートの件数が増加していると指摘しました。セキュリティポリシーの変更や脅威モデルの追加は効果があったように見えましたが、それを証明するのは困難でした。

Łukaszは、エージェント主導の貢献が非常に多いため、CPythonがいつか多くの外部からの貢献を受け付けられなくなる可能性があるという悲観的な見解を共有しました。

PEP 836（JIT go brrr）をお読みください。

Ken Jinによる

言語サミットの短いプレゼンテーションの最後に、ケン・ジン氏が簡単な要望を伝えました。それは、PEP 836 を読んでいただきたいというものです。ケン氏は、PEP 836 に関する議論のスレッドでわずか33件の返信しか受けておらず、コア開発者（そしてこのブログ記事を読んでいるすべての方）に、PEP を読んで「どの点に反対があるか教えてください」と呼びかけました。