PEP 731: C API Working Group Charter (#3476)
(Co-authored by all listed co-authors, and also by Jelle, since we cribbed a lot of words from his PEP 729.)
This commit is contained in:
parent
52a3481381
commit
32adf8fb23
|
@ -608,6 +608,7 @@ peps/pep-0726.rst @AA-Turner
|
|||
peps/pep-0727.rst @JelleZijlstra
|
||||
peps/pep-0729.rst @JelleZijlstra @hauntsaninja
|
||||
peps/pep-0730.rst @ned-deily
|
||||
peps/pep-0731.rst @gvanrossum @encukou @vstinner @zooba @iritkatriel
|
||||
# ...
|
||||
# peps/pep-0754.rst
|
||||
# ...
|
||||
|
|
|
@ -0,0 +1,181 @@
|
|||
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>
|
||||
Status: Draft
|
||||
Type: Process
|
||||
Created: 11-Oct-2023
|
||||
Python-Version: 3.13
|
||||
|
||||
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.
|
||||
The working group's members are the listed authors of this PEP.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
This document is placed in the public domain or under the
|
||||
CC0-1.0-Universal license, whichever is more permissive.
|
Loading…
Reference in New Issue