Merge branch 'main' into pep824-coalescing-operators

Author: hugovk

.github/CODEOWNERS

@@ -50,7 +50,7 @@ peps/pep-0020.rst  @tim-one
 peps/pep-0042.rst  @jeremyhylton
 # ...
 peps/pep-0100.rst  @malemburg
-peps/pep-0101.rst  @hugovk @Yhg1s @pablogsal @ambv @ned-deily
+peps/pep-0101.rst  @savannahostrowski @hugovk @Yhg1s @pablogsal @ambv @ned-deily
 peps/pep-0102.rst  @warsaw @gvanrossum
 # peps/pep-0103.rst
 # ...
@@ -656,7 +656,6 @@ peps/pep-0775.rst  @encukou
 peps/pep-0776.rst  @hoodmane @ambv
 peps/pep-0777.rst  @warsaw @emmatyping
 peps/pep-0778.rst  @warsaw @emmatyping
-# ...
 peps/pep-0779.rst  @Yhg1s @colesbury @mpage
 peps/pep-0780.rst  @lysnikolaou
 peps/pep-0781.rst  @methane
@@ -688,18 +687,22 @@ peps/pep-0808.rst  @FFY00
 peps/pep-0809.rst  @zooba
 peps/pep-0810.rst  @pablogsal @DinoV @Yhg1s
 peps/pep-0811.rst  @sethmlarson @gpshead
-# ...
+peps/pep-0813.rst  @warsaw @ericvsmith
 peps/pep-0814.rst  @vstinner @corona10
 peps/pep-0815.rst  @emmatyping
 peps/pep-0816.rst  @brettcannon
 peps/pep-0817.rst  @warsaw @dstufft
 peps/pep-0817/     @warsaw @dstufft
-# ...
+peps/pep-0818.rst  @hoodmane @ambv
 peps/pep-0819.rst  @emmatyping
 peps/pep-0820.rst  @encukou
 peps/pep-0821.rst  @JelleZijlstra
 peps/pep-0822.rst  @methane
+# ...
 peps/pep-0824.rst  @gvanrossum
+peps/pep-0825.rst  @warsaw @dstufft
+peps/pep-0826.rst  @savannahostrowski
+peps/pep-0827.rst  @1st1
 # ...
 peps/pep-2026.rst  @hugovk
 # ...

.github/PULL_REQUEST_TEMPLATE/Add a new PEP.md

