Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 731 – C API Working Group Charter

Author:
Guido van Rossum <guido at Python.org>, Petr Viktorin <encukou at gmail >, Victor Stinner <vstinner at Python.org>, Steve Dower <steve.dower at Python.org>, Irit Katriel <irit at Python.org>
Discussions-To:
Discourse thread
Status:
Active
Type:
Process
Topic:
Governance
Created:
11-Oct-2023
Post-History:
13-Oct-2023, 23-May-2024, 19-Jun-2024
Resolution:
Discourse message
Table of Contents

Abstract

This PEP proposes to establish the C API Working Group: a small committee of Python core developers responsible for overseeing and coordinating the development and maintenance of the Python C API.

The working group will maintain documentation, test suites and tooling related to Python’s C API. As delegated by the Steering Council it is the deciding body for changes to the C API, from the addition or removal of individual API functions, types, etc., to the acceptance of new designs of a more or less radical nature.

The working group’s mandate is to represent the interests of all Python users, but especially all maintainers of code that uses Python’s C API, whether in the context of CPython, using an alternate Python implementation, or using a binding framework for other programming languages (such as C++ and Rust).

The working group serves at the pleasure of the Python Steering Council. This document serves as the working group’s charter.

Epigraph

KEEPER
Stop! Who would cross the Bridge of Death must answer me these questions three, ere the other side he see.
  1. What was Python named after?
  2. What was Python 2’s EOL?
  3. What is the optimal strategy to evolve the CPython C API?
LANCELOT
Auuuuuuuugh!

Motivation

Despite many discussions and in-person meetings at core developer sprints and Language Summits, and a thorough inventory of the problems and stakeholders of the C API, no consensus has been reached about many contentious issues, including, but not limited to:

  • Conventions for designing new API functions;
  • How to deal with compatibility;
  • What’s the best strategy for handling errors;
  • The future of the Stable ABI and the Limited API;
  • Whether to switch to a handle-based API convention (and how).

The general feeling is that there are too many stakeholders, proposals, requirements, constraints, and conventions, to make progress without having a small trusted group of deciders.

At the 2023 Language Summit in Salt Lake City it was decided to start work on aninventory of problems. At the 2023 core developer sprint in Brno this work is more or less finished and after a discussion it appeared that the next step is to establish a working group to ensure that we’re not stymied forever.

The Steering Council has indicated its desire to delegate decisions about the C API to such a working group, anticipating its formal establishment.

Specification

We propose the creation of a new group, the C API Working Group. This group will be responsible for overseeing and coordinating the development and maintenance of the Python C API. It will do this by establishing the principles underpinning the work and publishing guidelines that the core developers can refer to.

The “operations and process” section below describes how the working group operates and how it is governed.

Members

The members of the working group are:

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

Mandate

The working group’s mandate is to ensure that the Python C API is suitable for all users of and contributors to the API, without unduly preferencing one group over another. The working group will identify exemplar stakeholders, their needs and preferences, and will determine a plan for meeting these needs equitably and sustainably. It will oversee execution of the plan.

Operations and process

The working group has at least three members, comprised of prominent Python core developers. The members should consider the needs of the various stakeholders carefully.

The Steering Council appoints the initial working group. There is no term limit for working group members. Working group members may resign their position at any time, for any reason. There is an expectation that the membership will change over time.

To determine replacements, nominations will be collected from the core developer community. Self-nominations are allowed. The existing working group will then decide the replacement member(s) from the nominees. The expectation is that this will be done by fiat, but the working group can choose a replacement by any means they see fit, including a vote.

The working group remains accountable to the Steering Council. At any point, for any reason, the Steering Council could (publicly or privately) make a specific change or request a non-specific change to the composition of the working group.

We acknowledge that this is not a particularly democratic structure and puts a lot of faith in the working group. However, the Python community has a long history of success with structures that are not fully democratic! We believe that self-governance, cycling of membership, and accountability to the Steering Council will be sufficient to ensure that the C API workgroup is meeting the needs of the community.

The working group may operate primarily through reviews of GitHub issues and PRs. Regular meetings are likely not necessary, but the working group may set up video calls, a private chat, or whatever other mechanism they decide upon internally.

The working group should aim for transparency, posting all decisions publicly on discuss. Python.org, with a rationale if possible. Before making a decision, the working group should give all interested community members (as examples of different categories of stakeholders) a chance to weigh in. There should be at least a week between the start of a discussion and the working group’s decision.

Relationship with the Steering Council

Just like today, the Python Steering Council remains responsible for the overall direction of the Python C API and continues to decide on PEPs related to the C API, using the standard PEP review process (community discussion, etc.). The C API working group provides written opinions and recommendations to the Steering Council on PEPs related to the C API.

However, the working group can make smaller C API changes directly. The Steering Council may also choose to delegate decisions on some PEPs to the working group (exactly as any other PEP delegation).

Amendments

This PEP serves as a charter for the working group. Changes to its operation can be made either through a new PEP or through a change to this PEP. In either case, the change will be decided upon by the Steering Council after discussion in the community.

Contact

To ask the C API Working Group for a decision, community members may open an issue in the capi-workgroup/decisions repository.

Source:https://github / Python /peps/blob/main/peps/pep-0731.rst

Last modified:2024-06-27 15:01:11 GMT