Merge branch 'main' into version-filter

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,17 +687,20 @@ 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-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,8 +29,8 @@ 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

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

peps/pep-0012.rst

@@ -32,13 +32,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:

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

peps/pep-0694.rst

@@ -1105,7 +1105,7 @@ as experience is gained operating Upload 2.0.
 Change History
 ==============
 
-* `06-Dec-2025 <TBD>`__
+* `07-Dec-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/35>`__
 
   * Error responses conform to the :rfc:`9457` format.