HPy - Pythonのための改善されたC API

 (hpyproject.org)
9 ポイント 投稿者 GN⁺ 2024-10-07 | 1件のコメント | WhatsAppで共有
  • HPyはCでPythonを拡張するための新しいAPI
  • #include <Python.h> の代わりに #include <hpy.h> を使用

HPyの利点

  • CPythonでのゼロオーバーヘッド: HPyで書かれた拡張は「通常の」拡張と同じ速度で実行される
  • 代替実装でより高速: PyPy、GraalPyなどでより高速に実行される
  • 汎用バイナリ: HPy Universal ABIでビルドされた拡張は、CPython、PyPy、GraalPythonなどで修正なしにロード可能
  • 旧C-APIとの混在のための移行パス: レガシーC-API呼び出しとHPy API呼び出しを混在できる。すべてのコードが移行されれば、すべてのCPythonバージョン、PyPy、またはGraalPyで動作する汎用バイナリとしてコンパイルできる
  • デバッグモード: メモリリーク、オブジェクトの不正な寿命、APIの誤用などを簡単に特定できる
  • より良いAPI: 標準のPython/C APIの限界を克服し、より一貫性があり、より高品質な拡張を生成し、バグが生じにくいよう設計されている
  • 進化可能性: PEP 620でよく要約されているように、標準のPython/C APIは多くの内部実装詳細を露出しており、C APIの進化を困難にしている。HPyはすべての内部実装詳細を隠すため、この問題がない

現在の状況

  • HPyは活発に開発中。0.9.0が最新のアルファリリースだが、まもなくアルファ段階を脱し、安定リリースに向けて取り組んでいる
  • HPy ABIは現在十分に安定しており、今後のリリースで前方および後方のバイナリ互換性の約束を果たせると考えている
  • 重要なパッケージを移行するのに十分なユースケースをAPIが現在カバーできていると考えている（特にnumpyポートを参照）
  • ポーティングガイドと広範なドキュメント（特にAPIリファレンス）も提供している
  • 設計議論と新たな要件について常にオープンである

HPy互換拡張

  • ultrajson-hpy: HPyに移植された最初の実用モジュール
  • piconumpy: 名前の通り、カスタム型を定義する最小限のnumpy風モジュール
  • numpy: 野心的な目標の1つはnumpyをHPyへ移植し、この経験を使ってAPI設計の方法をよりよく理解すること。このポートはテストスイート通過直前
  • matplotlib: NumPyへの依存関係もあるため、汎用モードへの移行は完全には完了していない。HPyではレガシーC API関数を引き続き呼び出しつつテストスイートを正常に実行できるよう、レガシー互換APIを提供している
  • kiwi-solver: Matplotlibの依存関係で、汎用モードに完全移植済み

GN⁺の見解

  • HPyはPython/C APIの限界を克服し、より優れた拡張性と移植性を提供する非常に有望なプロジェクト
  • 特にPyPy、GraalPyのような代替Python実装で、性能向上の可能性が大きい点が魅力的
  • レガシーC APIからの移行は難しい可能性があるが、HPyは段階的な移行パスを提供し、この過程をはるかに管理しやすくしている
  • HPyを採用する際は、既存のビルドシステムおよび配布パイプラインとの統合、アップストリームプロジェクトの受容、そしてHPy自体の成熟度と安定性を考慮する必要がある
  • HPyと似た目標を持つ他のプロジェクトとしては、CythonやRustのPyO3のようなものがある。これらは低水準C APIの代わりに高水準言語を使う点でHPyとは異なる

関連記事

1件のコメント

 
GN⁺ 2024-10-07
Hacker Newsのコメント

  • C API作業で最も面倒な部分は、コンパイル／リンクフラグの設定です。python3-configはOSレベルでしか動作せず、pipでインストールしたパッケージにアクセスするには扱いにくいです。python3 -m venvはこのようなスクリプトを生成せず、anaconda/minicondaも問題があります。各パッケージがハードコードされたpython3 -c "import sys: print..."呼び出しでビルドスクリプトを汚染しています。CPythonにpython3 -m sysconfig --jsonフラグを追加するPRを出しました

  • Python言語が1つの実装に過度に集中していることは、長期的には成功への脅威になり得ます。Webサーバー、コマンドラインプログラム、組み込み機器では要件が異なります。このプロジェクトが、実装の詳細を露出しないPythonのC APIへの置き換えに成功すれば、代替実装の保守や新技術の実験がより容易になるかもしれません

  • このプロジェクトがバージョン非依存のPythonバインディングを提供するのか気になります。現状では各バージョンごとに別々にバインディングをビルドしており、CI/CDの時間をかなり消費しています

  • HPy拡張とCython/pybind11実装を、性能および開発時間の観点で比較するベンチマークがあると面白そうです

  • このプロジェクトがPyBind11やnanobindのようなライブラリとどう噛み合うのかが明確ではありません。これらのライブラリを同じ方法で使うには、書き直しが必要になりそうです

  • 最近、新しくCで書かれる拡張がどれくらいあるのか気になります。主流はBoost Python、pybind、PyO3のようなものだと思っていました

  • CPythonバインディングを最小限のオーバーヘッドで実装することについてよく投稿しており、いくつかの提案、質問、懸念を共有したいです。HPyプロジェクトのランディングページとリポジトリのREADMEは再構成した方がよいでしょう。PyPy、GraalPython、その他のPythonランタイムに関する支持の統計があれば、さらに説得力が増すはずです

  • HPyContextのようなカプセル化されたコンテキストオブジェクトを使うのは、マルチスレッドなPythonの将来や複雑な環境で有用です。しかし、HPyContextがCPythonのシングルトンにリダイレクトされるのであれば、問題の解決にはなりません

  • 2019年のベンチマークでは、CPythonのMETH_FASTCALL呼び出し規約に言及していますが、比較はされていません。性能に関心があるなら、文字列フォーマッタを使わずにタプルから直接引数をパースする方がよいです

  • PythonでCヘッダーを渡して共有ライブラリをロードし、構造体を利用可能にして関数を呼び出せる、luajitのffiのようなシンプルなものがあるのか気になります

  • PythonからGoを呼び出すことに関心があり、gopyはcgo向けのPythonバインディングを生成します。HPy<->cgoの方がオーバーヘッドをより小さくできるかもしれません

  • 20年前にこの作業が完了していたら、Pythonエコシステムがどれほど違っていたか想像してみてほしいです