PEP: 731 Title: C API Working Group Charter Author: Guido van Rossum
<guido@python.org>, Petr Viktorin <encukou@gmail.com>, Victor Stinner
<vstinner@python.org>, Steve Dower <steve.dower@python.org>, Irit
Katriel <irit@python.org> Discussions-To:
https://discuss.python.org/t/pep-731-c-api-working-group-charter/36117
Status: Active Type: Process Topic: Governance Created: 11-Oct-2023
Post-History: 13-Oct-2023, 23-May-2024, 19-Jun-2024 Resolution:
https://discuss.python.org/t/pep-731-c-api-working-group-charter/36117/12

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 an inventory 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.

Copyright

This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive.