207 lines
7.6 KiB
ReStructuredText
207 lines
7.6 KiB
ReStructuredText
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 <https://discuss.python.org/t/pep-731-c-api-working-group-charter/36117>`__,
|
|
`23-May-2024 <https://discuss.python.org/t/c-api-working-group-vacancy/54015>`__,
|
|
`19-Jun-2024 <https://discuss.python.org/t/c-api-working-group-vacancy-again/56167>`__
|
|
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.
|
|
|
|
#. What was Python named after?
|
|
#. What was Python 2's EOL?
|
|
#. 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 <https://github.com/capi-working-group/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 <https://github.com/python/steering-council/issues/201#issuecomment-1648848155>`__
|
|
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 <https://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 <https://github.com/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.
|