@@ -29,14 +29,17 @@ If your PEP is not Standards Track, remove the corresponding section.
 * [ ] PEP topic [discussed in a suitable venue](https://peps.python.org/pep-0001/#start-with-an-idea-for-python) with general agreement that a PEP is appropriate
 * [ ] [Suggested sections](https://peps.python.org/pep-0012/#suggested-sections) included (unless not applicable)
     * [ ] Motivation
-    * [ ] Rationale
     * [ ] Specification
+    * [ ] Rationale
     * [ ] Backwards Compatibility
     * [ ] Security Implications
     * [ ] How to Teach This
     * [ ] Reference Implementation
     * [ ] Rejected Ideas
     * [ ] Open Issues
+    * [ ] Acknowledgements
+    * [ ] Footnotes
+    * [ ] Change History
 * [ ] ``Python-Version`` set to valid (pre-beta) future Python version, if relevant
 * [ ] Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
 * [ ] Right before or after initial merging, [PEP discussion thread](https://peps.python.org/pep-0001/#discussing-a-pep) created and linked to in ``Discussions-To`` and ``Post-History``

pep_sphinx_extensions/pep_theme/static/style.css

@@ -236,7 +236,6 @@ div.table-wrapper {
 table {
     width: 100%;
     border-collapse: collapse;
-    border: 1px solid var(--colour-background-accent-strong);
 }
 table caption {
     margin: 1rem 0 .75rem;
@@ -245,22 +244,16 @@ table thead tr {
     background-color: var(--colour-background-accent-medium);
     color: var(--colour-text-strong);
 }
-table tbody tr {
-    border-top: 1px solid var(--colour-background-accent-strong);
-}
 table th,
 table td {
     text-align: left;
     padding: 0.25rem 0.5rem 0.2rem;
+    border: 1px solid var(--colour-background-accent-strong);
 }
 table.pep-zero-table tr td:nth-child(1),
 table.pep-zero-table tr td:nth-child(2) {
     white-space: nowrap;
 }
-table th + th,
-table td + td {
-    border-left: 1px solid var(--colour-background-accent-strong);
-}
 /* Common column widths for PEP status tables  */
 table.pep-zero-table tr td:nth-child(1) {
     width: 5%;

pep_sphinx_extensions/pep_zero_generator/writer.py

@@ -331,36 +331,25 @@ def _classify_peps(peps: list[PEP]) -> tuple[list[PEP], ...]:
 
 
 def _verify_email_addresses(peps: list[PEP]) -> dict[str, str]:
-    authors_dict: dict[str, set[str]] = {}
+    authors_dict: dict[str, list[str]] = {}
     for pep in peps:
         for author in pep.authors:
             # If this is the first time we have come across an author, add them.
             if author.full_name not in authors_dict:
-                authors_dict[author.full_name] = set()
+                authors_dict[author.full_name] = []
 
             # If the new email is an empty string, move on.
             if not author.email:
                 continue
             # If the email has not been seen, add it to the list.
-            authors_dict[author.full_name].add(author.email)
-
-    valid_authors_dict: dict[str, str] = {}
-    too_many_emails: list[tuple[str, set[str]]] = []
-    for full_name, emails in authors_dict.items():
-        if len(emails) > 1:
-            too_many_emails.append((full_name, emails))
-        else:
-            valid_authors_dict[full_name] = next(iter(emails), "")
-    if too_many_emails:
-        err_output = []
-        for author, emails in too_many_emails:
-            err_output.append(" " * 4 + f"{author}: {emails}")
-        raise ValueError(
-            "some authors have more than one email address listed:\n"
-            + "\n".join(err_output)
-        )
-
-    return valid_authors_dict
+            emails = authors_dict[author.full_name]
+            if author.email not in emails:
+                emails.append(author.email)
+
+    # Combine multiple email addresses with commas. Since peps is
+    # sorted by PEP number, this should produce a deterministic
+    # output.
+    return {name: ', '.join(emails) for name, emails in authors_dict.items()}
 
 
 def _sort_authors(authors_dict: dict[str, str]) -> list[str]:

pep_sphinx_extensions/tests/pep_zero_generator/test_writer.py

@@ -56,6 +56,23 @@ def test_verify_email_addresses(test_input, expected):
     assert out == expected
 
 
+def test_verify_email_addresses_multiple_emails():
+    # Arrange
+    peps = [
+        parser.PEP(Path("pep_sphinx_extensions/tests/peps/pep-9000.rst")),
+        parser.PEP(Path("pep_sphinx_extensions/tests/peps/pep-9003.rst")),
+    ]
+
+    # Act
+    out = writer._verify_email_addresses(peps)
+
+    # Assert: Francis has two emails combined, Javier's single email is not duplicated
+    assert out == {
+        "Francis Fussyreverend": "one@example.com, different@example.com",
+        "Javier Soulfulcommodore": "two@example.com",
+    }
+
+
 def test_sort_authors():
     # Arrange
     authors_dict = {

pep_sphinx_extensions/tests/peps/pep-9003.rst

@@ -0,0 +1,7 @@
+PEP: 9003
+Title: Test with author using a different email than in PEP 9000
+Author: Francis Fussyreverend <different@example.com>,
+        Javier Soulfulcommodore <two@example.com>
+Created: 20-Apr-2022
+Status: Draft
+Type: Process

peps/pep-0001.rst

@@ -509,7 +509,13 @@ Each PEP should have the following parts/sections:
    projects in the Python ecosystem.  PEP submissions without
    sufficient motivation may be rejected.
 
-4. Rationale -- The rationale fleshes out the specification by
+4. Specification -- The technical specification should describe the
+   syntax and semantics of any new language feature.  The
+   specification should be detailed enough to allow competing,
+   interoperable implementations for at least the current major Python
+   platforms (CPython, Jython, IronPython, PyPy).
+
+5. Rationale -- The rationale fleshes out the specification by
    describing why particular design decisions were made.  It should
    describe alternate designs that were considered and related work,
    e.g. how the feature is supported in other languages.
@@ -518,12 +524,6 @@ Each PEP should have the following parts/sections:
    community and discuss important objections or concerns raised
    during discussion.
 
-5. Specification -- The technical specification should describe the
-   syntax and semantics of any new language feature.  The
-   specification should be detailed enough to allow competing,
-   interoperable implementations for at least the current major Python
-   platforms (CPython, Jython, IronPython, PyPy).
-
 6. Backwards Compatibility -- All PEPs that introduce backwards
    incompatibilities must include a section describing these
    incompatibilities and their severity.  The PEP must explain how the
@@ -581,7 +581,18 @@ Each PEP should have the following parts/sections:
 13. Footnotes -- A collection of footnotes cited in the PEP, and
     a place to list non-inline hyperlink targets.
 
-14. Copyright/license -- Each new PEP must be placed under a dual license of
+Change History -- A summary of major changes the PEP has undergone, based on
+    discussions and feedback. Think of this as a "changelog" or "release notes"
+    for the PEP.  In general, whenever you update the ``Post-History`` header
+    for major changes, add a new bullet item in newest-first (i.e. reverse
+    chronological) order, using the same ``DD-MMM-YYYY`` format, with
+    sub-bullets summarizing the changes. You can consider linking this to the
+    same link as the ``Post-History`` link.  This isn't mandatory, so it's left
+    to the PEP author's discretion, but such a section can be helpful for those
+    following along to understand the evolution of your PEP.  Here is :pep:`an
+    example <694#change-history>`.
+
+15. Copyright/license -- Each new PEP must be placed under a dual license of
     public domain and CC0-1.0-Universal_ (see this PEP for an example).
 
 
@@ -876,6 +887,14 @@ Footnotes
 .. _Contributing Guide: https://github.com/python/peps/blob/main/CONTRIBUTING.rst
 
 
+Change History
+==============
+
+* 2026-02-02
+
+  * Added an optional ``Change History`` section for PEPs, for summarizing changes when updating the
+    ``Post-History`` header.
+
 Copyright
 =========
 

peps/pep-0012.rst

@@ -7,6 +7,8 @@ Status: Active
 Type: Process
 Created: 05-Aug-2002
 Post-History: `30-Aug-2002 <https://mail.python.org/archives/list/python-dev@python.org/thread/KX3AS7QAY26QH3WIUAEOCCNXQ4V2TGGV/>`__
+              `22-Feb-2026 <https://discuss.python.org/t/small-but-useful-change-to-pep-1-12/106250>`__
+
 
 
 .. highlight:: rst
@@ -32,13 +34,17 @@ The source for this (or any) PEP can be found in the
 as well as via a link at the bottom of each PEP.
 
 
-Rationale
-=========
+Specification
+=============
 
 If you intend to submit a PEP, you MUST use this template, in
 conjunction with the format guidelines below, to ensure that your PEP
 submission won't get automatically rejected because of form.
 
+
+Rationale
+=========
+
 ReStructuredText provides PEP authors with useful functionality and
 expressivity, while maintaining easy readability in the source text.
 The processed HTML form makes the functionality accessible to readers:
@@ -100,8 +106,8 @@ directions below.
   feature is described in a Final PEP.
 
 - Change the Created header to today's date.  Be sure to follow the
-  format carefully: it must be in ``dd-mmm-yyyy`` format, where the
-  ``mmm`` is the 3 English letter month abbreviation, i.e. one of Jan,
+  format carefully: it must be in ``DD-MMM-YYYY`` format, where the
+  ``MMM`` is the three-letter English month abbreviation, i.e. one of Jan,
   Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
 
 - For Standards Track PEPs, after the Created header, add a
@@ -122,7 +128,7 @@ directions below.
 - Post-History can be 'Pending' for now; you'll add dates and corresponding links
   to this header each time you post your PEP to the designated discussion forum
   (and update the Discussions-To header with said link, as above).
-  For each thread, use the date (in the ``dd-mmm-yyy`` format) as the
+  For each thread, use the date (in the ``DD-MMM-YYYY`` format) as the
   linked text, and insert the URLs inline as anonymous reST `hyperlinks`_,
   with commas in between each posting.
 
@@ -795,6 +801,16 @@ resources don't address, ping ``@python/pep-editors`` on GitHub, open an
 or reach out to a PEP editor directly.
 
 
+Change History
+==============
+
+* `22-Feb-2026 <https://discuss.python.org/t/small-but-useful-change-to-pep-1-12/106250>`_
+
+  * Suggest a new section, headed ``Change History`` to the PEP template, and
+    add that section to this PEP.
+  * The ``Rationale`` section now comes after the ``Specification`` section.
+
+
 Copyright
 =========
 

peps/pep-0012/pep-NNNN.rst

@@ -28,18 +28,18 @@ Motivation
 [Clearly explain why the existing language specification is inadequate to address the problem that the PEP solves.]
 
 
-Rationale
-=========
-
-[Describe why particular design decisions were made.]
-
-
 Specification
 =============
 
 [Describe the syntax and semantics of any new language feature.]
 
 
+Rationale
+=========
+
+[Describe why particular design decisions were made.]
+
+
 Backwards Compatibility
 =======================
 
@@ -88,6 +88,16 @@ Footnotes
 [A collection of footnotes cited in the PEP, and a place to list non-inline hyperlink targets.]
 
 
+Change History
+==============
+
+[A summary of major changes the PEP has undergone.  Whenever you update the
+``Post-History``, add a new bullet item in newest-first (i.e. reverse
+chronological) order, using the same ``DD-MMM-YYYY`` format, with sub-bullets
+summarizing the changes.  You can use the same link for the date bullet as you
+do in the ``Post-History`` addition.]
+
+
 Copyright
 =========
 

peps/pep-0101.rst

@@ -127,10 +127,10 @@ release.  The roles and their current experts are:
 
 * RM = Release Manager
 
+  - Savannah Ostrowski <savannah@python.org> (US)
   - Hugo van Kemenade <hugo@python.org> (FI)
   - Thomas Wouters <thomas@python.org> (NL)
   - Pablo Galindo Salgado <pablogsal@python.org> (UK)
-  - Łukasz Langa <lukasz@python.org> (PL)
 
 * WE = Windows - Steve Dower <steve.dower@python.org>
 * ME = Mac - Ned Deily <nad@python.org> (US)
@@ -157,8 +157,8 @@ As much as possible, the release is automated and guided by the
 `python/release-tools`_. This helps by automating many of the following steps,
 and guides you to perform some manual steps.
 
-- Log into Discord and join the Python Core Devs server. Ask Thomas
-  or Łukasz for an invite.
+- Log into Discord and join the Python Core Devs server. Ask another
+  RM for an invite.
 
   You probably need to coordinate with other people around the world.
   This communication channel is where we've arranged to meet.
@@ -330,8 +330,6 @@ and guides you to perform some manual steps.
   - Compile all variants of binaries (32-bit, 64-bit, debug/release),
     including running profile-guided optimization.
 
-  - Compile the HTML Help file containing the Python documentation.
-
   - Codesign all the binaries with the PSF's certificate.
 
   - Create packages for python.org, nuget.org, the embeddable distro and
@@ -740,20 +738,6 @@ else does them.  Some of those tasks include:
 
         git push upstream --delete 3.3  # or perform from GitHub Settings page
 
-- Remove the release from the list of "Active Python Releases" on the Downloads
-  page.  To do this, `log in to the admin page <https://www.python.org/admin>`__
-  for python.org, navigate to Boxes,
-  and edit the ``downloads-active-releases`` entry.  Strip out the relevant
-  paragraph of HTML for your release.  (You'll probably have to do the ``curl -X PURGE``
-  trick to purge the cache if you want to confirm you made the change correctly.)
-
-- Add a retired notice to each release page on python.org for the retired branch.
-  For example:
-
-  * https://www.python.org/downloads/release/python-337/
-
-  * https://www.python.org/downloads/release/python-336/
-
 - In python-releases.toml_, set the branch status to end-of-life.
 
 - Update or remove references to the branch in the `developer's guide