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

Python 增强提案

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年5月23日，2024年6月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 的生命周期终结日期是什么？
  3. 发展 CPython C API 的最佳策略是什么？
兰斯洛特
啊呜啊呜啊呜！

动机

尽管在核心开发者冲刺和语言峰会上进行了多次讨论和面对面会议，并对 C API 的问题和利益相关者进行了全面梳理，但在许多有争议的问题上仍未达成共识，包括但不限于

  • 设计新 API 函数的约定；
  • 如何处理兼容性；
  • 处理错误的最佳策略是什么；
  • 稳定 ABI 和受限 API 的未来；
  • 是否切换到基于句柄的 API 约定（以及如何切换）。

普遍的感觉是，利益相关者、提案、需求、约束和约定过多，如果没有一个规模较小且值得信赖的决策小组，将无法取得进展。

在 2023 年盐湖城的语言峰会上，决定开始着手进行问题清单的工作。在 2023 年布尔诺的核心开发者冲刺中，这项工作或多或少已经完成，经过讨论后，似乎下一步是成立一个工作组，以确保我们不会永远停滞不前。

指导委员会已表示希望将有关 C API 的决策委托给这样一个工作组，并预见到其正式成立。

规范

我们提议创建一个新的组织，即 C API 工作组。该小组将负责监督和协调 Python C API 的开发和维护。它将通过建立工作原则和发布核心开发人员可以参考的指南来做到这一点。

下面的“运作和流程”部分描述了工作组的运作方式及其治理方式。

成员

工作组成员为

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

任务

工作组的任务是确保 Python C API 适用于所有 API 用户和贡献者，而不 unduly 偏袒某一组用户。工作组将识别典型利益相关者、他们的需求和偏好，并确定一个公平且可持续地满足这些需求的计划。它将监督计划的执行。

运作和流程

工作组至少有 3 名成员，由知名的 Python 核心开发者组成。成员应仔细考虑各种利益相关者的需求。

指导委员会任命初始工作组。工作组成员没有任期限制。工作组成员可以随时、任何理由辞职。预计成员构成会随着时间推移而发生变化。

为了确定替代成员，将从核心开发者社区收集提名。允许自我提名。然后，现有工作组将从提名人中决定替代成员。预计这将由工作组自行决定，但工作组可以选择任何他们认为合适的方式来选择替代成员，包括投票。

工作组仍然对指导委员会负责。在任何时间点，出于任何原因，指导委员会都可以（公开或私下）对工作组的构成进行具体更改或请求非具体更改。

我们承认，这不是一个特别民主的结构，并且对工作组寄予了很大的信任。但是，Python 社区在非完全民主的结构方面有着悠久的成功历史！我们相信，自我治理、成员轮换和对指导委员会的责任将足以确保 C API 工作组满足社区的需求。

工作组可能主要通过审查 GitHub 问题和 PR 来运作。定期会议可能没有必要，但工作组可能会设置视频通话、私人聊天或他们内部决定的任何其他机制。

工作组应力求透明，在discuss.python.org 上公开发布所有决策，并在可能的情况下提供理由。在做出决定之前，工作组应让所有感兴趣的社区成员（作为不同类别利益相关者的示例）有机会发表意见。在工作组做出决定之前，至少应有一周的讨论时间。

与指导委员会的关系

与今天一样，Python 指导委员会仍然负责 Python C API 的总体方向，并继续使用标准的 PEP 审查流程（社区讨论等）来决定与 C API 相关的 PEP。C API 工作组向指导委员会提供与 C API 相关的 PEP 的书面意见和建议。

但是，工作组可以直接进行较小的 C API 更改。指导委员会也可以选择将某些 PEP 的决策委托给工作组（与任何其他 PEP 委托完全相同）。

修订

本 PEP 作为工作组的章程。其运作方式的更改可以通过新的 PEP 或对本 PEP 的更改来进行。无论哪种情况，更改都将在社区讨论后由指导委员会决定。

联系方式

要请求 C API 工作组做出决定，社区成员可以在capi-workgroup/decisions 存储库中打开一个问题。

来源：https://github.com/python/peps/blob/main/peps/pep-0731.rst

上次修改时间：GMT 2024-06-27 15:01:11