Following system colour scheme - Python 增強提案 Selected dark colour scheme - Python 增強提案 Selected light colour scheme - Python 增強提案

Python 增強提案 (Python Enhancement Proposals)

PEP 731 – C API 工作小組章程

作者:
Guido van Rossum <guido at python.org>, Petr Viktorin <encukou at gmail.com>, Victor Stinner <vstinner at python.org>, Steve Dower <steve.dower at python.org>, Irit Katriel <irit at python.org>
討論於:
Discourse 討論串
狀態:
作用中
類型:
流程
主題:
治理
建立日期:
2023-10-11
公告歷史:
2023-10-13, 2024-05-23, 2024-06-19
決議:
Discourse 訊息
目錄

摘要

本 PEP 提議成立 C API 工作小組：這是一個由 Python 核心開發者組成的小型委員會，負責監督並協調 Python C API 的開發與維護。

該工作小組將負責維護與 Python C API 相關的文件、測試套件與工具。受指導委員會委託，該小組是 C API 變更的決策機構，範圍涵蓋從新增或移除個別 API 函式、型別等，到採納具備一定程度變革性的新設計。

工作小組的任務是代表所有 Python 使用者的利益，特別是所有維護使用 Python C API 程式碼的開發者，無論其是在 CPython 環境下，還是使用其他 Python 實作，或是使用其他程式語言（如 C++ 和 Rust）的綁定框架。

工作小組聽命於 Python 指導委員會。本文件即為該工作小組的章程。

題詞

守門人
站住！若想穿越死亡之橋，必先回答我這三個問題，否則休想見到彼岸。
  1. Python 的命名源自何處？
  2. Python 2 的生命週期結束（EOL）日期為何？
  3. 發展 CPython C API 的最佳策略是什麼？
蘭斯洛特（LANCELOT）
啊啊啊啊啊！

動機

儘管在核心開發者衝刺會議（sprints）和語言高峰會（Language Summits）中進行了多次討論與面對面會議，並對 C API 的問題與利害關係人進行了詳盡盤點，但在許多具爭議性的議題上仍未達成共識，這些議題包括但不限於：

  • 設計新 API 函式的規範；
  • 如何處理相容性問題；
  • 處理錯誤的最佳策略；
  • 穩定 ABI（Stable ABI）與有限 API（Limited API）的未來；
  • 是否要轉換為基於控制代碼（handle-based）的 API 慣例（以及該如何實作）。

普遍的感受是，由於利害關係人、提案、需求、限制與慣例太多，若沒有一個小型且受信任的決策小組，將難以取得進展。

在鹽湖城舉行的 2023 年語言高峰會上，決定開始編製一份問題清單。在布爾諾舉行的 2023 年核心開發者衝刺會議上，這項工作已大致完成；經過討論後，顯然下一步是成立一個工作小組，以確保我們不會陷入永遠無法突破的僵局。

指導委員會已表示希望將 C API 相關決策委託給此類工作小組，並預期其正式成立。

規範

我們提議成立一個新的小組：C API 工作小組。該小組將負責監督與協調 Python C API 的開發與維護。其做法是確立支撐這項工作的原則，並發布可供核心開發者參考的指南。

下方的「運作與流程」章節說明了工作小組的運作與治理方式。

成員

工作小組成員如下：

  • Erlend Aasland
  • Petr Viktorin
  • Serhiy Storchaka
  • Steve Dower
  • Victor Stinner

授權範圍

工作小組的任務是確保 Python C API 適用於所有使用者與貢獻者，且不會不適當地偏袒任何群體。工作小組將識別典範利害關係人、其需求與偏好，並擬定公平且永續的滿足需求計畫。該小組將監督計畫的執行。

運作與流程

工作小組至少由三名成員組成，成員皆為傑出的 Python 核心開發者。成員應審慎考量各利害關係人的需求。

由指導委員會任命初始工作小組成員。工作小組成員無任期限制。成員可隨時基於任何理由辭職。預期成員名單將隨時間更迭。

若需替換成員，將從核心開發者社群收集提名。允許自我提名。隨後由既有工作小組從被提名人中決定替換人選。預期此過程將透過指令（fiat）完成，但工作小組也可選擇任何其認為合適的方式（包括投票）來選出替換成員。

工作小組仍須對指導委員會負責。指導委員會可隨時基於任何理由（公開或私下）對工作小組的組成做出特定變更或要求非特定變更。

我們承認這並非一個特別民主的架構，且對工作小組寄予厚望。然而，Python 社群在非完全民主的架構下已有悠久的成功歷史！我們相信自我治理、成員輪替以及對指導委員會負責，將足以確保 C API 工作小組能滿足社群需求。

工作小組主要可透過審查 GitHub Issue 與 PR 來運作。通常不需要定期會議，但工作小組可視需要自行決定是否召開視訊會議、使用私人聊天室或任何其他溝通機制。

工作小組應追求透明化，將所有決策公開發布至 discuss.python.org，並儘可能提供理由。在做出決定前，工作小組應給予所有感興趣的社群成員（作為不同類型利害關係人的代表）發表意見的機會。從開始討論到工作小組做出決定，應至少間隔一週。

與指導委員會的關係

與現行機制相同，Python 指導委員會仍負責 Python C API 的整體方向，並持續負責對相關 PEP 做出最終決定，採取標準的 PEP 審查流程（社群討論等）。C API 工作小組則針對相關 PEP 向指導委員會提供書面意見與建議。

不過，工作小組可直接做出較小的 C API 變更。指導委員會也可選擇將部分 PEP 的決策權委託給工作小組（與其他任何 PEP 委託方式相同）。

修訂

本 PEP 作為工作小組的章程。若要變更運作方式，可透過新的 PEP 或修改本 PEP 來達成。無論何種方式，變更皆須由指導委員會在社群討論後決定。

聯絡方式

社群成員若需請求 C API 工作小組做出決策，可於 capi-workgroup/decisions 儲存庫開啟一個 issue。

原始碼：https://github.com/python/peps/blob/main/peps/pep-0731.rst

最後修改：2025-10-08 12:21:13 GMT