diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 668bb5aceb..06213bdf40 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -4,5 +4,5 @@
# It uses the same pattern rule for gitignore file
# https://git-scm.com/docs/gitignore#_pattern_format
-
-garbage_collector.rst @pablogsal
+# PSRT member list owned by PSRT admins.
+developer-workflow/psrt*.csv @warsaw @ewdurbin @ned-deily @sethmlarson
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index 218b07b63b..c4a7d25457 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -18,13 +18,12 @@ Please be aware that our workflow does deviate slightly from the typical GitHub
project. Details on how to properly submit a pull request are covered in
[Lifecycle of a Pull Request](https://devguide.python.org/pullrequest/).
We utilize various bots and status checks to help with this, so do follow the
-comments they leave and their "Details" links, respectively. The key points of
-our workflow that are not covered by a bot or status check are:
+comments they leave and their "Details" links, respectively.
-- All discussions that are not directly related to the code in the pull request
- should happen on the [issue tracker](https://devguide.python.org/tracker/)
-- Upon your first non-trivial pull request (which includes documentation changes),
- feel free to add yourself to [`Misc/ACKS`](https://github.com/python/cpython/blob/main/Misc/ACKS)
+The final key part of our workflow is that all discussions that are not
+directly related to the code in the pull request should happen on the
+[issue tracker](https://devguide.python.org/tracker/), generally in the
+pull request's parent issue.
## Setting Expectations
@@ -33,8 +32,8 @@ Due to the fact that this project is entirely volunteer-run (that is, no one is
to work on Python full-time), we unfortunately can make no guarantees as to if
or when a core developer will get around to reviewing your pull request.
If no core developer has done a review or responded to changes made because of a
-"changes requested" review, please feel free to email [python-dev](https://mail.python.org/mailman3/lists/python-dev.python.org/) to ask if
-someone could take a look at your pull request.
+"changes requested" review, please consider seeking assistance through the
+[Core Development Discourse category](https://discuss.python.org/c/core-dev/23).
## Code of Conduct
diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml
index b160c6ea11..f6d55b1247 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.yml
+++ b/.github/ISSUE_TEMPLATE/bug_report.yml
@@ -1,7 +1,7 @@
name: "Bug report"
description: Create a report to help us improve the Python devguide
title: "Bug:
"
-labels: ["bug"]
+labels: ["type-bug"]
assignees: []
body:
diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml
index a4413c137a..7a7e9ec805 100644
--- a/.github/ISSUE_TEMPLATE/feature_request.yml
+++ b/.github/ISSUE_TEMPLATE/feature_request.yml
@@ -1,7 +1,7 @@
name: "Feature request"
description: Suggest an idea for the Python devguide
title: "Feature: "
-labels: ["enhancement"]
+labels: ["type-feature"]
assignees: []
body:
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index c990752808..23f03616cf 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -1,7 +1,23 @@
version: 2
updates:
+- package-ecosystem: "github-actions"
+ directory: "/"
+ schedule:
+ interval: monthly
+ assignees:
+ - "ezio-melotti"
+ groups:
+ actions:
+ patterns:
+ - "*"
+
- package-ecosystem: pip
directory: "/"
schedule:
interval: monthly
- open-pull-requests-limit: 10
+ assignees:
+ - "ezio-melotti"
+ groups:
+ pip:
+ patterns:
+ - "*"
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 22ad254ebf..b85a45c1bb 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -12,8 +12,8 @@ jobs:
timeout-minutes: 10
steps:
- - uses: actions/checkout@v4
- - uses: actions/setup-python@v5
+ - uses: actions/checkout@v6
+ - uses: actions/setup-python@v6
with:
python-version: "3"
- name: Install uv
diff --git a/.github/workflows/documentation-links.yml b/.github/workflows/documentation-links.yml
deleted file mode 100644
index bacb37d07c..0000000000
--- a/.github/workflows/documentation-links.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-name: Read the Docs PR preview
-on:
- pull_request_target:
- types:
- - opened
-
-permissions:
- pull-requests: write
-
-jobs:
- documentation-links:
- runs-on: ubuntu-latest
- timeout-minutes: 10
- steps:
- - uses: readthedocs/actions/preview@v1
- with:
- project-slug: "cpython-devguide"
- single-version: "true"
diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml
index 5c9caf026f..4622f995aa 100644
--- a/.github/workflows/lint.yml
+++ b/.github/workflows/lint.yml
@@ -8,8 +8,8 @@ jobs:
timeout-minutes: 10
steps:
- - uses: actions/checkout@v4
- - uses: actions/setup-python@v4
+ - uses: actions/checkout@v6
+ - uses: actions/setup-python@v6
with:
python-version: "3.x"
- - uses: pre-commit/action@v3.0.0
+ - uses: pre-commit/action@v3.0.1
diff --git a/.gitignore b/.gitignore
index df4dc9415a..f61a108300 100644
--- a/.gitignore
+++ b/.gitignore
@@ -90,4 +90,5 @@ celerybeat-schedule
# Generated CSV and SVG files
include/branches.csv
include/end-of-life.csv
-include/release-cycle.svg
+_static/release-cycle.svg
+_static/release-cycle-all.svg
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index ae27fd1f23..c5beee4a37 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -7,14 +7,12 @@ repos:
args: [--exit-non-zero-on-fix]
- id: ruff-format
name: Run Ruff (format)
- args: [--check]
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0
hooks:
- id: check-case-conflict
- id: check-merge-conflict
- - id: check-json
- id: check-yaml
- id: debug-statements
- id: end-of-file-fixer
diff --git a/Makefile b/Makefile
index 5a33d50897..a26ad48e00 100644
--- a/Makefile
+++ b/Makefile
@@ -10,8 +10,8 @@ SPHINXBUILD = $(VENVDIR)/bin/sphinx-build
# there are duplicate labels. These cause warnings, which prevent the
# build from finishing. Turn off --fail-on-warning so we can see the
# finished results.
-#SPHINXOPTS = --fail-on-warning --keep-going
-SPHINXOPTS = --keep-going
+#SPHINXOPTS = --fail-on-warning
+SPHINXOPTS =
BUILDDIR = _build
BUILDER = html
JOBS = auto
@@ -22,7 +22,8 @@ REQUIREMENTS = requirements.txt
_ALL_SPHINX_OPTS = --jobs $(JOBS) $(SPHINXOPTS)
_RELEASE_CYCLE = include/branches.csv \
include/end-of-life.csv \
- include/release-cycle.svg
+ _static/release-cycle-all.svg \
+ _static/release-cycle.svg
.PHONY: help
help:
@@ -57,6 +58,7 @@ venv:
.PHONY: ensure-venv
ensure-venv:
@if [ ! -d $(VENVDIR) ] ; then \
+ set -e; \
echo "Creating venv in $(VENVDIR)"; \
if $(UV) --version >/dev/null 2>&1; then \
$(UV) venv --python=$(PYTHON) $(VENVDIR); \
@@ -101,15 +103,20 @@ _ensure-pre-commit:
lint: _ensure-pre-commit
$(VENVDIR)/bin/python3 -m pre_commit run --all-files
-# Defined so that "include/release-cycle.json"
-# doesn't fall through to the catch-all target.
-include/release-cycle.json:
- @exit
-
-$(_RELEASE_CYCLE): include/release-cycle.json
+# Generate all release cycle files together with a single script invocation
+# Use branches.csv as the primary target, others depend on it
+include/branches.csv:
$(VENVDIR)/bin/python3 _tools/generate_release_cycle.py
@echo Release cycle data generated.
+# Other files are generated together with branches.csv
+include/end-of-life.csv: include/branches.csv
+ @:
+_static/release-cycle-all.svg: include/branches.csv
+ @:
+_static/release-cycle.svg: include/branches.csv
+ @:
+
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option.
.PHONY: Makefile
diff --git a/README.rst b/README.rst
index fde4a6c277..e2f0c5617c 100644
--- a/README.rst
+++ b/README.rst
@@ -17,7 +17,7 @@ The CPython Developer's Guide
This guide covers how to contribute to CPython. It is known by the
-nickname of "the devguide" by the Python core developers.
+nickname of "the devguide" by the Python core team.
The official home of this guide is https://devguide.python.org.
diff --git a/_static/devguide_overrides.css b/_static/devguide_overrides.css
index 8e2c7c6fca..625a9dda2d 100644
--- a/_static/devguide_overrides.css
+++ b/_static/devguide_overrides.css
@@ -6,79 +6,6 @@
height: 110px;
}
-/* Release cycle chart */
-
-.release-cycle-chart {
- width: 100%;
-}
-
-.release-cycle-chart .release-cycle-year-line {
- stroke: var(--color-foreground-primary);
- stroke-width: 0.8px;
- opacity: 75%;
-}
-
-.release-cycle-chart .release-cycle-year-text {
- fill: var(--color-foreground-primary);
-}
-
-.release-cycle-chart .release-cycle-today-line {
- stroke: var(--color-brand-primary);
- stroke-width: 1.6px;
-}
-
-.release-cycle-chart .release-cycle-row-shade {
- fill: var(--color-background-item);
- opacity: 50%;
-}
-
-.release-cycle-chart .release-cycle-version-label {
- fill: var(--color-foreground-primary);
-}
-
-.release-cycle-chart .release-cycle-blob {
- stroke-width: 1.6px;
- /* default colours, overridden below for individual statuses */
- fill: var(--color-background-primary);
- stroke: var(--color-foreground-primary);
-}
-
-.release-cycle-chart .release-cycle-blob-label {
- /* white looks good on both light & dark */
- fill: white;
-}
-
-.release-cycle-chart .release-cycle-blob-label.release-cycle-blob-security,
-.release-cycle-chart .release-cycle-blob-label.release-cycle-blob-bugfix {
- /* but use black to improve contrast for lighter backgrounds */
- fill: black;
-}
-
-.release-cycle-chart .release-cycle-blob.release-cycle-blob-end-of-life {
- fill: #DD2200;
- stroke: #FF8888;
-}
-
-.release-cycle-chart .release-cycle-blob.release-cycle-blob-security {
- fill: #FFDD44;
- stroke: #FF8800;
-}
-
-.release-cycle-chart .release-cycle-blob.release-cycle-blob-bugfix {
- fill: #00DD22;
- stroke: #008844;
-}
-
-.release-cycle-chart .release-cycle-blob.release-cycle-blob-prerelease {
- fill: teal;
- stroke: darkgreen;
-}
-
-.release-cycle-chart .release-cycle-blob.release-cycle-blob-feature {
- fill: #2222EE;
- stroke: #008888;
-}
-
.good pre {
border-left: 3px solid rgba(74, 182, 93, 1);
}
diff --git a/_static/python-cyclic-gc-1-new-page.png b/_static/python-cyclic-gc-1-new-page.png
deleted file mode 100644
index 2ddac50f4b..0000000000
Binary files a/_static/python-cyclic-gc-1-new-page.png and /dev/null differ
diff --git a/_static/python-cyclic-gc-2-new-page.png b/_static/python-cyclic-gc-2-new-page.png
deleted file mode 100644
index 159aeeb050..0000000000
Binary files a/_static/python-cyclic-gc-2-new-page.png and /dev/null differ
diff --git a/_static/python-cyclic-gc-3-new-page.png b/_static/python-cyclic-gc-3-new-page.png
deleted file mode 100644
index 29fab0498e..0000000000
Binary files a/_static/python-cyclic-gc-3-new-page.png and /dev/null differ
diff --git a/_static/python-cyclic-gc-4-new-page.png b/_static/python-cyclic-gc-4-new-page.png
deleted file mode 100644
index 51a2b1065e..0000000000
Binary files a/_static/python-cyclic-gc-4-new-page.png and /dev/null differ
diff --git a/_static/python-cyclic-gc-5-new-page.png b/_static/python-cyclic-gc-5-new-page.png
deleted file mode 100644
index fe67a6896f..0000000000
Binary files a/_static/python-cyclic-gc-5-new-page.png and /dev/null differ
diff --git a/_templates/page.html b/_templates/page.html
new file mode 100644
index 0000000000..d1c9a515a4
--- /dev/null
+++ b/_templates/page.html
@@ -0,0 +1,8 @@
+{% extends "!page.html" %}
+
+{% block extrahead %}
+{{ super() }}
+{% if not is_deployment_preview %}
+
+{% endif %}
+{% endblock %}
diff --git a/_tools/generate_release_cycle.py b/_tools/generate_release_cycle.py
index 3a8fefec02..24dfa03e74 100644
--- a/_tools/generate_release_cycle.py
+++ b/_tools/generate_release_cycle.py
@@ -3,9 +3,13 @@
from __future__ import annotations
import argparse
+import calendar
import csv
import datetime as dt
import json
+from functools import cache
+from pathlib import Path
+from urllib.request import urlopen
import jinja2
@@ -18,31 +22,83 @@ def csv_date(date_str: str, now_str: str) -> str:
return date_str
-def parse_date(date_str: str) -> dt.date:
+def parse_date(date_str: str, *, last: bool = False) -> dt.date:
if len(date_str) == len("yyyy-mm"):
# We need a full yyyy-mm-dd, so let's approximate
- return dt.date.fromisoformat(date_str + "-01")
+ if last:
+ # Last day of month
+ year, month = map(int, date_str.split("-"))
+ last_day = calendar.monthrange(year, month)[1]
+ return dt.date(year, month, last_day)
+ else:
+ return dt.date.fromisoformat(date_str + "-01")
+
return dt.date.fromisoformat(date_str)
+def parse_version(ver: str) -> list[int]:
+ return [int(i) for i in ver["key"].split(".")]
+
+
+@cache
+def get_versions() -> dict[str, dict[str, str | int]]:
+ with urlopen("https://peps.python.org/api/release-cycle.json") as in_file:
+ return json.loads(in_file.read().decode("utf-8"))
+
+
class Versions:
"""For converting JSON to CSV and SVG."""
- def __init__(self) -> None:
- with open("include/release-cycle.json", encoding="UTF-8") as in_file:
- self.versions = json.load(in_file)
+ def __init__(self, *, limit_to_active=False, special_py27=False) -> None:
+ self.versions = get_versions()
# Generate a few additional fields
for key, version in self.versions.items():
version["key"] = key
- version["first_release_date"] = parse_date(version["first_release"])
- version["end_of_life_date"] = parse_date(version["end_of_life"])
+ ver_info = parse_version(version)
+ if ver_info >= [3, 13]:
+ full_years = 2
+ else:
+ full_years = 1.5
+ version["first_release_date"] = r1 = parse_date(version["first_release"])
+ version["start_security_date"] = r1 + dt.timedelta(days=full_years * 365)
+ version["end_of_life_date"] = parse_date(version["end_of_life"], last=True)
+
+ self.cutoff = min(ver["first_release_date"] for ver in self.versions.values())
+
+ if limit_to_active:
+ self.cutoff = min(
+ version["first_release_date"]
+ for version in self.versions.values()
+ if version["status"] != "end-of-life"
+ )
+ self.versions = {
+ key: version
+ for key, version in self.versions.items()
+ if version["end_of_life_date"] >= self.cutoff
+ or (special_py27 and key == "2.7")
+ }
+ if special_py27:
+ self.cutoff = min(self.cutoff, dt.date(2019, 8, 1))
+ self.id_key = "active"
+ else:
+ self.id_key = "all"
+
self.sorted_versions = sorted(
self.versions.values(),
- key=lambda v: [int(i) for i in v["key"].split(".")],
+ key=parse_version,
reverse=True,
)
+ # Set the row (Y coordinate) for the chart, to allow a gap between 2.7
+ # and the rest
+ y = len(self.sorted_versions) + (1 if special_py27 else 0)
+ for version in self.sorted_versions:
+ if special_py27 and version["key"] == "2.7":
+ y -= 1
+ version["y"] = y
+ y -= 1
+
def write_csv(self) -> None:
"""Output CSV files."""
now_str = str(dt.datetime.now(dt.timezone.utc))
@@ -68,7 +124,7 @@ def write_csv(self) -> None:
csv_file.writeheader()
csv_file.writerows(versions.values())
- def write_svg(self, today: str) -> None:
+ def write_svg(self, today: str, out_path: str) -> None:
"""Output SVG file."""
env = jinja2.Environment(
loader=jinja2.FileSystemLoader("_tools/"),
@@ -85,6 +141,8 @@ def write_svg(self, today: str) -> None:
# CSS.
# (Ideally we'd actually use `em` units, but SVG viewBox doesn't take
# those.)
+
+ # Uppercase sizes are un-scaled
SCALE = 18
# Width of the drawing and main parts
@@ -96,7 +154,7 @@ def write_svg(self, today: str) -> None:
# some positioning numbers in the template as well.
LINE_HEIGHT = 1.5
- first_date = min(ver["first_release_date"] for ver in self.sorted_versions)
+ first_date = self.cutoff
last_date = max(ver["end_of_life_date"] for ver in self.sorted_versions)
def date_to_x(date: dt.date) -> float:
@@ -105,7 +163,7 @@ def date_to_x(date: dt.date) -> float:
total_days = (last_date - first_date).days
ratio = num_days / total_days
x = ratio * (DIAGRAM_WIDTH - LEGEND_WIDTH - RIGHT_MARGIN)
- return x + LEGEND_WIDTH
+ return (x + LEGEND_WIDTH) * SCALE
def year_to_x(year: int) -> float:
"""Convert year number to an SVG X coordinate of 1st January"""
@@ -115,20 +173,21 @@ def format_year(year: int) -> str:
"""Format year number for display"""
return f"'{year % 100:02}"
- with open(
- "include/release-cycle.svg", "w", encoding="UTF-8", newline="\n"
- ) as f:
+ with open(out_path, "w", encoding="UTF-8", newline="\n") as f:
template.stream(
SCALE=SCALE,
- diagram_width=DIAGRAM_WIDTH,
- diagram_height=(len(self.sorted_versions) + 2) * LINE_HEIGHT,
+ diagram_width=DIAGRAM_WIDTH * SCALE,
+ diagram_height=(self.sorted_versions[0]["y"] + 2) * LINE_HEIGHT * SCALE,
years=range(first_date.year, last_date.year + 1),
- LINE_HEIGHT=LINE_HEIGHT,
+ line_height=LINE_HEIGHT * SCALE,
+ legend_width=LEGEND_WIDTH * SCALE,
+ right_margin=RIGHT_MARGIN * SCALE,
versions=list(reversed(self.sorted_versions)),
today=dt.datetime.strptime(today, "%Y-%m-%d").date(),
year_to_x=year_to_x,
date_to_x=date_to_x,
format_year=format_year,
+ id_key=self.id_key,
).dump(f)
@@ -145,8 +204,14 @@ def main() -> None:
args = parser.parse_args()
versions = Versions()
+ assert len(versions.versions) > 10
+ Path("include").mkdir(exist_ok=True)
+
versions.write_csv()
- versions.write_svg(args.today)
+ versions.write_svg(args.today, "_static/release-cycle-all.svg")
+
+ versions = Versions(limit_to_active=True, special_py27=True)
+ versions.write_svg(args.today, "_static/release-cycle.svg")
if __name__ == "__main__":
diff --git a/_tools/release_cycle_template.svg.jinja b/_tools/release_cycle_template.svg.jinja
index 5d39d307a5..ffc54919e7 100644
--- a/_tools/release_cycle_template.svg.jinja
+++ b/_tools/release_cycle_template.svg.jinja
@@ -2,29 +2,146 @@
diff --git a/conf.py b/conf.py
index 0319de4ddf..1d88937227 100644
--- a/conf.py
+++ b/conf.py
@@ -1,4 +1,9 @@
+import json
+import os
+from urllib.request import urlopen
+
extensions = [
+ 'linklint.ext',
'notfound.extension',
'sphinx.ext.extlinks',
'sphinx.ext.intersphinx',
@@ -34,6 +39,7 @@
"source_repository": "https://github.com/python/devguide",
"source_branch": "main",
}
+templates_path = ['_templates']
html_static_path = ['_static']
html_css_files = [
'devguide_overrides.css',
@@ -47,6 +53,14 @@
# Set to '' to prevent appending "documentation" to the site title
html_title = ""
+# Deployment preview information
+# (See .readthedocs.yaml and https://docs.readthedocs.io/en/stable/reference/environment-variables.html)
+is_deployment_preview = os.getenv("READTHEDOCS_VERSION_TYPE") == "external"
+
+html_context = {
+ "is_deployment_preview": is_deployment_preview,
+}
+
linkcheck_allowed_redirects = {
# Edit page
r"https://docs.google.com/document/d/.*/": r"https://docs.google.com/document/d/.*/edit", # noqa: E501
@@ -84,18 +98,10 @@
r'\/.*',
]
-# Check the link itself, but ignore anchors that are added by JS
-# https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-linkcheck_anchors_ignore_for_url
-linkcheck_anchors_ignore_for_url = [
- # GitHub
- r'https://github.com/.*',
-]
-
linkcheck_ignore = [
- # The voters repo is private and appears as a 404
- 'https://github.com/python/voters',
- # The python-core team link is private, redirects to login
- 'https://github.com/orgs/python/teams/python-core',
+ # Checks fail due to rate limits
+ r'https://github.com/.*',
+ r'https://www.gnu.org/software/autoconf/',
# The Discourse groups are private unless you are logged in
'https://discuss.python.org/groups/staff',
'https://discuss.python.org/groups/moderators',
@@ -117,12 +123,21 @@
# Advanced Tools was renamed Development Tools in gh-1149
"advanced-tools/clang.rst": "development-tools/clang.rst",
"advanced-tools/gdb.rst": "development-tools/gdb.rst",
- # Core Developers
- "coredev.rst": "core-developers/become-core-developer.rst",
- "committing.rst": "core-developers/committing.rst",
- "developers.rst": "core-developers/developer-log.rst",
- "experts.rst": "core-developers/experts.rst",
- "motivations.rst": "core-developers/motivations.rst",
+ # Core team
+ "coredev.rst": "core-team/join-team.rst",
+ "committing.rst": "core-team/committing.rst",
+ "developers.rst": "core-team/team-log.rst",
+ "experts.rst": "core-team/experts.rst",
+ "motivations.rst": "core-team/motivations.rst",
+ # core-developers/ -> core-team/
+ "core-developers/become-core-developer.rst": "core-team/join-team.rst",
+ "core-developers/committing.rst": "core-team/committing.rst",
+ "core-developers/developer-log.rst": "core-team/team-log.rst",
+ "core-developers/experts.rst": "core-team/experts.rst",
+ "core-developers/index.rst": "core-team/index.rst",
+ "core-developers/memorialization.rst": "core-team/memorialization.rst",
+ "core-developers/motivations.rst": "core-team/motivations.rst",
+ "core-developers/responsibilities.rst": "core-team/responsibilities.rst",
# Developer Workflow
"c-api.rst": "developer-workflow/c-api.rst",
"communication.rst": "developer-workflow/communication-channels.rst",
@@ -135,6 +150,10 @@
# Documentation
"docquality.rst": "documentation/help-documenting.rst",
"documenting.rst": "documentation/start-documenting.rst",
+ # Translating
+ "documentation/translating.rst": "documentation/translations/translating.rst",
+ "translating.rst": "documentation/translations/translating.rst",
+ "coordinating.rst": "documentation/translations/coordinating.rst",
# Getting Started
"fixingissues.rst": "getting-started/fixing-issues.rst",
"help.rst": "getting-started/getting-help.rst",
@@ -142,10 +161,14 @@
"pullrequest.rst": "getting-started/pull-request-lifecycle.rst",
"setup.rst": "getting-started/setup-building.rst",
# CPython Internals
- "compiler.rst": "internals/compiler.rst",
- "exploring.rst": "internals/exploring.rst",
- "garbage_collector.rst": "internals/garbage-collector.rst",
- "parser.rst": "internals/parser.rst",
+ "compiler.rst": "internals.rst",
+ "exploring.rst": "internals.rst",
+ "garbage_collector.rst": "internals.rst",
+ "parser.rst": "internals.rst",
+ "internals/compiler.rst": "internals.rst",
+ "internals/exploring.rst": "internals.rst",
+ "internals/garbage_collector.rst": "internals.rst",
+ "internals/parser.rst": "internals.rst",
# Testing and Buildbots
"buildbots.rst": "testing/buildbots.rst",
"coverage.rst": "testing/coverage.rst",
@@ -157,6 +180,56 @@
"tracker.rst": "triage/issue-tracker.rst",
"gh-labels.rst": "triage/labels.rst",
"triaging.rst": "triage/triaging.rst",
+ # Contributing guide draft pages
+ "contrib/code/git.rst": "getting-started/git-boot-camp.rst",
+ "contrib/code/pull-request-lifecycle.rst": "getting-started/pull-request-lifecycle.rst",
+ "contrib/code/setup.rst": "getting-started/setup-building.rst",
+ "contrib/code/testing.rst": "testing/index.rst",
+ "contrib/code/developer-workflow.rst": "developer-workflow/index.rst",
+ "contrib/code/index.rst": "index.rst",
+ "contrib/code/development-tools.rst": "development-tools/index.rst",
+ "contrib/doc/devguide.rst": "documentation/devguide.rst",
+ "contrib/doc/help-documenting.rst": "documentation/help-documenting.rst",
+ "contrib/doc/markup.rst": "documentation/markup.rst",
+ "contrib/doc/pull-request-lifecycle.rst": "getting-started/pull-request-lifecycle.rst",
+ "contrib/doc/start-documenting.rst": "documentation/start-documenting.rst",
+ "contrib/doc/style-guide.rst": "documentation/style-guide.rst",
+ "contrib/doc/translating.rst": "documentation/translations/index.rst",
+ "contrib/doc/index.rst": "documentation/index.rst",
+ "contrib/intro/index.rst": "index.rst",
+ "contrib/project/channels.rst": "developer-workflow/communication-channels.rst",
+ "contrib/project/conduct.rst": "index.rst",
+ "contrib/project/github.rst": "index.rst",
+ "contrib/project/governance.rst": "index.rst",
+ "contrib/project/roles.rst": "index.rst",
+ "contrib/project/generative-ai.rst": "getting-started/generative-ai.rst",
+ "contrib/project/outreach.rst": "index.rst",
+ "contrib/project/directory-structure.rst": "getting-started/setup-building.rst",
+ "contrib/project/index.rst": "index.rst",
+ "contrib/security.rst": "index.rst",
+ "contrib/triage/issue-tracker.rst": "triage/issue-tracker.rst",
+ "contrib/triage/labels.rst": "triage/labels.rst",
+ "contrib/triage/reviewing.rst": "triage/triaging.rst",
+ "contrib/triage/triage-team.rst": "triage/triage-team.rst",
+ "contrib/triage/triaging.rst": "triage/triaging.rst",
+ "contrib/triage/index.rst": "triage/index.rst",
+ "contrib/user-success.rst": "index.rst",
+ "contrib/core-team/committing.rst": "core-team/committing.rst",
+ "contrib/core-team/experts.rst": "core-team/experts.rst",
+ "contrib/core-team/index.rst": "core-team/index.rst",
+ "contrib/core-team/join-team.rst": "core-team/join-team.rst",
+ "contrib/core-team/motivations.rst": "core-team/motivations.rst",
+ "contrib/core-team/responsibilities.rst": "core-team/responsibilities.rst",
+ "contrib/core-team/team-log.rst": "core-team/team-log.rst",
+ "contrib/workflows/codespaces.rst": "getting-started/setup-building.rst",
+ "contrib/workflows/compile.rst": "getting-started/setup-building.rst",
+ "contrib/workflows/get-source.rst": "getting-started/setup-building.rst",
+ "contrib/workflows/index.rst": "getting-started/setup-building.rst",
+ "contrib/workflows/install-dependencies.rst": "getting-started/setup-building.rst",
+ "contrib/workflows/install-git.rst": "getting-started/setup-building.rst",
+ "contrib/workflows/regenerate.rst": "getting-started/setup-building.rst",
+ "contrib/workflows/troubleshooting.rst": "getting-started/setup-building.rst",
+ "contrib/index.rst": "index.rst",
}
intersphinx_mapping = {
@@ -169,23 +242,19 @@
# sphinx-notfound-page
notfound_urls_prefix = "/"
+# Dynamically expose the Python version associated with the "main" branch.
+# Exactly one entry in ``release-cycle.json`` should have ``"branch": "main"``.
+with urlopen("https://peps.python.org/api/release-cycle.json") as _f:
+ _cycle = json.loads(_f.read().decode("utf-8"))
+
+_main_version = next(
+ version for version, data in _cycle.items() if data.get("branch") == "main"
+)
+
# prolog and epilogs
-rst_prolog = """
-.. |draft| replace::
- This is part of a **Draft** of the Python Contributor's Guide.
- Text in square brackets are notes about content to fill in.
- Currently, the devguide and this new Contributor's Guide co-exist in the
- repo. We are using Sphinx include directives to demonstrate the re-organization.
- The final Contributor's Guide will replace the devguide with content in only one
- place.
- We welcome help with this!
-
-.. |purpose| replace::
- The :ref:`contrib-plan` page has more details about the current state of this draft
- and **how you can help**. See more info about the Contributor Guide in the
- discussion forum: `Refactoring the DevGuide`_.
-
-.. _Refactoring the DevGuide: https://discuss.python.org/t/refactoring-the-devguide-into-a-contribution-guide/63409
+rst_prolog = f"""
+
+.. |main_version| replace:: {_main_version}
"""
@@ -207,11 +276,11 @@
ogp_site_url = "https://devguide.python.org/"
ogp_site_name = "Python Developer's Guide"
ogp_image = "_static/og-image-200x200.png"
-ogp_custom_meta_tags = [
+ogp_custom_meta_tags = (
'',
'',
'',
-]
+)
# Strip the dollar prompt when copying code
# https://sphinx-copybutton.readthedocs.io/en/latest/use.html#strip-and-configure-input-prompts-for-code-cells
diff --git a/contrib/code/developer-workflow.rst b/contrib/code/developer-workflow.rst
deleted file mode 100644
index 416ca2c022..0000000000
--- a/contrib/code/developer-workflow.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-====================
-Development workflow
-====================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-[This is the existing :ref:`dev-workflow` page from the devguide]
-
-.. toctree::
- :maxdepth: 5
-
- ../../developer-workflow/communication-channels
- ../../developer-workflow/development-cycle
- ../../developer-workflow/stdlib
- ../../developer-workflow/extension-modules
- ../../developer-workflow/c-api
- ../../developer-workflow/lang-changes
- ../../developer-workflow/grammar
- ../../developer-workflow/porting
- ../../developer-workflow/sbom
- ../../developer-workflow/psrt
diff --git a/contrib/code/development-tools.rst b/contrib/code/development-tools.rst
deleted file mode 100644
index 348ceb95ac..0000000000
--- a/contrib/code/development-tools.rst
+++ /dev/null
@@ -1,19 +0,0 @@
-=================
-Development tools
-=================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-[This is the existing :ref:`development-tools` page from the devguide.]
-
-.. toctree::
- :maxdepth: 5
-
- ../../development-tools/clinic
- ../../development-tools/gdb
- ../../development-tools/clang
- ../../development-tools/warnings
diff --git a/contrib/code/git.rst b/contrib/code/git.rst
deleted file mode 100644
index 7c7aaa57b1..0000000000
--- a/contrib/code/git.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-========
-Git tips
-========
-
-.. important::
-
- |draft|
-
- |purpose|
-
-[More git help for advanced things needed by code contributors.]
diff --git a/contrib/code/index.rst b/contrib/code/index.rst
deleted file mode 100644
index 7680950663..0000000000
--- a/contrib/code/index.rst
+++ /dev/null
@@ -1,30 +0,0 @@
-.. _c_code:
-
-==================
-Code contributions
-==================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-[The main page for code contributors.]
-
-[We'll include code-focused content from the :ref:`main devguide page `: Quick
-reference, Quick links, Proposing changes, and so on.]
-
-[The existing :ref:`internals` section of the devguide will be fully
-migrated into the Python repo.]
-
-
-.. toctree::
- :maxdepth: 5
-
- setup
- git
- pull-request-lifecycle
- developer-workflow
- testing
- development-tools
diff --git a/contrib/code/pull-request-lifecycle.rst b/contrib/code/pull-request-lifecycle.rst
deleted file mode 100644
index 30c0fd5903..0000000000
--- a/contrib/code/pull-request-lifecycle.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-.. _code-pull-request-lifecycle:
-
-======================
-Pull request lifecycle
-======================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[Details of pull requests for code contributions. The existing
-:ref:`pull-request-lifecycle` page is long and includes many details.
-Some only apply to code contributions, but many are common to all
-contributions. Should we keep a common page, with extra steps here, or
-should this page have all of the details even if they are duplicated
-elsewhere?]
-
-[See :ref:`docs-pull-request-lifecycle` for the documentation half of this conundrum.]
diff --git a/contrib/code/setup.rst b/contrib/code/setup.rst
deleted file mode 100644
index 2d14bb0d91..0000000000
--- a/contrib/code/setup.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-==================
-Setup and building
-==================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-[More setup and build instructions specifically for code contributors, building
-on the basics from the :ref:`Getting Started ` section.]
diff --git a/contrib/code/testing.rst b/contrib/code/testing.rst
deleted file mode 100644
index 575d1477a4..0000000000
--- a/contrib/code/testing.rst
+++ /dev/null
@@ -1,20 +0,0 @@
-=====================
-Testing and buildbots
-=====================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-[This is the existing :ref:`testing` page from the devguide.]
-
-.. toctree::
- :maxdepth: 5
-
- ../../testing/run-write-tests
- ../../testing/silence-warnings
- ../../testing/coverage
- ../../testing/buildbots
- ../../testing/new-buildbot-worker
diff --git a/contrib/contrib-plan.rst b/contrib/contrib-plan.rst
deleted file mode 100644
index 36a171bf14..0000000000
--- a/contrib/contrib-plan.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-.. _contrib-plan:
-
-==================================
-[Plan for the Contributor's Guide]
-==================================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-We are in the process of updating and refactoring the devguide to be a
-Contributor's Guide. It will highlight the different kinds of contribution
-possible, and how to succeed at each kind.
-
-Currently, the Contibutor's Guide is a draft in this new last section of the
-devguide. We welcome feedback, but please understand that some of the current
-content is moving or skeletal.
-
-Repo structure
-==============
-
-While the reorganization is happening, we are keeping the old devguide as it
-is. The new Contributor's Guide is represented in this last section, but will
-eventually be the only content in the guide. To avoid copying content, we're
-using Sphinx include directives to display existing devguide content in its new
-Contributor's Guide location. That is not how the eventual Guide will be
-built. Once we are ready to make the Contributor's Guide real, we will
-rearrange content into its new location.
-
-How to help
-===========
-
-To help, you can:
-
-- `Write an issue`_ detailing a change you'd like to see here.
-- `Make a pull request`_ in this repo to add content.
-- Join us in the `Python Docs Discord`_ to collaborate with other docs-minded
- community members.
-- Get in touch with the `Docs Editorial Board`_ to discuss larger documentation
- concerns.
-
-.. _Write an issue: https://github.com/python/devguide/issues
-.. _Make a pull request: https://github.com/python/devguide/pulls
-.. _Python Docs Discord: https://discord.gg/NeGgyhUZ
-.. _Docs Editorial Board: https://python.github.io/editorial-board/
diff --git a/contrib/core-team/committing.rst b/contrib/core-team/committing.rst
deleted file mode 100644
index 59cf7c1af2..0000000000
--- a/contrib/core-team/committing.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing core developers :ref:`committing` page from the devguide. We'll
-adjust "core developer" to "core team" where appropriate.]
-
-.. include:: ../../core-developers/committing.rst
diff --git a/contrib/core-team/developer-log.rst b/contrib/core-team/developer-log.rst
deleted file mode 100644
index 473cd3c6c6..0000000000
--- a/contrib/core-team/developer-log.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing core developers :ref:`developer-log` page from the devguide. We'll
-adjust "core developer" to "core team" where appropriate.]
-
-.. include:: ../../core-developers/developer-log.rst
diff --git a/contrib/core-team/experts.rst b/contrib/core-team/experts.rst
deleted file mode 100644
index 7f2a103cd5..0000000000
--- a/contrib/core-team/experts.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing core developers :ref:`experts` page from the devguide. We'll
-adjust "core developer" to "core team" where appropriate.]
-
-.. include:: ../../core-developers/experts.rst
diff --git a/contrib/core-team/index.rst b/contrib/core-team/index.rst
deleted file mode 100644
index 281ed0f479..0000000000
--- a/contrib/core-team/index.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-=========
-Core team
-=========
-
-[This is mostly re-organized from the :ref:`core-dev` section of the devguide,
-but with "core developer" language changed to "core team" where possible.]
-
-.. toctree::
- :maxdepth: 5
-
- responsibilities
- committing
- experts
- developer-log
- motivations
- join-team
diff --git a/contrib/core-team/join-team.rst b/contrib/core-team/join-team.rst
deleted file mode 100644
index 0c893ae08d..0000000000
--- a/contrib/core-team/join-team.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing core developers :ref:`become-core-developer` page from the devguide with the title changed. We'll
-adjust "core developer" to "core team" where appropriate.]
-
-=========================
-How to join the core team
-=========================
-
-.. include:: ../../core-developers/become-core-developer.rst
- :start-line: 7
diff --git a/contrib/core-team/motivations.rst b/contrib/core-team/motivations.rst
deleted file mode 100644
index c9e0281b6f..0000000000
--- a/contrib/core-team/motivations.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing core developers :ref:`motivations` page from the devguide. We'll
-adjust "core developer" to "core team" where appropriate.]
-
-.. include:: ../../core-developers/motivations.rst
diff --git a/contrib/core-team/responsibilities.rst b/contrib/core-team/responsibilities.rst
deleted file mode 100644
index a3de329561..0000000000
--- a/contrib/core-team/responsibilities.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing core developers :ref:`responsibilities` page from the devguide. We'll
-adjust "core developer" to "core team" where appropriate.]
-
-.. include:: ../../core-developers/responsibilities.rst
diff --git a/contrib/doc/devguide.rst b/contrib/doc/devguide.rst
deleted file mode 100644
index 2c83e52003..0000000000
--- a/contrib/doc/devguide.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-==================================
-Helping with the Developer's Guide
-==================================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing :ref:`devguide` page from the devguide.]
diff --git a/contrib/doc/help-documenting.rst b/contrib/doc/help-documenting.rst
deleted file mode 100644
index befb4b2461..0000000000
--- a/contrib/doc/help-documenting.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-==========================
-Helping with documentation
-==========================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing :ref:`help-documenting` page from the devguide.]
diff --git a/contrib/doc/index.rst b/contrib/doc/index.rst
deleted file mode 100644
index dc8ec93074..0000000000
--- a/contrib/doc/index.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-.. _c_docs:
-
-===========================
-Documentation contributions
-===========================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[The main page for documentation contributors.]
-
-[We'll include docs-focused content from the :ref:`main devguide page `: Quick
-reference, Quick links, and so on.]
-
-
-.. toctree::
- :maxdepth: 5
-
- start-documenting
- help-documenting
- style-guide
- markup
- pull-request-lifecycle
- translating
- devguide
diff --git a/contrib/doc/markup.rst b/contrib/doc/markup.rst
deleted file mode 100644
index 96b9faad5e..0000000000
--- a/contrib/doc/markup.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-=======================
-reStructuredText markup
-=======================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing :ref:`markup` page from the devguide.]
diff --git a/contrib/doc/pull-request-lifecycle.rst b/contrib/doc/pull-request-lifecycle.rst
deleted file mode 100644
index a62e637283..0000000000
--- a/contrib/doc/pull-request-lifecycle.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-.. _docs-pull-request-lifecycle:
-
-======================
-Pull request lifecycle
-======================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[Details of pull requests for documentation contributions. The existing
-:ref:`pull-request-lifecycle` page is long and includes many details.
-Some only apply to code contributions, but many are common to all
-contributions. Should we keep a common page, with documentation tweaks here, or
-should this page have only the documentation details even if they are duplicated
-elsewhere?]
-
-[See :ref:`code-pull-request-lifecycle` for the code half of this conundrum.]
diff --git a/contrib/doc/start-documenting.rst b/contrib/doc/start-documenting.rst
deleted file mode 100644
index c5cf96161b..0000000000
--- a/contrib/doc/start-documenting.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-===============
-Getting started
-===============
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing documentation :ref:`start-documenting` page from the devguide.]
diff --git a/contrib/doc/style-guide.rst b/contrib/doc/style-guide.rst
deleted file mode 100644
index 87762f3e03..0000000000
--- a/contrib/doc/style-guide.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-===========
-Style guide
-===========
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing documentation :ref:`style-guide` page from the devguide.]
diff --git a/contrib/doc/translating.rst b/contrib/doc/translating.rst
deleted file mode 100644
index baface2f0d..0000000000
--- a/contrib/doc/translating.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-===========
-Translating
-===========
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing :ref:`translating` page from the devguide.]
diff --git a/contrib/get-started/index.rst b/contrib/get-started/index.rst
deleted file mode 100644
index 70e61b1b1b..0000000000
--- a/contrib/get-started/index.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-.. _c_gettingstarted:
-
-===============
-Getting started
-===============
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-* Basic setup
-* Git bootcamp (simplified for everyone to use)
diff --git a/contrib/index.rst b/contrib/index.rst
deleted file mode 100644
index b3ef0d992a..0000000000
--- a/contrib/index.rst
+++ /dev/null
@@ -1,116 +0,0 @@
-.. _c_root:
-
-==================================
-Python Contributor's Guide (draft)
-==================================
-
-.. raw:: html
-
-
-
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[Open question: how to divide content between this Introduction and the
-:ref:`introduction `?]
-
-This guide is a comprehensive resource for :ref:`contributing `
-to Python_ -- for both new and experienced contributors. It is :ref:`maintained
-` by the same community that maintains Python. We welcome your
-contributions to Python!
-
-We encourage everyone to contribute to Python. This guide should have
-everything you need to get started and be productive. If you still have
-questions after reviewing the material in this guide, the `Core Python
-Mentorship`_ group is available to help you through the process.
-
-There are a number of ways to contribute including code, documentation, and
-triaging issues. We've organized this guide to provide specifics based on the
-type of activity you'll be engaged in.
-
-
-Using this guide
-================
-
-We recommend reading this guide as needed. You can stop where you feel
-comfortable and begin contributing immediately without reading and
-understanding everything. If you do choose to skip around this guide, be aware
-that it is written assuming preceding sections have been read so you may need
-to backtrack to fill in missing concepts and terminology.
-
-No matter what kind of contribution you'll be making, you should start with
-these common sections:
-
-* :ref:`c_intro`
-* :ref:`c_project`
-* :ref:`c_gettingstarted`
-
-Then choose a path based on your type of activity:
-
-*[The original table on the devguide home had a fourth column for Core
-Developers. That made the table wider and more confusing. I don't think core
-team members need a quick intro path since they will have been through the
-devguide before.]*
-
-*[I haven't adjusted the links in the table yet other than to add a link to the
-major section at the top of each column.]*
-
-.. list-table::
- :widths: 10 10 10
- :header-rows: 1
-
- * - :ref:`Triaging `
- - :ref:`Documentation `
- - :ref:`Code `
- * -
- * :ref:`tracker`
- * :ref:`triaging`
- * :ref:`helptriage`
- * :ref:`experts`
- * :ref:`labels`
- * :ref:`gh-faq`
- * :ref:`triage-team`
- -
- * :ref:`docquality`
- * :ref:`documenting`
- * :ref:`style-guide`
- * :ref:`rst-primer`
- * :ref:`translating`
- * :ref:`devguide`
- -
- * :ref:`setup`
- * :ref:`help`
- * :ref:`pullrequest`
- * :ref:`runtests`
- * :ref:`fixingissues`
- * :ref:`communication`
- * :ref:`gitbootcamp`
- * :ref:`devcycle`
-
-
-.. toctree::
- :maxdepth: 3
-
- contrib-plan
- intro/index
- project/index
- get-started/index
- triage/index
- code/index
- doc/index
- core-team/index
- user-success
- security
-
-
-.. _Python: https://www.python.org/
-.. _Core Python Mentorship: https://www.python.org/dev/core-mentorship/
diff --git a/contrib/intro/index.rst b/contrib/intro/index.rst
deleted file mode 100644
index c5ba303dfd..0000000000
--- a/contrib/intro/index.rst
+++ /dev/null
@@ -1,53 +0,0 @@
-.. _c_intro:
-
-============
-Introduction
-============
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-
-[Open question: how to divide content between this Introduction and the
-:ref:`home page `?]
-
-Welcome!
-
-New to open source?
-===================
-
-Python is an open source project, with culture and techniques from the broader
-open source world. You might find it helpful to read about open source in
-general. A number of individuals from the Python community have contributed to
-a series of excellent guides at `Open Source Guides
-`_.
-
-Anyone will find the following guides useful:
-
-* `How to Contribute to Open Source `_
-* `Building Welcoming Communities `_
-
-
-Healthy collaboration
-=====================
-
-[Importance of healthy inclusive collaboration]
-
-[While code is a large part of the project's success, project management, documentation, governance, sprint outreach, etc. matter.]
-
-[We respect the individual skills people bring to the project and strive to create and maintain a culture of inclusion.]
-
-About this guide
-================
-
-Types of contribution
-=====================
-
-[Pathways for contributors]
-
-Helping with this guide
-=======================
diff --git a/contrib/project/channels.rst b/contrib/project/channels.rst
deleted file mode 100644
index 711dbe5879..0000000000
--- a/contrib/project/channels.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-======================
-Communication channels
-======================
-
-* Repos
-* Discourse
-* Discord
-* Mailing lists (deprioritize)
-* Where to get help
diff --git a/contrib/project/conduct.rst b/contrib/project/conduct.rst
deleted file mode 100644
index 37fe3bbfa7..0000000000
--- a/contrib/project/conduct.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-===============
-Code of Conduct
-===============
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[Brief summary of the code of conduct, with links to official source.]
-
-* Standard for communication
-* How to report
-* Enforcement details
diff --git a/contrib/project/generative-ai.rst b/contrib/project/generative-ai.rst
deleted file mode 100644
index 6cb5b62ffc..0000000000
--- a/contrib/project/generative-ai.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[This is the existing :ref:`generative-ai` page from the devguide.]
-
-.. include:: ../../getting-started/generative-ai.rst
diff --git a/contrib/project/github.rst b/contrib/project/github.rst
deleted file mode 100644
index fe45c6b8b1..0000000000
--- a/contrib/project/github.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-======
-GitHub
-======
-
-[Where are the actual artifacts?]
-
-* Main CPython repos
-* Core workflow repos
-* Infrastructure repos
diff --git a/contrib/project/governance.rst b/contrib/project/governance.rst
deleted file mode 100644
index a4bc66ff1b..0000000000
--- a/contrib/project/governance.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-==========
-Governance
-==========
-
-[How decisions are made, who is involved, how to participate.]
-
-Steering Council
-================
-
-Documentation Editorial Board
-=============================
-
-Typing Council
-==============
-
-
-Others?
-=======
diff --git a/contrib/project/index.rst b/contrib/project/index.rst
deleted file mode 100644
index 5d26b15aab..0000000000
--- a/contrib/project/index.rst
+++ /dev/null
@@ -1,28 +0,0 @@
-.. _c_project:
-
-===================
-The CPython project
-===================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[Give the reader an understanding of the project as a whole. What are the
-moving parts, who is involved, how do they interact?]
-
-* Structure
-
-.. toctree::
- :maxdepth: 5
-
- conduct
- roles
- governance
- generative-ai.rst
- github
- channels
- outreach
diff --git a/contrib/project/outreach.rst b/contrib/project/outreach.rst
deleted file mode 100644
index d43aa8e9de..0000000000
--- a/contrib/project/outreach.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-========
-Outreach
-========
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-* Sprints
diff --git a/contrib/project/roles.rst b/contrib/project/roles.rst
deleted file mode 100644
index 8336fe4651..0000000000
--- a/contrib/project/roles.rst
+++ /dev/null
@@ -1,17 +0,0 @@
-=====
-Roles
-=====
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-[Quick overview of the roles people play. Core team has its own section.]
-
-* Core team
-* Triager
-* Contributors
- * types of contributions
diff --git a/contrib/security.rst b/contrib/security.rst
deleted file mode 100644
index db40b4a167..0000000000
--- a/contrib/security.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-=========================================
-Security and infrastructure contributions
-=========================================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-* Security
-* Infrastructure
-* Core workflow
diff --git a/contrib/triage/index.rst b/contrib/triage/index.rst
deleted file mode 100644
index 0a547d9d77..0000000000
--- a/contrib/triage/index.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-.. _c_triage:
-
-===================
-Issues and triaging
-===================
-
-.. toctree::
- :maxdepth: 5
-
- issue-tracker
- triaging
- labels
- reviewing
- triage-team
diff --git a/contrib/triage/issue-tracker.rst b/contrib/triage/issue-tracker.rst
deleted file mode 100644
index a5777bc81d..0000000000
--- a/contrib/triage/issue-tracker.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-[This is the existing :ref:`issue-tracker` page from the devguide]
-
-.. include:: ../../triage/issue-tracker.rst
diff --git a/contrib/triage/labels.rst b/contrib/triage/labels.rst
deleted file mode 100644
index c364817333..0000000000
--- a/contrib/triage/labels.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-[This is the existing :ref:`labels` page from the devguide]
-
-.. include:: ../../triage/labels.rst
diff --git a/contrib/triage/reviewing.rst b/contrib/triage/reviewing.rst
deleted file mode 100644
index 060f6b78dd..0000000000
--- a/contrib/triage/reviewing.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-
-=========
-Reviewing
-=========
-
-* How? Etiquette?
-* How to request a review?
diff --git a/contrib/triage/triage-team.rst b/contrib/triage/triage-team.rst
deleted file mode 100644
index a9b59056a9..0000000000
--- a/contrib/triage/triage-team.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-[This is the existing :ref:`triage-team` page from the devguide]
-
-.. include:: ../../triage/triage-team.rst
diff --git a/contrib/triage/triaging.rst b/contrib/triage/triaging.rst
deleted file mode 100644
index 22e1ccc657..0000000000
--- a/contrib/triage/triaging.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. important::
-
- |draft|
-
- |purpose|
-
-[This is the existing :ref:`triaging` page from the devguide]
-
-.. include:: ../../triage/triaging.rst
diff --git a/contrib/user-success.rst b/contrib/user-success.rst
deleted file mode 100644
index 2a9ef5d4e5..0000000000
--- a/contrib/user-success.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-=======================================
-Accessibility, design, and user success
-=======================================
-
-.. important::
-
- |draft|
-
- |purpose|
-
-
-* Accessibility
-* Design
-* User success
diff --git a/core-developers/committing.rst b/core-team/committing.rst
similarity index 59%
rename from core-developers/committing.rst
rename to core-team/committing.rst
index 326578c0b3..c606df3839 100644
--- a/core-developers/committing.rst
+++ b/core-team/committing.rst
@@ -5,7 +5,7 @@ Accepting pull requests
.. highlight:: none
-This page is a step-by-step guide for core developers who need to assess,
+This page is a step-by-step guide for the core team to assess,
merge, and possibly backport a pull request on the main repository.
Assessing a pull request
@@ -54,15 +54,16 @@ to enter the public source tree. Ask yourself the following questions:
developer can apply the label ``needs backport to X.Y`` to the pull
request. Once the backport pull request has been created, remove the
``needs backport to X.Y`` label from the original pull request. (Only
- core developers and members of the :ref:`Python Triage Team `
+ the core team and members of the :ref:`Python Triage Team `
can apply labels to GitHub pull requests).
* **Does the pull request pass a check indicating that the submitter has signed the CLA?**
Make sure that the contributor has signed a `Contributor
- Licensing Agreement `_
+ Licensing Agreement `__
(CLA), unless their change has no possible intellectual property
associated with it (for example, fixing a spelling mistake in documentation).
- The `CPython CLA Bot `_
+ The `Python Software Foundation Contributor License Agreement Management Bot
+ `__
checks whether the author has signed the CLA, and replies in the PR
if they haven't. For further questions about the CLA
process, write to contributors@python.org.
@@ -72,104 +73,10 @@ to enter the public source tree. Ask yourself the following questions:
significant improvements, or backwards-incompatible changes), then an
entry in the ``What's New in Python`` document (in ``Doc/whatsnew/``) should
be added as well. Changes that affect only documentation generally do not
- require a ``NEWS`` entry. (See the following section for more information.)
+ require a ``NEWS`` entry.
-.. _news-entry:
-.. _what-s-new-and-news-entries:
-
-Updating NEWS and What's New in Python
---------------------------------------
-
-Changes that require NEWS entries
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Most changes made to the codebase deserve an entry in :cpy-file:`Misc/NEWS.d`,
-except for the following:
-
-* documentation changes
-* test changes
-* strictly internal changes with no user-visible effects
-* changes that already have a ``NEWS`` entry
-* reverts that have not yet been included in any formal release
- (including alpha and beta releases)
-
-For the last two, note the following:
-
-#. **If a change is reverted prior to release**, then the corresponding
- entry is simply removed. Otherwise, a new entry must be added noting
- that the change has been reverted (for example, when a feature is released in
- an alpha and then cut prior to the first beta).
-
-#. **If a change is a fix (or other adjustment) to an earlier unreleased
- change and the original** ``NEWS`` **entry remains valid**, then no additional
- entry is needed.
-
-Changes that require "What's New in Python" entries
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If a change is particularly interesting for end users (for example, new features,
-significant improvements, or backwards-incompatible changes), add an entry in
-the "What's New in Python" document (in :cpy-file:`Doc/whatsnew/`)
-in addition to the ``NEWS`` entry.
-
-In most cases, it is sufficient to reuse the wording from the ``NEWS`` entry
-in the "What's New in Python" entry.
-
-.. note::
-
- A change that needs an entry in "What's New in Python",
- is very likely not suitable for inclusion in a maintenance release.
-
-How to add a NEWS entry
-^^^^^^^^^^^^^^^^^^^^^^^
-
-``NEWS`` entries go into the ``Misc/NEWS.d`` directory as individual files. The
-``NEWS`` entry can be created by using `blurb-it `_,
-or the :pypi:`blurb` tool and its ``blurb add`` command.
-
-If you are unable to use the tool, then you can create the ``NEWS`` entry file
-manually. The ``Misc/NEWS.d`` directory contains a sub-directory named
-``next``, which contains various sub-directories representing classifications
-for what was affected (for example, ``Misc/NEWS.d/next/Library`` for changes relating
-to the standard library). The file name itself should be in the format
-``.gh-issue-..rst``:
-
-* ```` is today's date joined with a hyphen (``-``) to your current
- local time, in the ``YYYY-MM-DD-hh-mm-ss`` format (for example, ``2017-05-27-16-46-23``).
-* ```` is the issue number the change is for (for example, ``12345``
- for ``gh-issue-12345``).
-* ```` is a unique string to guarantee that the file name is
- unique across branches (for example, ``Yl4gI2``). It is typically six characters
- long, but it can be any length of letters and numbers. Its uniqueness
- can be satisfied by typing random characters on your keyboard.
-
-As a result, a file name can look something like
-``Misc/NEWS.d/next/Library/2017-05-27-16-46-23.gh-issue-12345.Yl4gI2.rst``.
-
-How to write a NEWS entry
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All ``NEWS`` entries end up being part of the changelog.
-The changelog contains *a lot* of entries,
-and its intended audience is mainly users, not core devs and contributors.
-Take this into consideration when wording your ``NEWS`` entry.
-Describe the user-visible effects of your change succinctly and accurately;
-avoid long technical elaborations, digressions, and do not expect or require
-the reader to have read the actual diff for the change.
-
-The contents of a ``NEWS`` file should be valid reStructuredText. An 80 character
-column width should be used. There is no indentation or leading marker in the
-file (for example, ``-``). There is also no need to start the entry with the issue
-number since it is part of the file name. You can use
-:ref:`inline markups ` too. Here is an example of a ``NEWS``
-entry::
-
- Fix warning message when :func:`os.chdir` fails inside
- :func:`test.support.temp_cwd`. Contributed by Chris Jerdonek.
-
-The inline Sphinx roles like ``:func:`` can be used help readers
-find more information. You can build HTML and verify that the
-link target is appropriate by using :ref:`make html `.
+ .. seealso::
+ :ref:`what-s-new-and-news-entries`
Working with Git_
@@ -178,7 +85,7 @@ Working with Git_
.. seealso::
:ref:`gitbootcamp`
-As a core developer, you have the ability to push changes to the official
+As a core team member, you have the ability to push changes to the official
Python repositories, so you need to be careful with your workflow:
* **You should not push new branches to the main repository.** You can
@@ -223,12 +130,12 @@ Backporting changes to an older version
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If it is determined that a pull request needs to be backported into one or
-more of the maintenance branches, then a core developer can apply the label
+more of the maintenance branches, then a core team member can apply the label
``needs backport to X.Y`` to the pull request.
After the pull request has been merged, miss-islington (bot) will first try to
do the backport automatically. If miss-islington is unable to do it,
-then the pull request author or the core developer who merged it should look into
+then the pull request author or the core team member who merged it should look into
backporting it themselves, using the backport generated by cherry_picker.py_
as a starting point.
@@ -251,7 +158,7 @@ Note that cherry_picker.py_ adds the branch prefix automatically.
Once the backport pull request has been created, remove the
``needs backport to X.Y`` label from the original pull request. (Only
-core developers and members of the :ref:`Python Triage Team `
+members of the core team and :ref:`Python Triage Team `
can apply labels to GitHub pull requests).
.. _cherry_picker.py: https://github.com/python/cherry-picker
diff --git a/core-developers/developers.csv b/core-team/core-team.csv
similarity index 88%
rename from core-developers/developers.csv
rename to core-team/core-team.csv
index a138f37397..48234eff4d 100644
--- a/core-developers/developers.csv
+++ b/core-team/core-team.csv
@@ -1,5 +1,10 @@
+Itamar Oren,itamaro,2026-02-16,,
+Emma Smith,emmatyping,2025-07-31,,
+Tomas Roun,tomasr8,2025-06-16,,
+Peter Bierma,ZeroIntensity,2025-06-16,,
+Diego Russo,diegorusso,2025-05-13,,
Bénédikt Tran,picnixz,2025-01-10,,
-Savannah Ostrowski,savannahostrowski,2024-11-13,,
+Savannah Ostrowski,savannahostrowski,2024-11-13,,
Matt Page,mpage,2024-10-10,,
Kirill Podoprigora,Eclips4,2024-09-20,,
Ned Batchelder,nedbat,2024-07-16,,
@@ -31,7 +36,7 @@ Kyle Stanley,aeros,2020-04-14,,
Donghee Na,corona10,2020-04-08,,
Karthikeyan Singaravelan,tirkarthi,2019-12-31,,
Joannah Nanjekye,nanjekyejoannah,2019-09-23,,
-Abhilash Raj,maxking,2019-08-06,,
+Abhilash Raj,maxking,2019-08-06,2022-11-30,Privileges relinquished on 2022-11-30
Paul Ganssle,pganssle,2019-06-15,,
Stéphane Wirtel,matrixise,2019-04-08,,
Stefan Behnel,scoder,2019-04-08,,
@@ -52,7 +57,7 @@ Xavier de Gaye,xdegaye,2016-06-03,2018-01-25,Privileges relinquished on 2018-01-
Davin Potts,applio,2016-03-06,,
Martin Panter,vadmium,2015-08-10,2020-11-26,
Paul Moore,pfmoore,2015-03-15,,
-Robert Collins,rbtcollins,2014-10-16,,To work on unittest
+Robert Collins,rbtcollins,2014-10-16,2021-11-30,To work on unittest; privileges relinquished on 2021-11-30
Berker Peksağ,berkerpeksag,2014-06-26,,
Steve Dower,zooba,2014-05-10,,
Kushal Das,kushaldas,2014-04-14,,
@@ -69,16 +74,16 @@ Hynek Schlawack,hynek,2012-05-14,,
Richard Oudkerk,,2012-04-29,2017-02-10,For multiprocessing module; did not make GitHub transition
Andrew Svetlov,asvetlov,2012-03-13,,At PyCon sprint
Petri Lehtinen,akheron,2011-10-22,2020-11-12,
-Meador Inge,meadori,2011-09-19,2020-11-26,
+Meador Inge,meadori,2011-09-19,,
Jeremy Kloth,jkloth,2011-09-12,,
Sandro Tosi,sandrotosi,2011-08-01,,
Alex Gaynor,alex,2011-07-18,,For PyPy compatibility (since expanded scope)
Charles-François Natali,,2011-05-19,2017-02-10,Did not make GitHub transition
Nadeem Vawda,,2011-04-10,2017-02-10,Did not make GitHub transition
-Carl Friedrich Bolz-Tereick,cfbolz,2011-03-21,,for stdlib compatibility work for PyPy
+CF Bolz-Tereick,cfbolz,2011-03-21,,for stdlib compatibility work for PyPy
Jason R. Coombs,jaraco,2011-03-14,,For sprinting on distutils2
Ross Lagerwall,,2011-03-13,2017-02-10,Did not make GitHub transition
-Eli Bendersky,eliben,2011-01-11,2020-11-26,
+Eli Bendersky,eliben,2011-01-11,2020-11-26,Relinquished privileges on 2020-11-26
Ned Deily,ned-deily,2011-01-09,,
David Malcolm,davidmalcolm,2010-10-27,2020-11-12,relinquished privileges on 2020-11-12
Tal Einat,taleinat,2010-10-04,,Initially for IDLE
@@ -100,12 +105,12 @@ Doug Hellmann,dhellmann,2009-09-20,2020-11-11,For documentation; relinquished pr
Frank Wierzbicki,,2009-08-02,2017-02-10,For Jython compatibility; did not make GitHub transition
Ezio Melotti,ezio-melotti,2009-06-07,,For documentation
Philip Jenvey,pjenvey,2009-05-07,2020-11-26,For Jython compatibility
-Michael Foord,voidspace,2009-04-01,,For IronPython compatibility
+Michael Foord,voidspace,2009-04-01,2025-01-24,For IronPython compatibility; deceased
R\. David Murray,bitdancer,2009-03-30,,
Chris Withers,cjw296,2009-03-08,,
Tarek Ziadé,tarekziade,2008-12-21,2017-02-10,For distutils module
Hirokazu Yamamoto,,2008-08-12,2017-02-10,For Windows build; did not make GitHub transition
-Armin Ronacher,mitsuhiko,2008-07-23,2020-11-26,For documentation toolset and ast module
+Armin Ronacher,mitsuhiko,2008-07-23,,For documentation toolset and ast module
Antoine Pitrou,pitrou,2008-07-16,,
Senthil Kumaran,orsenthil,2008-06-16,,
Jesse Noller,,2008-06-16,2017-02-10,For multiprocessing module; did not make GitHub transition
@@ -114,9 +119,9 @@ Guilherme Polo,,2008-04-24,2017-02-10,Did not make GitHub transition
Jeroen Ruigrok van der Werven,,2008-04-12,2017-02-10,For documentation; did not make GitHub transition
Benjamin Peterson,benjaminp,2008-03-25,,For bug triage
David Wolever,wolever,2008-03-17,2020-11-21,For 2to3 module
-Trent Nelson,tpn,2008-03-17,2020-11-26,
+Trent Nelson,tpn,2008-03-17,,
Mark Dickinson,mdickinson,2008-01-06,2024-08-13,For maths-related work
-Amaury Forgeot d'Arc,amauryfa,2007-11-09,2020-11-26,
+Amaury Forgeot d'Arc,amauryfa,2007-11-09,2020-11-26,Relinquished privileges on 2020-11-26
Christian Heimes,tiran,2007-10-31,,
Bill Janssen,,2007-08-28,2017-02-10,For ssl module; did not make GitHub transition
Jeffrey Yasskin,,2007-08-09,2017-02-10,Did not make GitHub transition
@@ -142,9 +147,9 @@ Facundo Batista,facundobatista,2004-10-16,,
Sean Reifschneider,,2004-09-17,2017-02-10,Did not make GitHub transition
Johannes Gijsbers,,2004-08-14,2005-07-27,Privileges relinquished on 2005-07-27
Matthias Klose,doko42,2004-08-04,,
-PJ Eby,pjeby,2004-03-24,2020-11-26,
+PJ Eby,pjeby,2004-03-24,2020-11-26,Relinquished privileges on 2020-11-26
Vinay Sajip,vsajip,2004-02-20,,
-Hye-Shik Chang,hyeshik,2003-12-10,,
+Hye-Shik Chang,hyeshik,2003-12-10,2025-02-28,Privileges relinquished on 2025-02-28
Armin Rigo,,2003-10-24,2012-06-01,Privileges relinquished in 2012
Andrew McNamara,,2003-06-09,2017-02-10,Did not make GitHub transition
Samuele Pedroni,,2003-05-16,2017-02-10,Did not make GitHub transition
@@ -153,11 +158,11 @@ Brett Cannon,brettcannon,2003-04-18,,
David Goodger,,2003-01-02,2017-02-10,Did not make GitHub transition
Gustavo Niemeyer,,2002-11-05,2017-02-10,Did not make GitHub transition
Tony Lownds,,2002-09-22,2017-02-10,Did not make GitHub transition
-Steve Holden,holdenweb,2002-06-14,2017-02-10,"Relinquished privileges on 2005-04-07,
+Steve Holden,holdenweb,2002-06-14,2017-02-10,"Relinquished privileges on 2005-04-07,
but granted again for Need for Speed sprint; did not make GitHub transition"
Christian Tismer,ctismer,2002-05-17,,For Need for Speed sprint
Jason Tishler,,2002-05-15,2017-02-10,Did not make GitHub transition
-Walter Dörwald,doerwalter,2002-03-21,,
+Walter Dörwald,doerwalter,2002-03-21,2021-11-16,Relinquished privileges on 2021-11-16
Andrew MacIntyre,,2002-02-17,2016-01-02,Privileges relinquished 2016-01-02
Gregory P. Smith,gpshead,2002-01-08,,
Anthony Baxter,,2001-12-21,2017-02-10,Did not make GitHub transition
@@ -190,7 +195,7 @@ Eric S. Raymond,,2000-06-02,2017-02-10,Did not make GitHub transition
Greg Stein,,1999-11-07,2017-02-10,Did not make GitHub transition
Just van Rossum,,1999-01-22,2017-02-10,Did not make GitHub transition
Greg Ward,,1998-12-18,2017-02-10,Did not make GitHub transition
-Andrew Kuchling,akuchling,1998-04-09,,
+Andrew Kuchling,akuchling,1998-04-09,2022-11-09,Privileges relinquished 2022-11-09
Ken Manheimer,,1998-03-03,2005-04-08,Privileges relinquished on 2005-04-08
Jeremy Hylton,jeremyhylton,1997-08-13,,
Roger E. Masse,,1996-12-09,2017-02-10,Did not make GitHub transition
diff --git a/core-developers/experts.rst b/core-team/experts.rst
similarity index 51%
rename from core-developers/experts.rst
rename to core-team/experts.rst
index ec9fc23067..87d3ba4c73 100644
--- a/core-developers/experts.rst
+++ b/core-team/experts.rst
@@ -20,12 +20,9 @@ following is added to an issue or pull request, they will be notified
automatically. The :cpy-file:`.github/CODEOWNERS` file is also used to indicate
maintainers that will be automatically added as reviewers to pull requests.
+Names followed by a '*' may be assigned issues involving the module or topic.
Unless a name is followed by a '*', you should never assign an issue to
-that person. Names followed by a '*' may be assigned issues involving the
-module or topic.
-
-Names followed by a '^' indicate old bugs.python.org usernames, for people
-that did not transition to GitHub.
+that person.
The Platform and Interest Area tables list broader fields in which various
people have expertise. These people can also be contacted for help,
@@ -52,212 +49,116 @@ Stdlib
==================== =============================================
Module Maintainers
==================== =============================================
-__future__
__main__ gvanrossum, ncoghlan
-_thread
-abc
-argparse savannahostrowski*
-array
+annotationlib JelleZijlstra*
+argparse savannahostrowski*, serhiy-storchaka*
ast benjaminp, pablogsal, isidentical, JelleZijlstra, eclips4
asyncio 1st1, asvetlov, gvanrossum, graingert, kumaraditya303, willingc
-atexit
-base64
-bdb
-binascii
bisect rhettinger*
-builtins
-bz2
-calendar
-cmath
-cmd
-code
-codecs malemburg, doerwalter
-codeop
+codecs malemburg
collections rhettinger*
-collections.abc rhettinger*, stutzbach^
-colorsys
+collections.abc rhettinger*
compileall carljm
-concurrent.futures pitrou, brianquinlan, gpshead*
+compression.zlib Yhg1s, gpshead*, emmatyping
+compression.zstd emmatyping*
+concurrent.futures pitrou, gpshead*
configparser ambv*
contextlib ncoghlan, 1st1
-contextvars
-copy avassalotti
-copyreg avassalotti
-cProfile
-csv smontanaro (inactive)
-ctypes theller (inactive), abalkin, amauryfa, meadori
+copy serhiy-storchaka*
+copyreg serhiy-storchaka*
+csv serhiy-storchaka*
curses Yhg1s
dataclasses ericvsmith*, carljm
-datetime abalkin, pganssle
-dbm
+datetime pganssle
decimal facundobatista, rhettinger
-difflib tim-one (inactive)
dis 1st1
-doctest tim-one (inactive)
-email warsaw, bitdancer*, maxking
+email warsaw, bitdancer*
encodings malemburg
ensurepip ncoghlan, dstufft, pradyunsg, pfmoore
-enum eliben*, warsaw, ethanfurman*
+enum warsaw, ethanfurman*
errno Yhg1s
-faulthandler vstinner, gpshead
+faulthandler vstinner, gpshead, ZeroIntensity*
fcntl Yhg1s
-filecmp
-fileinput
-fnmatch
-fractions
+fnmatch serhiy-storchaka*
ftplib giampaolo*
functools rhettinger*
-gc pitrou, pablogsal
-getopt
-getpath FFY00
-getpass
-gettext
-glob
-grp
-gzip
+gc pitrou, pablogsal, nascheme
+getopt serhiy-storchaka*
+getpath FFY00*
+gettext tomasr8
+glob serhiy-storchaka*
hashlib tiran, gpshead*, picnixz
-heapq rhettinger*, stutzbach^
+heapq rhettinger*
hmac tiran, gpshead*, picnixz
html ezio-melotti*
-http
-idlelib kbkaiser (inactive), terryjreedy*, serwy (inactive),
- taleinat
-imaplib
-imghdr
-importlib brettcannon
+idlelib terryjreedy*, taleinat
+importlib brettcannon, FFY00*
inspect 1st1
-io benjaminp, stutzbach^
-ipaddress pmoody^
+io benjaminp
itertools rhettinger*
-json etrepum (inactive), ezio-melotti, rhettinger
-keyword
-libmpdec
-linecache
+json ezio-melotti, rhettinger, serhiy-storchaka*
locale malemburg
logging vsajip
-lzma
-mailbox
-marshal
-math rhettinger, stutzbach^
-mimetypes
+math rhettinger
mmap Yhg1s
-modulefinder theller (inactive), jvr^
-msilib
-msvcrt
-multiprocessing applio*, pitrou, jnoller^ (inactive), sbt^ (inactive), gpshead*
-netrc
-nis
-nntplib
-numbers
-operator
-optparse mitsuhiko
-os
-os.path serhiy-storchaka
-ossaudiodev
+modulefinder FFY00
+multiprocessing pitrou, gpshead*
+optparse serhiy-storchaka*
+os.path serhiy-storchaka*
parser pablogsal
pathlib barneygale*
pdb gaogaotiantian
-pickle avassalotti
-pickletools avassalotti
-pipes
-pkgutil
+pickle serhiy-storchaka*
+pickletools serhiy-storchaka*
+pkgutil FFY00*
platform malemburg
-plistlib
-poplib
posix larryhastings, gpshead
-pprint freddrake
-profile
-pstats
pty Yhg1s*
-pwd
py_compile carljm
pyclbr isidentical
-pydoc AA-Turner
+pydoc AA-Turner, serhiy-storchaka*
queue rhettinger*
-quopri
random rhettinger
-re ezio-melotti, serhiy-storchaka
+re ezio-melotti, serhiy-storchaka*
readline Yhg1s
-reprlib
resource Yhg1s
-rlcompleter
-runpy ncoghlan
-sched
-secrets
-select
-selectors neologix^, giampaolo
-shelve
-shlex
-shutil tarekziade, giampaolo
+runpy ncoghlan, FFY00
+selectors giampaolo
+shutil giampaolo
signal gpshead
-site
-smtplib
-sndhdr
+site FFY00*
socket gpshead
-socketserver
-spwd
-sqlite3 ghaering^, erlend-aasland*
-ssl jackjansen, tiran, dstufft, alex
+sqlite3 erlend-aasland*
+ssl tiran, dstufft, alex
stat tiran
-statistics stevendaprano, rhettinger
-string
-stringprep
-struct meadori
-subprocess astrand^ (inactive), giampaolo, gpshead*
+statistics rhettinger
+subprocess giampaolo, gpshead*
symtable benjaminp
-sys
-sysconfig FFY00
-syslog jafo^*
-tabnanny tim-one (inactive)
-tarfile gustaebel
-tempfile
+sysconfig FFY00*
+tempfile serhiy-storchaka*
termios Yhg1s
-test ezio-melotti
-textwrap
+test ezio-melotti, serhiy-storchaka*
threading pitrou, gpshead
-time abalkin, pganssle
-timeit
-tkinter gpolo^, serhiy-storchaka
-token
-tokenize meadori
+time pganssle
+tkinter serhiy-storchaka*
tomllib hauntsaninja*
-trace abalkin
traceback iritkatriel
tracemalloc vstinner
tty Yhg1s*
-turtle gregorlingl^, willingc
+turtle willingc
turtledemo terryjreedy*
types 1st1
typing gvanrossum, JelleZijlstra*, AlexWaygood*, carljm, sobolevn*
unicodedata malemburg, ezio-melotti
-unittest voidspace*, ezio-melotti, rbtcollins, gpshead
-unittest.mock voidspace*
+unittest ezio-melotti, gpshead, serhiy-storchaka*
urllib orsenthil
-uu
-uuid
-venv vsajip, FFY00
-warnings
-wave
-weakref freddrake
-webbrowser
-winreg stutzbach^
-winsound
-wsgiref pjenvey
-xdrlib
-xml.dom
-xml.dom.minidom
-xml.dom.pulldom
-xml.etree eliben*, scoder
-xml.parsers.expat
-xml.sax
-xml.sax.handler
-xml.sax.saxutils
-xml.sax.xmlreader
-xmlrpc
+venv vsajip, FFY00*
+weakref nascheme
+xml.etree scoder
zipapp pfmoore
-zipfile alanmcintyre^, serhiy-storchaka, Yhg1s, gpshead
+zipfile serhiy-storchaka, Yhg1s, gpshead
zipimport Yhg1s*
-zlib Yhg1s, gpshead*
+zoneinfo pganssle
==================== =============================================
@@ -267,7 +168,8 @@ Tools
================== ===========
Tool Maintainers
================== ===========
-Argument Clinic larryhastings, AlexWaygood*, erlend-aasland
+Argument Clinic larryhastings, AlexWaygood*, erlend-aasland,
+ serhiy-storchaka*
Deepfreeze gvanrossum, kumaraditya303
PEG Generator gvanrossum, pablogsal, lysnikolaou
================== ===========
@@ -287,20 +189,15 @@ for “their” platform as a third-party project.
=================== ===========
Platform Maintainers
=================== ===========
-AIX edelsohn, ayappanec
+AIX ayappanec
Android mhsmith
-Cygwin jlt63^, stutzbach^
Emscripten hoodmane, pmp-p, rdb, rth, ryanking13
-FreeBSD
-HP-UX
iOS freakboy3742, ned-deily
Linux
macOS ronaldoussoren, ned-deily, freakboy3742
NetBSD1
-OS2/EMX aimacintyre^
-Solaris/OpenIndiana jcea
-Windows tjguk, zware, zooba, pfmoore
-JVM/Java frank.wierzbicki^
+Solaris/OpenIndiana jcea, kulikjak
+Windows tjguk, zooba, pfmoore
=================== ===========
@@ -308,13 +205,13 @@ Miscellaneous
=============
================== ==========================================================
-Interest Area Maintainers
+Interest area Maintainers
================== ==========================================================
-algorithms rhettinger*
-argument clinic larryhastings, AlexWaygood*, erlend-aasland
-ast/compiler benjaminp, 1st1, pablogsal, markshannon, isidentical, brandtbucher, carljm, iritkatriel
-autoconf/makefiles Yhg1s*
-bsd
+algorithms rhettinger*, serhiy-storchaka
+argument clinic larryhastings, AlexWaygood*, erlend-aasland,
+ serhiy-storchaka*
+AST/compiler benjaminp, 1st1, pablogsal, markshannon, isidentical, brandtbucher, carljm, iritkatriel
+autoconf/makefiles Yhg1s*, emmatyping
issue tracker ezio-melotti
buildbots zware, pablogsal
bytecode benjaminp, 1st1, markshannon, brandtbucher, carljm, iritkatriel
@@ -328,46 +225,251 @@ devguide merwok, ezio-melotti, willingc, Mariatta, hugovk,
documentation ezio-melotti, merwok, JulienPalard, willingc, hugovk,
AA-Turner, AlexWaygood*
emoji Mariatta
-extension modules encukou, ncoghlan
-filesystem giampaolo
-frozen modules ericsnowcurrently, gvanrossum, kumaraditya303
+extension modules encukou, ncoghlan, FFY00
+filesystem
+frozen modules ericsnowcurrently, gvanrossum, kumaraditya303, FFY00
f-strings ericvsmith*
GUI
-i18n malemburg, merwok
-import machinery brettcannon, ncoghlan, ericsnowcurrently, FFY00
-initialization FFY00
-io benjaminp, stutzbach^, gpshead
+i18n malemburg, merwok, tomasr8
+import machinery brettcannon, ncoghlan, ericsnowcurrently, FFY00*
+initialization FFY00*
+io benjaminp, gpshead
JIT brandtbucher*, savannahostrowski*
locale malemburg
-mathematics malemburg, stutzbach^, rhettinger
-memory management tim-one, malemburg, Yhg1s
+mathematics malemburg, rhettinger, serhiy-storchaka
+memory management tim-one, malemburg, Yhg1s, nascheme
memoryview
-networking giampaolo, gpshead
+networking gpshead
object model benjaminp, Yhg1s
-packaging tarekziade, malemburg, alexis^, merwok, dstufft, pfmoore
+packaging malemburg, merwok, dstufft, pfmoore, emmatyping, FFY00
pattern matching brandtbucher*
-peg parser gvanrossum, pablogsal, lysnikolaou
-performance vstinner, serhiy-storchaka, 1st1, rhettinger, markshannon, brandtbucher, carljm, Fidget-Spinner,
- AlexWaygood*
-pip ncoghlan, dstufft, pfmoore, Marcus.Smith^, pradyunsg
-py3 transition benjaminp
-release management tarekziade, malemburg, benjaminp, warsaw,
- gvanrossum, anthonybaxter^, merwok, ned-deily,
- birkenfeld, JulienPalard
-runtime lifecycle ericsnowcurrently, kumaraditya303, zooba
+PEG parser gvanrossum, pablogsal, lysnikolaou
+performance vstinner, serhiy-storchaka*, 1st1, rhettinger, markshannon,
+ brandtbucher, carljm, Fidget-Spinner, AlexWaygood*, nascheme
+pip ncoghlan, dstufft, pfmoore, pradyunsg
+release management malemburg, benjaminp, warsaw,
+ gvanrossum, merwok, ned-deily,
+ JulienPalard, hugovk
+runtime lifecycle ericsnowcurrently, kumaraditya303, zooba, ZeroIntensity, nascheme, FFY00
str.format ericvsmith*
-subinterpreters ericsnowcurrently, kumaraditya303
+subinterpreters ericsnowcurrently, kumaraditya303, ZeroIntensity*
symbol table JelleZijlstra, carljm
-testing voidspace, ezio-melotti
+testing ezio-melotti
test coverage
threads gpshead
-time and dates malemburg, abalkin, pganssle
-unicode malemburg, ezio-melotti, benjaminp
+time and dates malemburg, pganssle
+Unicode malemburg, ezio-melotti, benjaminp
version control merwok, ezio-melotti
================== ==========================================================
+Experts emeritus
+================
+
+Names followed by a '^' indicate old bugs.python.org usernames, for people
+that did not transition to GitHub.
+
+Stdlib
+------
+
+.. list-table::
+
+ * - Module
+ - Expert
+
+ * - codecs
+ - doerwalter
+
+ * - collections.abc
+ - stutzbach^
+
+ * - concurrent.futures
+ - brianquinlan
+
+ * - copy
+ - avassalotti
+
+ * - copyreg
+ - avassalotti
+
+ * - csv
+ - smontanaro
+
+ * - ctypes
+ - theller, abalkin, amauryfa, meadori
+
+ * - datetime
+ - abalkin
+
+ * - difflib
+ - tim-one
+
+ * - doctest
+ - tim-one
+
+ * - email
+ - maxking
+
+ * - enum
+ - eliben
+
+ * - heapq
+ - stutzbach
+
+ * - idlelib
+ - kbkaiser, serwy
+
+ * - io
+ - stutzbach^
+
+ * - ipaddress
+ - pmoody^
+
+ * - json
+ - etrepum
+
+ * - math
+ - stutzbach^
+
+ * - modulefinder
+ - theller, jvr^
+
+ * - multiprocessing
+ - applio, jnoller^, sbt^
+
+ * - optparse
+ - mitsuhiko
+
+ * - pickle
+ - avassalotti
+
+ * - pickletools
+ - avassalotti
+
+ * - pprint
+ - freddrake
+
+ * - selectors
+ - neologix^
+
+ * - shutil
+ - tarekziade
+
+ * - sqlite3
+ - ghaering^
+
+ * - ssl
+ - jackjansen
+
+ * - statistics
+ - stevendaprano
+
+ * - struct
+ - meadori
+
+ * - subprocess
+ - astrand^
+
+ * - syslog
+ - jafo^
+
+ * - tabnanny
+ - tim-one
+
+ * - tarfile
+ - gustaebel
+
+ * - time
+ - abalkin
+
+ * - tkinter
+ - gpolo^
+
+ * - tokenize
+ - meadori
+
+ * - trace
+ - abalkin
+
+ * - turtle
+ - gregorlingl^
+
+ * - unittest
+ - rbtcollins
+
+ * - weakref
+ - freddrake
+
+ * - winreg
+ - stutzbach^
+
+ * - wsgiref
+ - pjenvey
+
+ * - xml.etree
+ - eliben
+
+ * - zipfile
+ - alanmcintyre^
+
+Platforms
+---------
+
+.. list-table::
+
+ * - Platform
+ - Expert
+
+ * - AIX
+ - edelsohn
+
+ * - Cygwin
+ - jlt63^, stutzbach^
+
+ * - JVM/Java
+ - frank.wierzbicki^
+
+ * - OS2/EMX
+ - aimacintyre^
+
+
+Miscellaneous
+-------------
+
+.. list-table::
+
+ * - Interest Area
+ - Expert
+
+ * - filesystem
+ - giampaolo
+
+ * - io
+ - stutzbach^
+
+ * - mathematics
+ - stutzbach^
+
+ * - networking
+ - giampaolo
+
+ * - packaging
+ - tarekziade, alexis^
+
+ * - pip
+ - Marcus.Smith^
+
+ * - release management
+ - tarekziade, anthonybaxter^, birkenfeld
+
+ * - time and dates
+ - abalkin
+
+
Documentation translations
==========================
-For a list of translators, see :ref:`this table about translations `.
+Translations are within the charter of
+`Editorial Board `__.
+For a list of translations and their coordinators, see
+:ref:`this table of translations `.
diff --git a/core-developers/index.rst b/core-team/index.rst
similarity index 54%
rename from core-developers/index.rst
rename to core-team/index.rst
index 8555943a07..f8dafe05ee 100644
--- a/core-developers/index.rst
+++ b/core-team/index.rst
@@ -1,8 +1,9 @@
.. _core-dev:
+.. _core-team:
-===============
-Core developers
-===============
+=========
+Core team
+=========
.. toctree::
:maxdepth: 5
@@ -10,6 +11,7 @@ Core developers
responsibilities
committing
experts
- developer-log
+ team-log
motivations
- become-core-developer
+ join-team
+ memorialization
diff --git a/core-developers/become-core-developer.rst b/core-team/join-team.rst
similarity index 67%
rename from core-developers/become-core-developer.rst
rename to core-team/join-team.rst
index 739792b481..20ce9e4c98 100644
--- a/core-developers/become-core-developer.rst
+++ b/core-team/join-team.rst
@@ -1,24 +1,25 @@
.. _become-core-developer:
.. _coredev:
+.. _join-core-team:
-==============================
-How to become a core developer
-==============================
+=========================
+How to join the core team
+=========================
What it takes
=============
When you have consistently made contributions which meet quality standards
without requiring extensive rewrites prior to being committed,
-you may qualify for commit privileges and become a core developer of Python.
-You must also work well with other core developers (and people in general)
+you may qualify for commit privileges and join the core team of Python.
+You must also work well with other core team members (and people in general)
as you become an ambassador for the Python project.
-Typically a core developer will offer you the chance to gain commit privilege.
+Typically a core team member will offer you the chance to gain commit privilege.
The person making the offer will become your mentor and watch your commits for
a while to make sure you understand the development process. If other core
developers agree that you should gain commit privileges you are then extended
-an official offer. How core developers come to that agreement are outlined in
+an official offer. How core team members come to that agreement are outlined in
:pep:`13`.
@@ -28,7 +29,7 @@ Gaining commit privileges
After a candidate has demonstrated consistent contributions, commit privileges
are granted through these steps:
-#. A core developer (submitter, usually the mentor) starts a poll
+#. A core team member (submitter, usually the mentor) starts a poll
(see the :ref:`template ` below) in
the `Committers category`_ on the `Python Discourse`_.
@@ -38,13 +39,15 @@ are granted through these steps:
#. If the candidate receives at least two-thirds positive votes when the poll closes
(as per :pep:`13`), the submitter `emails the steering council
`_ with the candidate's email address
- requesting that the council either accept or reject the proposed membership.
+ requesting that the council either accept or reject the proposed membership. Technically, the
+ council may only `veto a positive vote `__.
-#. Assuming the steering council does not object, a member of the council or delegate
- (approver) will email the candidate:
+#. Assuming the steering council does not veto the positive vote, a member of the council or its
+ delegate (approver, usually in practice a :ref:`Developer-in-Residence `) will
+ email the candidate:
- A request for account details as required by
- `🔒 python/voters `_.
+ `🔒 python/voters `__.
- A reminder about the `Code of Conduct`_ and guidance on reporting issues
to the PSF Conduct WG.
@@ -52,11 +55,12 @@ are granted through these steps:
- Enable the various new privileges.
- Remove the new committer from the triage team, if applicable.
- - Add their details to `🔒 python/voters `_.
- - Update the devguide to publicly list their team membership
- at :ref:`developers`.
+ - Add their details to `🔒 python/voters `__.
+ - Once the python/voters update is merged, regenerate the public team membership
+ list at :ref:`developers`.
+ See "Public list of members" in the ``voters`` README.
- Post an announcement in the `Committers Discourse category
- `_. The past few announcements
+ `__. The past few announcements
were in the form of a separate post on the already open topic with
the poll.
@@ -65,7 +69,7 @@ Getting a python.org email address
Members of the core team can get an email address on the python.org domain.
For more details refer to the `python.org email policy
-`_.
+`__.
Poll template
@@ -86,10 +90,11 @@ Here's what it outputs, you can copy and paste it for your poll:
[/poll]
The important options in the poll builder set to get this result:
- - Show who voted: **disabled** (``public=false``)
- - Limit voting to these groups: **committers** (``groups=committers``)
- - Automatically close poll: **in 7 days** (``close=...``)
- - Show results: **When poll is closed** (``results=on_close``)
+
+- Show who voted: **disabled** (``public=false``)
+- Limit voting to these groups: **committers** (``groups=committers``)
+- Automatically close poll: **in 7 days** (``close=...``)
+- Show results: **When poll is closed** (``results=on_close``)
.. raw:: html
diff --git a/core-team/memorialization.rst b/core-team/memorialization.rst
new file mode 100644
index 0000000000..3d893a3029
--- /dev/null
+++ b/core-team/memorialization.rst
@@ -0,0 +1,159 @@
+.. _memorialize-core-developer:
+.. _memorialize-core-team-member:
+
+===============
+Memorialization
+===============
+
+Rationale
+=========
+
+When a core team member passes away, memorializing accounts helps create
+a space for remembering the contributor and protects against attempted
+logins and fraudulent activity.
+
+The process
+===========
+
+The memorialization process is performed by a member of the PSF staff
+with administrative access to current and historical systems where
+the core team has access.
+
+After the status of the core team member in question is confirmed,
+access to the systems listed below is revoked and some changes are
+made to how the user displays to others.
+
+To respect the choices that someone made while alive, we aim to preserve
+content of their accounts without changes after they've passed away.
+To support the bereaved, in some instances, we may remove or change
+certain content when the legacy contact or family members request it.
+
+GitHub
+------
+
+* The user is removed from the `python/ `__
+ organization on GitHub;
+* The user is removed from the `psf/ `__
+ organization on GitHub;
+* The user is removed from the `pypa/ `__
+ organization on GitHub.
+
+The PSF staff does not follow up with GitHub with regards to GitHub account
+cancellation as this action is reserved for next-of-kin or designated by
+the deceased GitHub user to act as an account successor.
+
+The general policy regarding deceased users on GitHub is described on their
+`Deceased User Policy `__
+page.
+
+Repositories in the organization
+--------------------------------
+
+* The user's GitHub handle is removed from ``/.github/CODEOWNERS``.
+ To see all that need action, perform
+ `this query `__.
+* The user is marked as deceased in the private
+ `voters/python-core.toml `__
+ file with the ``left=`` field set to the day of passing, if known.
+
+discuss.python.org
+------------------
+
+* The user's "custom status" is set to 🕊 ``in memoriam``;
+* The user's "about me" is amended with ``$firstname passed away on $date. [In memoriam.]($in_memoriam_post_url)``;
+* In the user's security "recently used devices" the staff member
+ chooses "Log out all";
+* In the user's permissions the staff member chooses "Deactivate account";
+* The user's trust level is reset to ``1: basic user`` (trust level 0
+ doesn't allow links in "About Me");
+* The user's "associated accounts" (like GitHub) that provide an
+ alternative login method, are all disconnected;
+* The user's API keys are revoked;
+* The user's admin or moderator right is revoked;
+* The user's primary email address is reset to
+ ``USERNAME@in-memoriam.invalid`` and secondary email addresses are
+ removed (this step requires the administrator to contact Discourse.org
+ staff via ``team@discourse.org``).
+
+The "in memoriam" Discourse topic mentioned above is best created by
+a community member close to the deceased.
+
+The general best practice for deceased community members on
+Discourse-powered forums is described on their
+`Best practices for deceased community members `__
+page.
+
+python.org email account
+------------------------
+
+The PSF staff member emails ``postmaster@python.org`` to ask the email
+administrator to:
+
+* remove SMTP access from ``USERNAME@python.org``;
+* reset the password to POP3/IMAP for ``USERNAME@python.org``;
+* disable email forwarding, if set up, for ``USERNAME@python.org`` and
+ leave a record permanently as "in memoriam" to avoid future account
+ name reuse;
+* remove this email from all mailing lists under ``@python.org``;
+* remove any known alternate emails for the same user from all mailing
+ lists under ``@python.org``.
+
+In case the email shutdown causes issues for the estate executors, the
+PSF will reasonably try to help if contacted directly.
+
+python.org admin
+----------------
+
+* The user's account (``/admin/users/user``) is deactivated (NOT deleted)
+ and their staff and superuser status is unchecked;
+* The user's password is reset to a long random string;
+* The user's primary email address is set to
+ ``USERNAME@in-memoriam.invalid`` and set as unverified;
+* The user's secondary email addresses are deleted;
+* The user's API keys (both on the account and ``tastypie``) are deleted;
+* The user's "I would like to be a PSF Voting Member" field is cleared.
+
+devguide.python.org
+-------------------
+
+* The user is marked as deceased in `core-team.csv `__;
+* The user is removed from the `experts index `__.
+
+bugs.python.org
+---------------
+
+While the issue tracker was migrated to GitHub, the Roundup instance
+is still up for historical purposes.
+
+* the PSF staff member logs into ``bugs.nyc1.psf.io``;
+* the PSF staff member runs ``roundup-admin`` to set the user's email
+ address to ``USERNAME@in-memoriam.invalid``;
+* the user's alternate emails are removed;
+* the user's password is reset to a long random string;
+* the PSF staff member removes any active login sessions from Postgres.
+
+Other PSF-related infrastructure
+--------------------------------
+
+* The PSF staff member notifies administrators of the Python Core Devs
+ Discord server to remove the user from the server. The PSF staff
+ does not follow up with Discord with regards to Discord account
+ cancellation. The general policy regarding deceased users on Discord
+ is available on their `Deceased or Incapacitated Users `__
+ page.
+
+* The user is removed from Salt configuration for the PSF infrastructure
+ in `/pillar/base/users `__
+ that allows SSH access to PSF-controlled servers.
+
+* The user might have ran a buildbot worker. The PSF staff member will
+ look for that in the
+ `buildmaster-config `__
+ repository.
+
+PyPI
+----
+
+* The PSF staff member notifies PyPI admins by emailing them at
+ ``admin@pypi.org`` to mark the user as inactive, remove their email
+ addresses, prohibit their password resets, and revoke all API keys.
diff --git a/core-developers/motivations.rst b/core-team/motivations.rst
similarity index 81%
rename from core-developers/motivations.rst
rename to core-team/motivations.rst
index b19c3062b8..d0e5a0cc18 100644
--- a/core-developers/motivations.rst
+++ b/core-team/motivations.rst
@@ -4,22 +4,22 @@
Motivations and affiliations
============================
-CPython core developers participate in the core development process for a
-variety of reasons. Being accepted as a core developer indicates that
+CPython core team members participate in the core development process for a
+variety of reasons. Being accepted as a core team member indicates that
an individual is interested in acquiring those responsibilities, has the
-ability to collaborate effectively with existing core developers, and has had
+ability to collaborate effectively with existing core team members, and has had
the time available to demonstrate both that interest and that ability.
-This page allows core developers that choose to do so to provide more
+This page allows core team members that choose to do so to provide more
information to the rest of the Python community regarding their personal
situation (such as their general location and professional affiliations), as
well as any personal motivations that they consider particularly relevant.
-Core developers that wish to provide this additional information add a new
+Core team members that wish to provide this additional information add a new
entry to the :ref:`published-motivations` section below. Guidelines relating
to content and layout are included as comments in the source code for this page.
-Core developers that are available for training, consulting, contract, or
+Core team members who are available for training, consulting, contract, or
full-time work, or are seeking crowdfunding support for their community
contributions, may also choose to provide that information here (including
linking out to commercial sites with the relevant details).
@@ -32,7 +32,7 @@ For more information on the origins and purpose of this page, see
Published entries
=================
-The following core developers have chosen to provide additional details
+The following core team members have chosen to provide additional details
regarding their professional affiliations and (optionally) other reasons for
participating in the CPython core development process:
@@ -43,7 +43,7 @@ participating in the CPython core development process:
Topic headings should be in the form of "Name (Country)" or
"Name (Continent)" to help give some indication as to the geographic
- distribution of core developers.
+ distribution of core team members.
NOTE: The rest of these guidelines are highly provisional - we can evolve
them as people add entries, and we decide on the style we like. The
@@ -97,22 +97,22 @@ participating in the CPython core development process:
.. topic:: Brett Cannon (Canada)
- * Personal site: `snarky.ca `_
+ * Personal site: `snarky.ca `__
* Microsoft (Software Developer)
* Python Software Foundation (Fellow)
.. topic:: Alyssa Coghlan (Australia)
- * Personal site: `Curious Efficiency `_
+ * Personal site: `Curious Efficiency `__
* `Extended bio `__
* Python Software Foundation (Fellow, Packaging Working Group)
- * Element Labs/LM Studio (Python deployment engineer)
+ * Westpac (Principal Python Engineer)
Alyssa began using Python as a testing and prototyping language while working
- for Boeing Defence Australia. She now primarily uses it as the lead project
- maintainer for the open source ``venvstacks`` Python deployment utility.
+ for Boeing Defence Australia, and now works for Westpac, supporting their
+ use of Python for a range of purposes.
- As a core developer, she is primarily interested in helping to ensure Python's
+ As a core team member, she is primarily interested in helping to ensure Python's
continued suitability for educational, testing and data analysis use cases,
as well as in encouraging good architectural practices when assembling Python
applications and test harnesses from open source components.
@@ -123,16 +123,16 @@ participating in the CPython core development process:
.. topic:: Steve Dower (United States/Australia)
* Microsoft (Software Developer)
- * Personal site: `stevedower.id.au `_
- * Speaking: `stevedower.id.au/speaking `_
- * Work blog: `devblogs.microsoft.com/python/ `_
+ * Personal site: `stevedower.id.au `__
+ * Speaking: `stevedower.id.au/speaking `__
+ * Work blog: `devblogs.microsoft.com/python/ `__
* Email address: steve.dower@python.org
Steve started with Python while automating a test harness for medical
devices, and now works for Microsoft on anything that makes Python more
accessible to developers on any platform.
- As a core developer, his focus is on maintaining the already excellent
+ As a core team member, his focus is on maintaining the already excellent
Windows support and improving Python's ability to be embedded in other
applications.
@@ -143,25 +143,25 @@ participating in the CPython core development process:
.. topic:: Mariatta (Canada)
- * Personal site: `mariatta.ca `_
- * Works as a `Software Engineer `_
+ * Personal site: `mariatta.ca `__
+ * Works as a `Software Engineer `__
in Vancouver, helps organize `Vancouver PyLadies
- `_ meetup on the side, and
- sometimes `speaks `_
+ `__ meetup on the side, and
+ sometimes `speaks `__
at conferences.
* Email address: mariatta@python.org
- * `Sponsor Mariatta on GitHub `_
- * `Patreon `_
+ * `Sponsor Mariatta on GitHub `__
+ * `Patreon `__
- Support Mariatta by `becoming a sponsor `_,
- sending her a `happiness packet `_,
- or `paypal `_.
+ Support Mariatta by `becoming a sponsor `__,
+ sending her a `happiness packet `__,
+ or `paypal `__.
.. topic:: R. David Murray (United States)
- * Personal site: `bitdance.com `_
+ * Personal site: `bitdance.com `__
* Available for `Python and Internet Services Consulting
- and Python contract programming `_
+ and Python contract programming `__
David has been involved in the Internet since the days when the old IBM
BITNET and the ARPANet got cross connected, and in Python programming since
@@ -177,7 +177,7 @@ participating in the CPython core development process:
David currently does both proprietary and open source development work,
primarily in Python, through the company in which he is a partner, `Murray &
- Walker, Inc `_. He has done contract work
+ Walker, Inc `__. He has done contract work
focused specifically on CPython development both through the PSF (the
kickstart of the email Unicode API development) and directly funded by
interested corporations (additional development work on email funded by
@@ -187,14 +187,14 @@ participating in the CPython core development process:
.. topic:: Antoine Pitrou (France)
- * LinkedIn: ``_ (Senior Software Engineer)
+ * LinkedIn: ``__ (Senior Software Engineer)
* QuantStack
* Python Software Foundation (Fellow)
* Email address: antoine@python.org
Antoine started working with Python in 2005 in order to implement a
decentralized virtual world protocol. He started contributing to CPython
- in 2007 and became a core developer in 2008. His motivations have been
+ in 2007 and became a core team member in 2008. His motivations have been
driven both by the abstract desire to make Python better for the whole
world, and by the concrete roadblocks he was hitting in professional
settings. Topics of choice have included interpreter optimizations,
@@ -213,7 +213,7 @@ participating in the CPython core development process:
Victor is paid by Red Hat to maintain Python upstream and downstream (RHEL,
CentOS, Fedora & Software collections). See `Victor's contributions to
- Python `_.
+ Python `__.
.. topic:: Kushal Das (India)
@@ -224,21 +224,21 @@ participating in the CPython core development process:
.. topic:: Barry Warsaw (United States)
* NVIDIA, Principal System Software Engineer, Open Source Python Ecosystem
- * Personal site: `barry.warsaw.us `_
- * Blog: `We Fear Change `_
- * `LinkedIn `_
- * `Bluesky `_
+ * Personal site: `barry.warsaw.us `__
+ * Blog: `We Fear Change `__
+ * `LinkedIn `__
+ * `Bluesky `__
* Email address: barry@python.org
* Python Software Foundation (Fellow)
Barry has been working in, with, and on Python since 1994. He attended the
- first Python workshop at `NIST `_ in Gaithersburg,
+ first Python workshop at `NIST `__ in Gaithersburg,
MD in 1994, where he met Guido and several other early Python adopters.
Barry subsequently worked with Guido for 8 years while at `CNRI
- `_. Barry has served as Python's postmaster,
+ `__. Barry has served as Python's postmaster,
webmaster, release manager, Language Summit co-chair, `Jython
- `_ project leader, `GNU Mailman
- `_ project leader, and Python Steering Council
+ `__ project leader, `GNU Mailman
+ `__ project leader, and Python Steering Council
member in 2019, 2020, 2021, 2024, and 2025.
.. topic:: Eric Snow (United States)
@@ -256,13 +256,13 @@ participating in the CPython core development process:
developers on the project for 6 years. After that he started the Python
Tools for Visual Studio project focusing on providing advanced code completion
and debugging features for Python. Today he works on
- `Cinder `_ improving Python
+ `Cinder `__ improving Python
performance for Instagram.
.. topic:: Carol Willing (United States)
* Noteable (VP Engineering)
- * Personal site: `Willing Consulting `_
+ * Personal site: `Willing Consulting `__
* `Extended bio `__
* Project Jupyter (Software Council, Core Team for JupyterHub/Binder)
* Python Software Foundation (Fellow)
@@ -279,12 +279,12 @@ Goals of this page
The `issue metrics`_ automatically collected by the CPython issue tracker
strongly suggest that the current core development process is bottlenecked on
-core developer time. This is most clearly indicated in the first metrics graph,
+core team time. This is most clearly indicated in the first metrics graph,
which shows both the number of open issues and the number of pull requests awaiting
review growing steadily over time, despite CPython being one of the most
active open source projects in the world. This bottleneck then impacts not only
resolving open issues and accepting submitted pull requests, but also the process of
-identifying, nominating and mentoring new core developers.
+identifying, nominating and mentoring new core team members.
The core commit statistics monitored by sites like `OpenHub`_ provide a good
record as to *who* is currently handling the bulk of the review and maintenance
@@ -293,13 +293,13 @@ people's ability to spend time on reviewing proposed changes, or mentoring new
contributors.
This page aims to provide at least some of that missing data by encouraging
-core developers to highlight professional affiliations in the following two
+core team members to highlight professional affiliations in the following two
cases (even if not currently paid for time spent participating in the core
development process):
-* developers working for vendors that distribute a commercially supported
+* members working for vendors that distribute a commercially supported
Python runtime
-* developers working for Sponsor Members of the Python Software Foundation
+* members working for Sponsor Members of the Python Software Foundation
These are cases where documenting our affiliations helps to improve the
overall transparency of the core development process, as well as making it
@@ -307,20 +307,20 @@ easier for staff at these organisations to locate colleagues that can help
them to participate in and contribute effectively to supporting the core
development process.
-Core developers working for organisations with a vested interest in the
+Core team members working for organisations with a vested interest in the
sustainability of the CPython core development process are also encouraged to
seek opportunities to spend work time on mentoring potential new core
developers, whether through the general `core mentorship program`_, through
mentoring colleagues, or through more targeted efforts like Outreachy's paid
`internships`_ and Google's `Summer of Code`_.
-Core developers that are available for consulting or contract work on behalf of
+Core team members who are available for consulting or contract work on behalf of
the Python Software Foundation or other organisations are also encouraged
to provide that information here, as this will help the PSF to better
facilitate funding of core development work by organisations that don't
-directly employ any core developers themselves.
+directly employ any core team members themselves.
-Finally, some core developers seeking to increase the time they have available
+Finally, some core team members seeking to increase the time they have available
to contribute to CPython may wish to pursue crowdfunding efforts that allow
their contributions to be funded directly by the community, rather than relying
on institutional sponsors allowing them to spend some or all of their work
@@ -336,15 +336,15 @@ time contributing to CPython development.
Limitations on scope
====================
-* Specific technical areas of interest for core developers should be captured in
+* Specific technical areas of interest for core team members should be captured in
the :ref:`Experts Index `.
-* This specific listing is limited to CPython core developers (since it's
- focused on the specific constraint that is core developer time), but it
+* This specific listing is limited to CPython core team members (since it's
+ focused on the specific constraint that is core team member time), but it
would be possible to create a more expansive listing on the Python wiki that
- also covers issue triagers, and folks seeking to become core developers.
+ also covers issue triagers, and folks seeking to join the core team.
-* Changes to the software and documentation maintained by core developers,
+* Changes to the software and documentation maintained by the core team,
together with related design discussions, all take place in public venues, and
hence are inherently subject to full public review. Accordingly, core
developers are NOT required to publish their motivations and affiliations if
diff --git a/core-developers/responsibilities.rst b/core-team/responsibilities.rst
similarity index 84%
rename from core-developers/responsibilities.rst
rename to core-team/responsibilities.rst
index 5cd5ed7bdb..9f5c62b728 100644
--- a/core-developers/responsibilities.rst
+++ b/core-team/responsibilities.rst
@@ -5,25 +5,25 @@ Responsibilities
================
As contributors to the CPython project, our shared responsibility is to
-collaborate constructively with other contributors, including core developers.
+collaborate constructively with other contributors, including core team members.
This responsibility covers all forms of contribution, whether that's submitting
pull requests to the implementation or documentation, reviewing other peoples'
pull requests, triaging issues on the issue tracker, or discussing design and
development ideas on the core
:ref:`communication channels `.
-Core developers accept key additional responsibilities around the ongoing
+Core team members accept key additional responsibilities around the ongoing
management of the project:
-* core developers bear the additional responsibility of handling the
+* core team members bear the additional responsibility of handling the
consequences of accepting a change into the code base or documentation.
That includes reverting or fixing it if it causes problems in the
Buildbot fleet or someone spots a problem in post-commit review, as well
as helping out the release manager in resolving any problems found during
the pre-release testing cycle. While all contributors are free to help out
with this part of the process, and it is most welcome when they do, the
- actual responsibility rests with the core developer that merged the change
-* core developers also bear the primary responsibility for deciding when
+ actual responsibility rests with the core team member that merged the change
+* core team members also bear the primary responsibility for deciding when
changes proposed on the issue tracker should be escalated to
the appropriate :ref:`Discourse ` category
for wider discussion, as well as suggesting the use of the
@@ -31,15 +31,15 @@ management of the project:
of complex changes, or changes with a potentially significant impact on
end users
-As a result of the additional responsibilities they accept, core developers
+As a result of the additional responsibilities they accept, core team members
gain the privilege of being able to approve proposed changes, as well as being
-able to reject them as inappropriate. Core developers are also able to request
+able to reject them as inappropriate. Core team members are also able to request
that even already merged changes be escalated to
:ref:`Discourse ` for further discussion,
and potentially even reverted prior to release.
-Becoming a core developer isn't a binary "all-or-nothing" status - CPython
-is a large project, and different core developers accept responsibility for
+Joining the core team isn't a binary "all-or-nothing" status - CPython
+is a large project, and different core team members accept responsibility for
making design and development decisions in different areas (as documented
in the :ref:`experts` and :ref:`developers`).
@@ -48,12 +48,12 @@ Communication channels and bug notifications
============================================
Mailing lists have generally been replaced by the
-`Discourse forum `_ (``discuss.python.org``).
+`Discourse forum `__ (``discuss.python.org``).
Refer to the :ref:`mailinglists` and :ref:`communication-discourse` sections
for more information.
If you want notification of new issues, you can use the appropriate GitHub notification
-settings for the `python/cpython `_ repository —
+settings for the `python/cpython `__ repository —
follow the link and click on the :guilabel:`Watch` button to set your notification options.
@@ -82,7 +82,7 @@ Pull request merging
Once you have your commit privileges on GitHub you will be able to accept
pull requests on GitHub. You should plan to continue to submit your own
-changes through pull requests as if you weren't a core developer to benefit
+changes through pull requests as if you weren't a core team member to benefit
from various things such as automatic integration testing, but you
can accept your own pull requests if you feel comfortable doing so.
@@ -90,13 +90,13 @@ can accept your own pull requests if you feel comfortable doing so.
Expectations
============
-As a core developer, there are certain things that are expected of you.
+As a core team member, there are certain things that are expected of you.
First and foremost, be a good person. This might sound melodramatic, but you
are now a member of the Python project and thus represent the project and your
-fellow core developers whenever you discuss Python with anyone. We have a
+fellow core team members whenever you discuss Python with anyone. We have a
reputation for being a very nice group of people and we would like to keep it
-that way. Core developers responsibilities include following the `PSF Code of
+that way. Core team responsibilities include following the `PSF Code of
Conduct`_.
Second, please be prompt in responding to questions. Many contributors to Python
@@ -118,7 +118,7 @@ remove yourself from the list.
Fourth, please consider whether or not you wish to add your name to the
:ref:`motivations` list. Core contributor participation in the list helps the
wider Python community to better appreciate the perspectives currently
-represented amongst the core development team, the Python Software Foundation
+represented amongst the core team, the Python Software Foundation
to better assess the sustainability of current contributions to CPython core
development, and also serves as a referral list for organisations seeking
commercial Python support from the core development community.
diff --git a/core-developers/developer-log.rst b/core-team/team-log.rst
similarity index 85%
rename from core-developers/developer-log.rst
rename to core-team/team-log.rst
index 665ef07003..77639ebf1d 100644
--- a/core-developers/developer-log.rst
+++ b/core-team/team-log.rst
@@ -1,16 +1,17 @@
.. _developer-log:
.. _developers:
+.. _team-log:
-Developer log
-=============
+Team log
+========
-This page lists the historical members of the Python development team. (The
+This page lists the historical members of the Python core team. (The
master list is kept in a private repository due to containing sensitive contact
information.)
.. csv-table::
:header: "Name", "GitHub username", "Joined", "Left", "Notes"
- :file: developers.csv
+ :file: core-team.csv
:encoding: "utf-8"
Procedure for granting or dropping access
diff --git a/developer-workflow/c-api.rst b/developer-workflow/c-api.rst
index 3f8c03e92c..427d9fd96a 100644
--- a/developer-workflow/c-api.rst
+++ b/developer-workflow/c-api.rst
@@ -19,8 +19,13 @@ The C API is divided into these tiers:
Each tier has different stability and maintenance requirements to consider
when you add or change definitions in it.
-The compatibility guarantees for public C API are explained in the
-user documentation, ``Doc/c-api/stable.rst`` (:ref:`python:stable`).
+The public backwards compatibility guarantees for public C API are explained
+in the user documentation, ``Doc/c-api/stable.rst`` (:ref:`python:stable`).
+C language compatibility guarantees are in ``Doc/c-api/intro.rst``
+(:ref:`python:api-intro`).
+
+As core developers, we need to be more careful about compatibility than what
+we promise publicly. See :ref:`public-capi` for details.
The internal API
@@ -33,7 +38,7 @@ While internal API can be changed at any time, it's still good to keep it
stable: other API or other CPython developers may depend on it.
For users, internal API is sometimes the best workaround for a thorny problem
--- though those use cases should be discussed on the
-`C API Discourse category `_
+`C API Discourse category `__
or an issue so we can try to find a supported way to serve them.
@@ -93,6 +98,17 @@ CPython's public C API is available when ``Python.h`` is included normally
It should be defined in ``Include/cpython/`` (unless part of the Limited API,
see below).
+Before adding new public API, please ask in the `decisions repo`_ of
+the :pep:`C API workgroup <731>`.
+This helps us ensure *newly added* API is consistent and maintainable.
+
+Also check with the C API WG before requiring a C feature not present in C99.
+While the *public* docs only promise compatibility with C11, in practice
+we only introduce C11 features individually as needed.
+
+.. _decisions repo: https://github.com/capi-workgroup/decisions/issues
+
+
.. _public-api-guidelines:
Guidelines for expanding/changing the public API
@@ -202,7 +218,7 @@ use this API reliably:
(:samp:`3.{x}.0`, including Alphas and Betas for :samp:`3.{x}.0`).
* Adding a new unstable API *for an existing feature* is allowed even after
Beta feature freeze, up until the first Release Candidate.
- Consensus on the `Core Development Discourse `_
+ Consensus on the `Core Development Discourse `__
is needed in the Beta period.
* Backwards-incompatible changes should make existing C callers fail to compile.
For example, arguments should be added/removed, or a function should be
@@ -371,7 +387,7 @@ Guidelines for adding to the Limited API
details involve:
- The GIL
- - :ref:`Garbage collection `
+ - Garbage collection
- Memory layout of PyObject, lists/tuples and other structures
If following these guidelines would hurt performance, add a fast function
@@ -379,9 +395,8 @@ If following these guidelines would hurt performance, add a fast function
API.
If anything is unclear, or you have a good reason to break the guidelines,
-consider discussing the change at the `capi-sig`_ mailing list.
-
-.. _capi-sig: https://mail.python.org/mailman3/lists/capi-sig.python.org/
+consider discussing the change in the `C API category
+`__ on Discourse.
Adding a new definition to the Limited API
------------------------------------------
diff --git a/developer-workflow/communication-channels.rst b/developer-workflow/communication-channels.rst
index 499ca9b964..78fbf21dff 100644
--- a/developer-workflow/communication-channels.rst
+++ b/developer-workflow/communication-channels.rst
@@ -27,12 +27,13 @@ in return.
Mailing lists
=============
-.. note:: Some mailing lists have been supplanted by categories in the
- Python `Discourse`_. Specifically,
+.. note::
+
+ Mailing lists have generally been replaced by the `Discourse`_ forum.
+ Specifically,
* The python-dev list is superseded by the `Core Development`_
and `PEPs`_ categories on Discourse.
-
* The python-ideas list is superseded by posts in the `Ideas`_
category on Discourse.
@@ -42,36 +43,33 @@ Mailing lists
- Ideas about new functionality should **not** start here, and instead
should be discussed in `Ideas`_.
- Technical support questions should also not be asked here, and instead
- should go to the python-list_ or python-help_ mailing lists, or the
- `Python Help`_ category on Discourse.
+ should go to the `Python Help`_ category on Discourse or the python-list_.
-Existing threads on the python-dev_, python-committers_, and python-ideas_ mailing lists
-can be accessed through the `online archive `__.
+ Previous threads on the python-dev_, python-committers_, and python-ideas_
+ mailing lists can be accessed through the `online archive
+ `__.
+
+ .. _python-committers: https://mail.python.org/mailman3/lists/python-committers.python.org/
+ .. _python-dev: https://mail.python.org/mailman3/lists/python-dev.python.org/
+ .. _python-ideas: https://mail.python.org/archives/list/python-ideas@python.org/
General Python questions should go to `python-list`_ or `tutor`_
-or similar resources, such as StackOverflow_ or the ``#python`` IRC channel
+or similar resources, such as `Stack Overflow`_ or the ``#python`` IRC channel
on Libera.Chat_.
-`The core-workflow `_
+The `core-workflow `__
issue tracker is the place to discuss and work on improvements to the CPython
core development workflow.
A complete list of Python mailing lists can be found at
-https://mail.python.org/mailman/listinfo (older lists, using Mailman2) or
-https://mail.python.org/mailman3/ (newer lists, using Mailman3). Some lists may also
-be mirrored at `GMANE `_ and can be read and posted to in various
+https://mail.python.org/mailman3/. Some lists may also
+be mirrored at `GMANE `__ and can be read and posted to in various
ways, including via web browsers, NNTP newsreaders, and RSS feed readers.
-.. _issue tracker: https://github.com/python/cpython/issues
-.. _python-committers: https://mail.python.org/mailman3/lists/python-committers.python.org/
-.. _python-dev: https://mail.python.org/mailman3/lists/python-dev.python.org/
-.. _python-help: https://mail.python.org/mailman/listinfo/python-help
-.. _python-ideas: https://mail.python.org/mailman3/lists/python-ideas.python.org
-.. _python-list: https://mail.python.org/mailman/listinfo/python-list
-.. _tutor: https://mail.python.org/mailman/listinfo/tutor
-.. _StackOverflow: https://stackoverflow.com/
+.. _python-list: https://mail.python.org/mailman3/lists/python-list.python.org/
+.. _tutor: https://mail.python.org/mailman3/lists/tutor.python.org/
+.. _Stack Overflow: https://stackoverflow.com/
.. _Libera.Chat: https://libera.chat/
-.. _web gateway: https://mail.python.org/archives/
.. _communication-discourse:
@@ -79,19 +77,16 @@ ways, including via web browsers, NNTP newsreaders, and RSS feed readers.
Discourse (discuss.python.org web forum)
========================================
-We have our own `Discourse`_ forum for both developers and users. This forum
-complements the `python-dev`_, `python-ideas`_, `python-help`_, and
-`python-list`_ mailing lists.
-
-This forum has different categories and most core development discussions
+We have our own `Discourse`_ forum for both developers and users.
+It has different categories and most core development discussions
take place in the open forum categories for `PEPs`_ and `Core Development`_
(these are the Discourse equivalents to the python-dev mailing list).
All categories are open for users to read and post with the exception of
the `Committers`_ category, where posting is restricted to the `CPython
-`_ core developers.
+`__ core team.
The Committers category is often used for announcements and notifications.
-It is also the designated venue for the core developer promotion votes.
+It is also the designated venue for the core team promotion votes.
Tutorials for new users
-----------------------
@@ -101,8 +96,8 @@ create an account using an email address or GitHub account. You can do so by
clicking the :guilabel:`Sign Up` button on the top right hand corner of the
`Discourse`_ main page.
-The Python Discourse `Quick Start `_
-compiled by `Carol Willing `_ gives you
+The Python Discourse `Quick Start `__
+compiled by `Carol Willing `__ gives you
a quick overview on how to kick off Python Discourse.
We recommend new users getting familiarised with the forum by going through Discobot tutorials.
@@ -118,13 +113,13 @@ Greetings!" received under Notifications and Messages in your user account.
* Select either Notifications or Messages.
* Open the "Greetings!" message sent by Discobot to start the tutorial.
-Ensure that you read through the `Python Code of Conduct `_.
+Ensure that you read through the `Python Code of Conduct `__.
We are to be open, considerate and respectful to all users in the community.
You can report messages that don't respect the CoC by clicking on the three
dots under the message and then on the :guilabel:`⚐` icon. You can also mention the
-`@staff `_,
-`@moderators `_, or
-`@admins `_ groups in a message.
+`@staff `__,
+`@moderators `__, or
+`@admins `__ groups in a message.
@@ -168,7 +163,7 @@ Customising notifications on user preference
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To get a bird's eye view of all your customised notifications, you can
-go to `Preferences of your account `_.
+go to `Preferences of your account `__.
This allows you to make adjustments according to categories, users, and tags.
Enabling mailing list mode
@@ -178,7 +173,7 @@ In mailing list mode, you will receive one email per post, as happens with
traditional mailing lists. This is desirable if you prefer to interact via email,
without visiting the forum website.
To activate the mailing list mode, go to the `email preferences
-`_, check "Enable
+`__, check "Enable
mailing list mode" and save changes.
.. _Discourse: https://discuss.python.org/
@@ -193,22 +188,22 @@ Discord (private chat server)
=============================
For more real-time discussions, the core development team have a private Discord
-server available. Core developers, Steering Council members, triagers, and
+server available. Core team members, Steering Council members, triagers, and
documentarians on the project are eligible to join the server. Joining the
Discord server is entirely optional, as all essential communications occur on
the mailing lists and Discourse forums.
-For core developers, a long lived multiple use invitation link for this server
-can be found in the private core developer only section of the Discourse forum.
+For core team members, a long-lived multiple-use invitation link for this server
+can be found in the private core team only section of the Discourse forum.
For triagers and documentarians joining the Discord server, a single use invitation
link should be generated and sent to them directly.
When first joining the server, new users will only have access to the ``#welcome``
and ``#rules-and-info`` channels. To link their Discord ID with their project
-role, core developers may update their Steering Council 🔒 `voter record`_ with
+role, core team members may update their Steering Council 🔒 `voter record`_ with
their Discord ID before posting in the ``#welcome`` channel to request access
-to the rest of the server channels. Triagers, documentarians, and core developers
+to the rest of the server channels. Triagers, documentarians, and core team members
that would prefer not to add their Discord ID to their Steering Council voter
record may instead be vouched for by an existing member of the Discord server.
@@ -229,7 +224,7 @@ set a specific `Server Nickname`_
IRC
===
-Some core developers still participate in the ``#python-dev`` IRC channel on
+Some core team members still participate in the ``#python-dev`` IRC channel on
``irc.libera.chat``. This is not a place to ask for help with Python, but to
discuss issues related to Python's own development. See also the
``#python-dev-notifs`` channel for bots notifications.
@@ -238,7 +233,7 @@ discuss issues related to Python's own development. See also the
Blogs
=====
-Several core developers are active bloggers and discuss Python's development
+Several core team members are active bloggers and discuss Python's development
that way. You can find their blogs (and various other developers who use Python)
at `Planet Python `__.
@@ -247,22 +242,23 @@ Setting expectations for open source participation
==================================================
Burn-out is common in open source due to a misunderstanding of what users, contributors,
-and maintainers should expect from each other. Brett Cannon gave a `talk `_
+and maintainers should expect from each other. Brett Cannon gave a `talk `__
about this topic that sets out to help everyone set reasonable expectations of each other in
order to make open source pleasant for everyone involved.
Additional repositories
=======================
-`Python Core Workflow`_ hosts the codebase for tools such as :pypi:`blurb`.
+`Python Core Workflow`_ hosts an issue tracker for workflow discussions.
-Other core workflow tools are:
+Some core workflow tools are:
* `cherry_picker`_ (:pypi:`PyPI `)
* `bedevere`_
+* `blurb`_ (:pypi:`PyPI `)
* `blurb_it`_
* `miss-islington`_
-* `cla-bot`_
+* `clabot`_
* `webhook-mailer`_
Python `Performance Benchmark`_ project is intended to be an authoritative
@@ -271,8 +267,9 @@ source of benchmarks for all Python implementations.
.. _Python Core Workflow: https://github.com/python/core-workflow
.. _cherry_picker: https://github.com/python/cherry-picker
.. _bedevere: https://github.com/python/bedevere
+.. _blurb: https://github.com/python/blurb
.. _blurb_it: https://github.com/python/blurb_it
.. _miss-islington: https://github.com/python/miss-islington
-.. _cla-bot: https://github.com/ambv/cla-bot
+.. _clabot: https://github.com/psf/clabot
.. _webhook-mailer: https://github.com/python/webhook-mailer
.. _Performance Benchmark: https://github.com/python/pyperformance
diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst
index 8a37692ad6..af198a4007 100644
--- a/developer-workflow/development-cycle.rst
+++ b/developer-workflow/development-cycle.rst
@@ -4,7 +4,7 @@
Development cycle
=================
-The responsibilities of a core developer shift based on what kind of branch of
+The responsibilities of a core team member shift based on what kind of branch of
Python a developer is working on and what stage the branch is in.
To clarify terminology, Python uses a ``major.minor.micro`` nomenclature
@@ -68,8 +68,8 @@ Maintenance branches
A branch for a previous feature release, currently being maintained for bug
fixes, or for the next feature release in its
:ref:`beta ` or :ref:`release candidate ` stages.
-There is usually either one or two maintenance branches at any given time for
-Python 3.x. After the final release of a new minor version (3.x.0), releases
+There are usually either one or two maintenance branches at any given time.
+After the final release of a new minor version (3.x.0), releases
produced from a maintenance branch are called **bugfix** or **maintenance**
releases; the terms are used interchangeably. These releases have a
**micro version** number greater than zero.
@@ -134,7 +134,7 @@ former branch, for example, ``3.8`` or ``2.7``.
The :ref:`versions` page contains list of active and end-of-life branches.
The latest release for each Python version can be found on the `download page
-`_.
+`__.
.. _stages:
@@ -142,7 +142,7 @@ Stages
------
Based on what stage the :ref:`in-development ` version of Python
-is in, the responsibilities of a core developer change in regards to commits
+is in, the responsibilities of a core team member change in regards to commits
to the :abbr:`VCS (version control system)`.
@@ -159,7 +159,7 @@ avoiding breaking the buildbots).
Alpha
^^^^^
-Alpha releases typically serve as a reminder to core developers that they
+Alpha releases typically serve as a reminder to the core team that they
need to start getting in changes that change semantics or add something to
Python as such things should not be added during a Beta_. Otherwise no new
restrictions are in place while in alpha.
@@ -171,16 +171,13 @@ Beta
After a first beta release is published, no new features are accepted. Only
bug fixes and improvements to documentation and tests can now be committed.
-This is when core developers should concentrate on the task of fixing
+This is when the core team should concentrate on the task of fixing
regressions and other new issues filed by users who have downloaded the alpha
and beta releases.
Being in beta can be viewed much like being in RC_ but without the extra
overhead of needing commit reviews.
-Please see the note in the `In-development (main) branch`_ section above for
-new information about the creation of the 3.5 maintenance branch during beta.
-
.. _rc:
@@ -188,18 +185,18 @@ Release Candidate (RC)
^^^^^^^^^^^^^^^^^^^^^^
A branch preparing for an RC release can only have bugfixes applied that have
-been reviewed by other core developers. Generally, these issues must be
+been reviewed by other core team members. Generally, these issues must be
severe enough (for example, crashes) that they deserve fixing before the final release.
All other issues should be deferred to the next development cycle, since
stability is the strongest concern at this point.
-While the goal is to have no code changes between a RC and a final release,
+While the goal is to have no code changes between an RC and a final release,
there may be a need for final documentation or test fixes. Any such proposed
changes should be discussed first with the release manager.
You **cannot** skip the peer review during an RC, no matter how small! Even if
it is a simple copy-and-paste change, **everything** requires peer review from
-a core developer.
+a core team member.
.. _final:
@@ -207,36 +204,38 @@ Final
^^^^^
When a final release is being cut, only the release manager (RM) can make
-changes to the branch. After the final release is published, the full
-:ref:`development cycle ` starts again for the next minor version.
+changes to the branch.
Repository administration
-------------------------
The source code is currently hosted on `GitHub
-`_ in the `Python organization `_.
+`__ in the `Python organization `__.
Organization repository policy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Within the `GitHub Python organization `_,
+Within the `GitHub Python organization `__,
repositories are expected to relate to the Python language, the CPython
reference implementation, their documentation and their development workflow.
This includes, for example:
-* The reference implementation of Python and related repositories: `CPython `_.
-* Tooling and support around CPython development: `pyperformance `_, `Bedevere `_.
-* Helpers and backports for Python/CPython features: `typing_extensions `_, `typeshed `_, `tzdata `_, `pythoncapi-compat `_.
-* Organization-related repositories: the `Code of Conduct `_, `.github `_.
-* Documentation and websites for all the above: `python.org repository `_, `PEPs `_, `Devguide `_, docs translations.
-* Infrastructure for all the above: `docsbuild-scripts `_, `buildmaster-config `_.
-* Discussions and notes around official development-related processes and events: `steering-council `_, `core-sprint `_.
+* The reference implementation of Python and related repositories: `CPython `__.
+* Tooling and support around CPython development: `pyperformance `__, `Bedevere `__.
+* Helpers and backports for Python/CPython features: `typing_extensions `__, `typeshed `__, `tzdata `__, `pythoncapi-compat `__.
+* Organization-related repositories: the `Code of Conduct `__, `.github `__.
+* Documentation and websites for all the above: `python.org repository `__, `PEPs `__, `Devguide `__, docs translations.
+* Infrastructure for all the above: `docsbuild-scripts `__, `buildmaster-config `__.
+* Discussions and notes around official development-related processes and events: `steering-council `__, `core-sprint `__.
Before adding a new repository to the organization, open a discussion to seek consensus
-in the `Committers Discourse category `_.
-Once people are satisfied with that, ask the `Python steering council `_
-to grant permission.
+in the `Committers Discourse category `__.
+Once people are satisfied with that, ask the `Python steering council `__
+to grant permission. Note that this process is not necessary for
+:ref:`docs translations ` following
+:pep:`PEP 545 <545#repository-for-po-files>`, which can be added at a
+core team member’s discretion.
Note that several repositories remain in the organization for historic reasons,
and would probably not be appropriate to add today.
@@ -244,18 +243,18 @@ and would probably not be appropriate to add today.
Generally, new repositories should start their life under personal GitHub
accounts or other GitHub orgs. It is relatively easy to move a repository to
the organization once it is mature. For example, this would now apply to
-experimental features like `asyncio `_,
-`exceptiongroups `_,
+experimental features like `asyncio `__,
+`exceptiongroups `__,
and drafts of new guides and other documentation (for example, `redistributor-guide
-`_).
+`__).
-General-use tools and libraries (for example, `mypy `_
-or `Black `_) should also be developed outside
+General-use tools and libraries (for example, `mypy `__
+or `Black `__) should also be developed outside
the ``python`` organization, unless core devs (as represented by the SC)
specifically want to “bless” one implementation (as with
-`typeshed `_,
-`tzdata `_, or
-`pythoncapi-compat `_).
+`typeshed `__,
+`tzdata `__, or
+`pythoncapi-compat `__).
Organization owner policy
@@ -267,13 +266,13 @@ at all levels including organization membership, team membership, access
control, and merge privileges on all repositories. For full details of the
permission levels see `GitHub's documentation on Organization permission
levels
-`_.
+`__.
This role is paramount to the security of the Python Language, Community, and
Infrastructure.
The Executive Director of the Python Software Foundation delegates authority on
-GitHub Organization Owner Status to Ee Durbin - Python Software
-Foundation Director of Infrastructure. Common reasons for this role are:
+GitHub Organization Owner Status to Jacob Coffee - Python Software
+Foundation Infrastructure Engineer. Common reasons for this role are:
Infrastructure Staff Membership, Python Software Foundation General Counsel,
and Python Software Foundation Staff as fallback.
@@ -297,7 +296,7 @@ Current owners
+----------------------+--------------------------------+-----------------+
| Donald Stufft | Infrastructure Staff | dstufft |
+----------------------+--------------------------------+-----------------+
-| Ee Durbin | PSF Director of Infrastructure | ewdurbin |
+| Ee Durbin | Infrastructure Staff | ewdurbin |
+----------------------+--------------------------------+-----------------+
| Jacob Coffee | PSF Infrastructure Engineer | JacobCoffee |
+----------------------+--------------------------------+-----------------+
@@ -318,13 +317,13 @@ The Administrator role on the repository allows for managing all aspects
including collaborators, access control, integrations, webhooks, and branch
protection. For full details of the permission levels see `GitHub's
documentation on repository permission levels
-`_.
-Common reasons for this role are: maintenance of Core Developer
-Workflow tooling, Release Managers for all :ref:`in-development `,
+`__.
+Common reasons for this role are: maintenance of core
+workflow tooling, Release Managers for all :ref:`in-development `,
:ref:`maintenance `, and :ref:`security mode `
-releases, and additional Python Core Developers as necessary for redundancy.
-Occasional temporary administrator access is acceptable as necessary for Core
-Developer workflow projects.
+releases, and additional Python core team members as necessary for redundancy.
+Occasional temporary administrator access is acceptable as necessary for core
+workflow projects.
Inactive or unreachable members may be removed with or without notice. Members
who no longer necessitate this level of access will be removed with notice.
@@ -335,27 +334,28 @@ Administrator of the repository.
Current administrators
^^^^^^^^^^^^^^^^^^^^^^
-+-------------------+----------------------------------------------------------+-----------------+
-| Name | Role | GitHub Username |
-+===================+==========================================================+=================+
-| Hugo van Kemenade | Python 3.14 and 3.15 Release Manager | hugovk |
-+-------------------+----------------------------------------------------------+-----------------+
-| Thomas Wouters | Python 3.12 and 3.13 Release Manager | Yhg1s |
-+-------------------+----------------------------------------------------------+-----------------+
-| Pablo Galindo | Python 3.10 and 3.11 Release Manager, | pablogsal |
-| | Maintainer of buildbot.python.org | |
-+-------------------+----------------------------------------------------------+-----------------+
-| Łukasz Langa | Python 3.9 Release Manager, | ambv |
-| | PSF CPython Developer in Residence 2021-present | |
-+-------------------+----------------------------------------------------------+-----------------+
-| Brett Cannon | | brettcannon |
-+-------------------+----------------------------------------------------------+-----------------+
-| Ezio Melotti | Maintainer of bugs.python.org GitHub webhook integration | ezio-melotti |
-+-------------------+----------------------------------------------------------+-----------------+
-| Mariatta Wijaya | Maintainer of bedevere, blurb_it and miss-islington | Mariatta |
-+-------------------+----------------------------------------------------------+-----------------+
-| Seth Larson | PSF Security Developer-in-Residence | sethmlarson |
-+-------------------+----------------------------------------------------------+-----------------+
++--------------------+----------------------------------------------------------+-------------------+
+| Name | Role | GitHub Username |
++====================+==========================================================+===================+
+| Savannah Ostrowski | Python 3.16 and 3.17 Release Manager | savannahostrowski |
++--------------------+----------------------------------------------------------+-------------------+
+| Hugo van Kemenade | Python 3.14 and 3.15 Release Manager | hugovk |
++--------------------+----------------------------------------------------------+-------------------+
+| Thomas Wouters | Python 3.12 and 3.13 Release Manager | Yhg1s |
++--------------------+----------------------------------------------------------+-------------------+
+| Pablo Galindo | Python 3.10 and 3.11 Release Manager, | pablogsal |
+| | Maintainer of buildbot.python.org | |
++--------------------+----------------------------------------------------------+-------------------+
+| Łukasz Langa | PSF CPython Developer in Residence 2021-present | ambv |
++--------------------+----------------------------------------------------------+-------------------+
+| Brett Cannon | | brettcannon |
++--------------------+----------------------------------------------------------+-------------------+
+| Ezio Melotti | Maintainer of bugs.python.org GitHub webhook integration | ezio-melotti |
++--------------------+----------------------------------------------------------+-------------------+
+| Mariatta Wijaya | Maintainer of bedevere, blurb_it and miss-islington | Mariatta |
++--------------------+----------------------------------------------------------+-------------------+
+| Seth Larson | PSF Security Developer-in-Residence | sethmlarson |
++--------------------+----------------------------------------------------------+-------------------+
Repository release manager role policy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/developer-workflow/extension-modules.rst b/developer-workflow/extension-modules.rst
index 61c1ff08af..4d8c0ffca1 100644
--- a/developer-workflow/extension-modules.rst
+++ b/developer-workflow/extension-modules.rst
@@ -547,21 +547,24 @@ Now that the configuration is in place, it remains to compile the project:
.. tip::
- Use ``make -j`` to speed-up compilation by utilizing as many CPU cores
- as possible or ``make -jN`` to allow at most *N* concurrent jobs.
+ Use ``make -jN`` to speed-up compilation by utilizing as many CPU cores
+ as possible, where *N* is as many CPU cores you want to spare (and have
+ memory for). Be careful using ``make -j`` with no argument, as this puts
+ no limit on the number of jobs, and compilation can sometimes use up a
+ lot of memory (like when building with LTO).
* ``make regen-configure`` updates the :cpy-file:`configure` script.
- The :cpy-file:`configure` script must be generated using a specific version
- of ``autoconf``. To that end, the :cpy-file:`Tools/build/regen-configure.sh`
- script which the ``regen-configure`` rule is based on either requires Docker
- or Podman, the latter being assumed by default.
+ The :cpy-file:`configure` script must be generated using a specific version
+ of ``autoconf``. To that end, the :cpy-file:`Tools/build/regen-configure.sh`
+ script which the ``regen-configure`` rule is based on either requires Docker
+ or Podman, the latter being assumed by default.
- .. tip::
+ .. tip::
- We recommend installing `Podman `_
- instead of Docker since the former does not require a background service
- and avoids creating files owned by the ``root`` user in some cases.
+ We recommend installing `Podman `__
+ instead of Docker since the former does not require a background service
+ and avoids creating files owned by the ``root`` user in some cases.
* ``make regen-all`` is responsible for regenerating header files and
invoking other scripts, such as :ref:`Argument Clinic `.
@@ -571,7 +574,7 @@ Now that the configuration is in place, it remains to compile the project:
:mod:`!_foo` discoverable and importable via ``import _foo``.
* The final ``make`` step is generally not needed since the previous ``make``
- invokations may completely rebuild the project, but it could be needed in
+ invocations may completely rebuild the project, but it could be needed in
some specific cases.
Troubleshooting
@@ -606,8 +609,8 @@ by executing :cpy-file:`Tools/build/regen-configure.sh`:
If Docker complains about missing permissions, this Stack Overflow post
could be useful in solving the issue: `How to fix docker: permission denied
-`_. Alternatively, you may try
-using `Podman `_.
+`__. Alternatively, you may try
+using `Podman `__.
Missing ``Py_BUILD_CORE`` define when using internal headers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/developer-workflow/grammar.rst b/developer-workflow/grammar.rst
index d574dfed7d..bd314c61e3 100644
--- a/developer-workflow/grammar.rst
+++ b/developer-workflow/grammar.rst
@@ -5,4 +5,4 @@ Changing CPython's grammar
==========================
This document is now part of the
-`CPython Internals Docs `_.
+`CPython Internals Docs `__.
diff --git a/developer-workflow/index.rst b/developer-workflow/index.rst
index e73927f1dd..9919398e62 100644
--- a/developer-workflow/index.rst
+++ b/developer-workflow/index.rst
@@ -8,11 +8,11 @@ Development workflow
:maxdepth: 5
communication-channels
+ lang-changes
development-cycle
stdlib
extension-modules
c-api
- lang-changes
grammar
porting
sbom
diff --git a/developer-workflow/lang-changes.rst b/developer-workflow/lang-changes.rst
index 52aabb15dd..0b2c613fa7 100644
--- a/developer-workflow/lang-changes.rst
+++ b/developer-workflow/lang-changes.rst
@@ -1,37 +1,43 @@
.. _lang-changes:
.. _langchanges:
-Changing the Python language
-============================
-On occasion people come up with an idea on how to change or improve Python as a
-programming language. This document is meant to explain exactly what changes
-have a reasonable chance of being considered and what the process is to propose
-changes to the language.
+Changing Python
+===============
+On occasion people come up with an idea for changing or improving the Python
+language or standard library.
+This page explains how to propose changes and what to expect during the
+process.
-What qualifies
+
+Considerations
--------------
-First and foremost, it must be understood that changes to the Python
-programming language are difficult to make. When the language changes,
-**every** Python programmer already in existence and all Python programmers to
+
+First, understand that changes to Python
+are difficult to make. When the language changes,
+**every** Python programmer and all Python programmers to
come will end up eventually learning about the change you want to propose.
Books will need updating, code will be changed, and a new way to do things will
-need to be learned. Changes to the Python programming language are never taken
+need to be learned. Changes to Python are never taken
lightly.
-Because of the seriousness that language changes carry, any change must be
-beneficial to a large proportion of Python users. If the change only benefits a
-small percentage of Python developers then the change will not be made. A good
-way to see if your idea would work for a large portion of the Python community
-is to ask in the `Ideas Discourse category`_. You can also
-go through Python's stdlib and find examples of code which would benefit from
-your proposed change (which helps communicate the usefulness of your change to
-others). For further guidance, see :ref:`suggesting-changes`.
+Backward compatibility is a significant concern. Existing Python code has to
+continue to work. There are exceptions to this rule, but they are very rare
+and are only allowed when the benefits of the change greatly outweigh the costs
+of breaking existing code.
-Your proposed change also needs to be *Pythonic*. While only the Steering
-Council can truly classify something as Pythonic, you can read the
-:pep:`Zen of Python <20>` for guidance.
+Because of the seriousness of changing the language, any change must be
+beneficial to many Python users. If the change only helps a small percentage of
+Python developers then the change will not be made. A good way to see if your
+idea would work for a large portion of the Python community is to discuss it in
+the `Ideas category in Discourse `_. You can also look in Python's standard
+library to find examples of code which would benefit from your proposed change.
+.. important::
+ For all of these reasons, most proposed changes to Python are rejected. This
+ doesn't mean you shouldn't suggest them. It can be useful to explore
+ alternatives and to get feedback from the community. Just be aware that
+ getting a change accepted is difficult. Don't take it personally.
.. index::
single: PEP process
@@ -41,25 +47,107 @@ Council can truly classify something as Pythonic, you can read the
Suggesting new features and language changes
--------------------------------------------
-The `Ideas Discourse category`_
-is specifically intended for discussion of new features and language changes.
-Please don't be disappointed if your idea isn't met with universal approval:
-as the :pep:`long list of Withdrawn and Rejected PEPs
-<0#rejected-superseded-and-withdrawn-peps>`
-in the :pep:`PEP Index <0>` attests,
-and as befits a reasonably mature programming language,
-getting significant changes into Python isn't a simple task.
+Proposing a change involves the following steps:
+
+- Describe your idea in detail.
+
+- Engage in discussion about the idea.
+
+- Rarely, the idea will advance to a formal proposal stage.
+
+
+Describe your idea
+^^^^^^^^^^^^^^^^^^
+
+The `Ideas category in Discourse `_ is specifically intended for discussion
+of new features and language changes. Make your proposal as a `new topic
+`_ there.
+
+Your proposal needs to be **detailed**. Describe the change you want to make,
+why you want to make it, and what benefits it will bring to Python users. Be
+specific. Show that you have considered the effect of the change on existing
+code.
+
+Some things you should **not** do:
+
+- **Don't** format your idea as a Python Enhancement Proposal (PEP).
+ It's good to use the PEP template as a guide for what information to include,
+ but don't try to write a full PEP until the idea has been accepted for
+ further consideration.
+
+- **Don't** create a list of proposed changes. Each idea needs its own
+ discussion. Proposing a change is significant work. You will need to spend
+ time on each proposal. A tossed-off list will not be taken seriously.
+
+When justifying your idea, these are **not good reasons** to make a change:
+
+- "Other languages work this way." Languages are different. What works well
+ in one language may not work well in Python, or Python may already have a
+ way to do a similar thing.
+
+- "It would be nice." This is too vague. Be specific about the benefits
+ your change will bring, and consider the costs as well.
+
+Some things you **should** do:
+
+- Research whether your idea has been proposed before. There are many
+ suggestions that have been made and rejected in the past. If your idea has a
+ history, read the discussion to see why it was rejected. Previously rejected
+ ideas are especially unlikely to get accepted. If you can address the
+ concerns raised in the previous discussion, mention that in your proposal.
+
+- Read other ideas to see how they are presented. This will help you flesh out
+ your proposal.
+
+- Read other ideas to understand the kinds of concerns that are raised and
+ objections that must be answered. Your proposal will be stronger if you can
+ address these concerns up front.
+
+- Provide enough detail to fully explain your idea, and to show that you have
+ considered all the implications of the change. Strike the right balance
+ between brevity and completeness. A shorter proposal will be easier to
+ discuss, so long as it includes all the necessary information.
+
+
+Engage in discussion
+^^^^^^^^^^^^^^^^^^^^
+
+Once you post your proposal, people will respond. You need to continue
+the discussion, answer questions, and address objections. This is an important
+part of the process. Other people's perspectives will help explore the full
+impact of the idea and find strengths or weaknesses you may not have
+considered.
+
+You will almost always get at least some push-back. Don't be disappointed,
+and don't take it personally.
+As the long list of :pep:`Withdrawn and Rejected PEPs
+<0#rejected-superseded-and-withdrawn-peps>` in the :pep:`PEP Index <0>`
+attests, and as befits a mature programming language, getting significant
+changes into Python isn't a simple task.
+
+Engage in good faith. The goal of the discussion is to find the best balance
+between competing concerns. If your idea has merit, the discussion will help
+refine it and make it stronger. If your idea has flaws, the discussion will
+help identify them so you can address them or move on. Keep the discussion
+productive and focused on the issues, not on personalities.
+
+It is especially useful to discuss with core team members since
+they know the language and design considerations well.
+If your proposal makes it to the PEP stage,
+you'll need a core team member as a sponsor.
+Sometimes they will differ in opinion, or merely be unconvinced. When there
+isn't a clear positive sentiment, the `Status Quo Wins a Stalemate`_.
+
+Even if your idea is not accepted, the discussion can help you and others
+understand the design of Python better, and help inform future proposals.
-If the idea is reasonable, someone will suggest posting it as a feature
-request on the `issue tracker`_, or, for larger changes,
-writing it up as PEP following the :ref:`lang-changes-pep-process`.
-Sometimes core developers will differ in opinion,
-or merely be collectively unconvinced.
-When there isn't an obvious victor, then the `Status Quo Wins a Stalemate`_.
+Formal proposal
+^^^^^^^^^^^^^^^
-For some examples on language changes that were accepted,
-see `Justifying Python Language Changes`_.
+If the idea gets positive discussion, someone will suggest posting it as a
+feature request on the `issue tracker`_, or, for larger changes, writing it up
+as PEP following the :ref:`lang-changes-pep-process`. Congratulations!
.. index:: PEP process
@@ -69,20 +157,20 @@ see `Justifying Python Language Changes`_.
PEP process
-----------
-Once you are certain you have a language change proposal
-which will appeal to the general Python community,
-you can begin the :abbr:`PEP (Python enhancement proposal)` process
-to officially propose the change.
-See :pep:`1` for information on PEPs and the PEP process,
-and the :pep:`PEP Index <0>` for examples.
+Once you have a proposal which will appeal to
+the general Python community, you can begin the PEP
+process to officially propose the change.
+This starts with finding a sponsor from the core team.
+See :pep:`1` for
+information on PEPs and the PEP process, and the :pep:`PEP Index <0>` for
+examples.
-If the PEP is accepted, then your proposed language change will be introduced
-in the next release of Python.
-Otherwise, your PEP will be recorded as rejected along with an explanation,
-to inform others who may propose a similar language change in the future.
+If the PEP is accepted, then your language change will be introduced in a
+future release of Python. Otherwise, your PEP will be recorded as rejected
+along with an explanation, to inform others who may propose a similar language
+change in the future.
.. _issue tracker: https://github.com/python/cpython/issues
-.. _Ideas Discourse category: https://discuss.python.org/c/ideas/6
-.. _Status Quo Wins a Stalemate: https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
-.. _Justifying Python Language Changes: https://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html
+.. _ideas: https://discuss.python.org/c/ideas/6
+.. _Status Quo Wins a Stalemate: https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate/
diff --git a/developer-workflow/psrt-emeritus.csv b/developer-workflow/psrt-emeritus.csv
new file mode 100644
index 0000000000..f9d26bfba4
--- /dev/null
+++ b/developer-workflow/psrt-emeritus.csv
@@ -0,0 +1,10 @@
+Anthony Baxter,,Release Manager
+Christian Heimes,tiran,
+Georg Brandl,birkenfeld,
+Huzaifa Sidhpurwala,,
+Jesse Noller,,
+Kushal Das,kushaldas,
+Mark Hammond,mhammond,
+Nam Nguyen,,
+Neal Norwitz,,
+Trent Mick,,
diff --git a/developer-workflow/psrt.csv b/developer-workflow/psrt.csv
new file mode 100644
index 0000000000..81147eb29e
--- /dev/null
+++ b/developer-workflow/psrt.csv
@@ -0,0 +1,25 @@
+Barry Warsaw,warsaw,Admin
+Benjamin Peterson,benjaminp,
+Donald Stufft,dstufft,
+Dustin Ingram,di,
+Ee Durbin,ewdurbin,Admin
+Emma Smith,emmatyping,
+Glyph Lefkowitz,glyph,
+Gregory P. Smith,gpshead,
+Hugo van Kemenade,hugovk,Release Manager
+Jacob Coffee,JacobCoffee,
+Larry Hastings,larryhastings,
+Łukasz Langa,ambv,Release Manager
+Ned Deily,ned-deily,"Admin, Release Manager"
+Pablo Galindo Salgado,pablogsal,Release Manager
+Paul McMillan,paulmcmillan,
+Petr Viktorin,encukou,
+Pradyun Gedam,pradyunsg,
+Savannah Ostrowski,savannahostrowski,Release Manager
+Serhiy Storchaka,serhiy-storchaka,
+Seth Larson,sethmlarson,Admin
+Stan Ulbrych,StanFromIreland,
+Steve Dower,zooba,Release Manager
+Thomas Wouters,Yhg1s,Release Manager
+Tim Peters,tim-one,
+William Woodruff,woodruffw,
diff --git a/developer-workflow/psrt.rst b/developer-workflow/psrt.rst
index f469f68d12..dee901726e 100644
--- a/developer-workflow/psrt.rst
+++ b/developer-workflow/psrt.rst
@@ -4,6 +4,84 @@ Python Security Response Team (PSRT)
The Python Security Response Team (PSRT) is responsible for handling
vulnerability reports for CPython and pip.
+Members
+-------
+
+The PSRT publishes a full
+list of members and admins, included in the table below:
+
+.. csv-table::
+ :header: "Name", "GitHub username", "Notes"
+ :file: psrt.csv
+ :encoding: "utf-8"
+
+See also the :ref:`members emeritus list `.
+
+How can I join the PSRT?
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Anyone can join the PSRT following a nomination process
+`similar to core team nominations`_. Nomination for a new member
+is brought to the PSRT by an existing PSRT member and then
+this nomination is voted on by existing PSRT members.
+The nomination succeeds if the nomination receives at least
+two-thirds positive votes from a vote of existing PSRT members
+that is open for one week and not vetoed by the Steering Council.
+
+Once per year the Steering Council will receive a report of inactive members
+of the PSRT with the recommendation to remove the inactive users from the PSRT.
+“Inactive” is defined as a member who hasn’t coordinated or commented on a
+vulnerability report in the past year since the last report was generated.
+The Steering Council may remove members of the PSRT with a simple vote.
+
+Members of the PSRT who are a Release Manager or Steering Council member may
+remain in the PSRT regardless of inactivity in vulnerability reports.
+
+.. _similar to core team nominations: https://devguide.python.org/core-team/join-team/
+
+Responsibilities of PSRT members
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Below are the responsibilities of PSRT members:
+
+* Being knowledgeable about typical software vulnerability report handling
+ processes, such as CVE IDs, patches, coordinated disclosure, embargoes.
+* Not sharing or acting on embargoed information about the reported
+ vulnerability. Examples of disallowed behavior include sharing information
+ with colleagues or publicly deploying unpublished mitigations or patches ahead
+ of the advisory publication date.
+* Acting as a “Coordinator” of vulnerability reports that are submitted to
+ projects. A Coordinator’s responsibility is to move a report through the PSRT
+ process to a “finished” state, either rejected or as a published advisory and
+ mitigation, within the industry standard timeline of 90 days.
+* As a Coordinator, involving relevant core team members or triagers where
+ necessary to make a determination whether a report is a vulnerability and
+ developing a patch. Coordinators are encouraged to involve members of the core
+ team to make the best decision for each report rather than working in isolation.
+* As a Coordinator, calculating the severity using CVSS and authoring advisories
+ to be shared on `security-announce@python.org`_. These advisories are used for
+ CVE records by the `PSF CVE Numbering Authority`_.
+* Coordinators that can no longer move a report forwards for any reason must
+ delegate their Coordinator role to someone else in the PSRT.
+
+.. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/
+.. _PSF CVE Numbering Authority: https://www.python.org/cve-numbering-authority/
+
+Responsibilities of PSRT admins
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+PSRT members who are designated as admins by the Steering Council have the
+following additional responsibilities:
+
+* Triaging the ``security@python.org`` mailing list.
+* Managing PSRT membership access including the GitHub team, the mailing list,
+ and Discord channel, to ensure they are synchronized with the canonical list
+ of PSRT members.
+* On a yearly basis, providing the Steering Council with a report including a
+ list of inactive PSRT members.
+* Running nomination elections, including counting final votes and giving
+ the Steering Council an opportunity to veto nominations via email.
+
Vulnerability report triage
---------------------------
@@ -31,7 +109,7 @@ If a coordinator can't complete the process for any reason (time obligation,
vacation, etc.) they must find a replacement coordinator in the PSRT
and reassign the vulnerability report appropriately.
-Coordinators are expected to collaborate with other PSRT members and core developers
+Coordinators are expected to collaborate with other PSRT and core team members
when needed for guidance on whether the report is an actual vulnerability,
severity, advisory text, and fixes.
@@ -74,7 +152,7 @@ severity, advisory text, and fixes.
* The coordinator determines the fix approach and who will provide a fix.
Some reporters are willing to provide or collaborate to create a fix,
- otherwise relevant core developers can be invited to collaborate by
+ otherwise relevant core team members can be invited to collaborate by
the coordinator.
* For **Low** and **Medium** severity vulnerabilities it is acceptable
@@ -84,7 +162,7 @@ severity, advisory text, and fixes.
* For **High** and **Critical** severity vulnerabilities the fix must be
developed privately using GitHub Security Advisories' "Private Forks" feature.
- Core developers can be added to the GitHub Security Advisory via "collaborators"
+ Core team members can be added to the GitHub Security Advisory via "collaborators"
to work on the fix together. Once a fix is approved privately and tested,
a public issue and pull request can be created with
the ``security`` and ``release-blocker`` labels.
@@ -93,6 +171,40 @@ severity, advisory text, and fixes.
to ``security-announce@python.org`` using the below template. Backport labels must be added as appropriate.
After the advisory is published a CVE record can be created.
+Handling code signing certificate reports
+-----------------------------------------
+
+Python signs binaries using Azure Trusted Signing and Apple Developer ID
+certificates. If a code signing certificate is reported as "compromised" or
+"malware signed with certificate", the Python Security Response Team must
+request the following information from the reporter:
+
+* Checksum(s) of binaries signed by certificate.
+* Signature(s) of binaries signed by certificate.
+
+To avoid unnecessary user confusion and churn around revoking code signing
+certificates, any reports **must be verifiable independently by the PSRT before
+taking destructive actions**, such as revoking certificates. With this
+information the PSRT can take investigative steps to verify the report, such as:
+
+* Downloading and checking artifacts from the associated Azure Pipelines
+ executions against the reported list of checksums.
+* Verifying the validity of the signatures. `Past reports
+ `__ have contained signatures that
+ purported to be from Python code signing certificates, but were not valid.
+* Checking the Azure Pipelines and Azure Trusted Signing audit logs for signs of
+ compromise.
+
+If any signs of compromise or incorrectly signed binaries are discovered by the
+PSRT, only then will certificates be revoked and an advisory published.
+If compromise is reported, the following non-destructive actions can be taken by
+the PSRT without verifying the reported information as a precaution, if
+relevant:
+
+* Rotating secrets associated with code signing (``TrustedSigningSecret`` for
+ Azure Trusted Publishing).
+* Resetting passwords for accounts with access to signing certificates.
+
Template responses
------------------
@@ -158,3 +270,15 @@ please feel free to adapt them as needed for the current context.
* https://www.cve.org/CVERecord?id={CVE-YYYY-XXXX}
* {pull request URL}
+
+.. _psrt-members-emeritus:
+
+Members emeritus
+----------------
+
+Members who have previously served on the PSRT.
+
+.. csv-table::
+ :header: "Name", "GitHub username", "Notes"
+ :file: psrt-emeritus.csv
+ :encoding: "utf-8"
diff --git a/developer-workflow/sbom.rst b/developer-workflow/sbom.rst
index 756c175708..c8a2facd14 100644
--- a/developer-workflow/sbom.rst
+++ b/developer-workflow/sbom.rst
@@ -5,15 +5,15 @@ Software Bill-of-Materials (abbreviated as "SBOM") is a document for sharing
information about software and how it's been composed. This format is used
most often in the security space for checking software and its dependencies
for vulnerabilities using vulnerability databases like
-`CVE `_ and `OSV `_. The SBOM format
-that the CPython project uses is `SPDX `_
+`CVE `__ and `OSV `__. The SBOM format
+that the CPython project uses is `SPDX `__
which can be transformed into other formats if necessary by consumers.
There are multiple sources of third-party dependencies for CPython.
Some are vendored into the source code of CPython itself (like ``mpdecimal``
vendored at :cpy-file:`Modules/_decimal/libmpdec`) or they could be optionally pulled
in during builds like Windows using dependencies from the
-`python/cpython-source-deps `_
+`python/cpython-source-deps `__
repository.
Whenever adding or updating a third-party dependency, an update will likely
@@ -51,10 +51,10 @@ Adding a new dependency
When adding a dependency it's important to have the following information:
* Name, version, and download URL of the project
-* License of the project as an `SPDX License Expression `_
+* License of the project as an `SPDX License Expression `__
* Software identifiers that match values in vulnerability databases
- (`CPE `_ and
- `Package URLs `_
+ (`CPE `__ and
+ `Package URLs `__
or "PURLs")
* Paths to include and exclude in the CPython source tree corresponding to this dependency
diff --git a/developer-workflow/stdlib.rst b/developer-workflow/stdlib.rst
index 60112d6d3e..b683e55e96 100644
--- a/developer-workflow/stdlib.rst
+++ b/developer-workflow/stdlib.rst
@@ -28,7 +28,7 @@ You have a several options for this:
* Search the `issue tracker`_ for discussion related to the proposed addition.
This may turn up an issue that explains why the suggestion wasn't accepted.
* Open a new thread in the `Ideas Discourse category`_
- to gather feedback directly from the Python core developers and community.
+ to gather feedback directly from the Python core team and community.
* Write a blog post about the code, which may also help gather useful feedback.
If you have found general acceptance and usefulness for your code from people,
@@ -36,9 +36,9 @@ you can open an issue on the `issue tracker`_ with the code attached as a
:ref:`pull request `. If possible, also submit a
:ref:`contributor agreement `.
-If a core developer decides that your code would be useful to the general
+If a core team member decides that your code would be useful to the general
Python community, they will then commit your code. If your code is not picked
-up by a core developer and committed then please do not take this personally.
+up by a core team and committed then please do not take this personally.
Through your public sharing of your code in order to gauge community support
for it you at least can know that others will come across it who may find it
useful.
@@ -51,8 +51,8 @@ Adding a new module
It must be stated upfront that getting a new module into the stdlib is very
difficult. Adding any significant amount of code to the stdlib increases the
-burden placed upon core developers. It also means that the module somewhat
-becomes "sanctioned" by the core developers as a good way to do something,
+burden placed upon the core team. It also means that the module somewhat
+becomes "sanctioned" by the core team as a good way to do something,
typically leading to the rest of the Python community to using the new module
over other available solutions. All of this means that additions to the stdlib
are not taken lightly.
@@ -76,7 +76,7 @@ that the stdlib consists of.
While a new stdlib module does not need to appeal to all users of Python, it
should be something that a large portion of the community will find useful.
-This makes sure that the developer burden placed upon core developers is worth
+This makes sure that the developer burden placed upon the core team is worth
it.
@@ -108,12 +108,12 @@ infrastructure (that is, the module is no longer directly maintained outside of
Python). This prevents a divergence between the code that is included in the
stdlib and that which is released outside the stdlib (typically done to provide
the module to older versions of Python). It also removes the burden of forcing
-core developers to have to redirect bug reports or changes to an external issue
+the core team to have to redirect bug reports or changes to an external issue
tracker and :abbr:`VCS (version control system)`.
Someone involved with the development of the
module must promise to help maintain the module in the stdlib for two years.
-This not only helps out other core developers by alleviating workload from bug
+This not only helps out other core team members by alleviating workload from bug
reports that arrive from the first Python release containing the module, but
also helps to make sure that the overall design of the module continues to be
uniform.
diff --git a/development-tools/clang.rst b/development-tools/clang.rst
index f06834731a..149fb7adcf 100644
--- a/development-tools/clang.rst
+++ b/development-tools/clang.rst
@@ -11,7 +11,7 @@ libraries.
This document does not cover interpreting the findings. For a discussion of
interpreting results, see Marshall Clow's `Testing libc++ with
--fsanitize=undefined `_. The
+-fsanitize=undefined `__. The
blog posting is a detailed examinations of issues uncovered by Clang in
``libc++``.
@@ -45,7 +45,7 @@ flags are passed through ``CFLAGS`` and ``CXXFLAGS``, and sometimes through
``CC`` and ``CXX`` (in addition to the compiler).
A complete list of sanitizers can be found at `Controlling Code Generation
-`_.
+`__.
.. note::
@@ -70,7 +70,7 @@ Pre-built Clang builds are available for most platforms:
includes the "C++ clang tools for windows" feature.
You can also build ``clang`` from source; refer to
-`the clang documentation `_ for details.
+`the clang documentation `__ for details.
The installer does not install all the components needed on occasion. For
example, you might want to run a ``scan-build`` or examine the results with
@@ -103,6 +103,10 @@ Then, run ``./configure`` with the relevant flags:
* ASan: ``--with-address-sanitizer --without-pymalloc``
* UBsan: ``--with-undefined-behavior-sanitizer``
+The ``--without-pymalloc`` option is not necessary (tests should pass without it),
+but disabling pymalloc helps ASan uncover more bugs (ASan does not track
+individual allocations done by pymalloc).
+
It is OK to specify both sanitizers.
After that, run ``make`` and ``make test`` as usual.
@@ -280,6 +284,6 @@ Or, you could ignore the entire file with::
Unfortunately, you won't know what to ignorelist until you run the sanitizer.
The documentation is available at `Sanitizer special case list
-`_.
+`__.
.. _Valgrind: https://github.com/python/cpython/blob/main/Misc/README.valgrind
diff --git a/development-tools/clinic.rst b/development-tools/clinic/howto.rst
similarity index 71%
rename from development-tools/clinic.rst
rename to development-tools/clinic/howto.rst
index 642f40dce9..359c53e903 100644
--- a/development-tools/clinic.rst
+++ b/development-tools/clinic/howto.rst
@@ -1,677 +1,3 @@
-.. highlight:: c
-
-.. _clinic:
-
-***************
-Argument Clinic
-***************
-
-:author: Larry Hastings
-
-**Source code:** :cpy-file:`Tools/clinic/clinic.py`.
-
-Argument Clinic is a preprocessor for CPython C files.
-It was introduced in Python 3.4 with :pep:`436`,
-in order to provide introspection signatures,
-and to generate performant and tailor-made boilerplate code
-for argument parsing in CPython builtins, module level functions, and class methods.
-This document is divided in four major sections:
-
-* :ref:`clinic-background` talks about the basic concepts and goals of Argument Clinic.
-* :ref:`clinic-reference` describes the command-line interface and Argument Clinic terminology.
-* :ref:`clinic-tutorial` guides you through all the steps required to adapt an existing C function to Argument Clinic.
-* :ref:`clinic-howtos` details how to handle specific tasks.
-
-
-.. note::
-
- Argument Clinic is considered internal-only
- for CPython. Its use is not supported for files outside
- CPython, and no guarantees are made regarding backwards
- compatibility for future versions. In other words: if you
- maintain an external C extension for CPython, you're welcome
- to experiment with Argument Clinic in your own code. But the
- version of Argument Clinic that ships with the next version
- of CPython *could* be totally incompatible and break all your code.
-
-
-.. _clinic-background:
-
-Background
-==========
-
-Basic concepts
---------------
-
-When Argument Clinic is run on a file, either via the :ref:`clinic-cli`
-or via ``make clinic``, it will scan over the input files looking for
-:term:`start lines `:
-
-.. code-block:: none
-
- /*[clinic input]
-
-When it finds one, it reads everything up to the :term:`end line`:
-
-.. code-block:: none
-
- [clinic start generated code]*/
-
-Everything in between these two lines is Argument Clinic :term:`input`.
-When Argument Clinic parses input, it generates :term:`output`.
-The output is rewritten into the C file immediately after the input,
-followed by a :term:`checksum line`.
-All of these lines, including the :term:`start line` and :term:`checksum line`,
-are collectively called an Argument Clinic :term:`block`:
-
-.. code-block:: none
-
- /*[clinic input]
- ... clinic input goes here ...
- [clinic start generated code]*/
- ... clinic output goes here ...
- /*[clinic end generated code: ...]*/
-
-If you run Argument Clinic on the same file a second time, Argument Clinic
-will discard the old :term:`output` and write out the new output with a fresh
-:term:`checksum line`.
-If the :term:`input` hasn't changed, the output won't change either.
-
-.. note::
-
- You should never modify the output of an Argument Clinic block,
- as any change will be lost in future Argument Clinic runs;
- Argument Clinic will detect an output checksum mismatch and regenerate the
- correct output.
- If you are not happy with the generated output,
- you should instead change the input until it produces the output you want.
-
-
-.. _clinic-reference:
-
-Reference
-=========
-
-
-.. _clinic-terminology:
-
-Terminology
------------
-
-.. glossary::
-
- start line
- The line ``/*[clinic input]``.
- This line marks the beginning of Argument Clinic input.
- Note that the *start line* opens a C block comment.
-
- end line
- The line ``[clinic start generated code]*/``.
- The *end line* marks the _end_ of Argument Clinic :term:`input`,
- but at the same time marks the _start_ of Argument Clinic :term:`output`,
- thus the text *"clinic start start generated code"*
- Note that the *end line* closes the C block comment opened
- by the *start line*.
-
- checksum
- A hash to distinguish unique :term:`inputs `
- and :term:`outputs