Merge branch 'main' into pep-813-pprint

Author: warsaw

.github/CODEOWNERS

@@ -689,6 +689,8 @@ 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-2026.rst  @hugovk
 # ...

.github/workflows/lint.yml

@@ -19,7 +19,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v6
         with:
           persist-credentials: false
 

.github/workflows/render.yml

@@ -27,7 +27,7 @@ jobs:
 
     steps:
       - name: Checkout
-        uses: actions/checkout@v5
+        uses: actions/checkout@v6
         with:
           fetch-depth: 0  # fetch all history so that last modified date-times are accurate
 

.github/workflows/test.yml

@@ -41,7 +41,7 @@ jobs:
         - "ubuntu-latest"
 
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v6
         with:
           persist-credentials: false
 

.pytest.toml

@@ -12,6 +12,7 @@ addopts = [
     # https://pytest-cov.readthedocs.io/en/latest/config.html#reference
     "--cov=check_peps",
     "--cov=pep_sphinx_extensions",
+    "--cov=release_management",
     "--cov-report=html",
     "--cov-report=xml",
 ]
@@ -23,6 +24,7 @@ filterwarnings = ["error"]
 
 testpaths = [
     "pep_sphinx_extensions",
+    "release_management",
 ]
 
 # https://docs.pytest.org/en/stable/reference/reference.html#confval-strict

pep_sphinx_extensions/pep_theme/static/mq.css

@@ -152,7 +152,7 @@
 
     section#pep-page-section > article {
         float: none;
-        max-width: 17.5cm;
+        max-width: 100%;
         width: auto;
         margin: 0;
         padding: 0;

pep_sphinx_extensions/pep_zero_generator/pep_index_generator.py

@@ -26,7 +26,7 @@
 from pep_sphinx_extensions.pep_zero_generator import subindices
 from pep_sphinx_extensions.pep_zero_generator import writer
 from pep_sphinx_extensions.pep_zero_generator.constants import SUBINDICES_BY_TOPIC
-from release_management.serialize import create_release_cycle, create_release_json
+from release_management.serialize import create_release_cycle, create_release_schedule_calendar, create_release_json
 
 if TYPE_CHECKING:
     from sphinx.application import Sphinx
@@ -79,3 +79,6 @@ def create_pep_zero(app: Sphinx, env: BuildEnvironment, docnames: list[str]) ->
 
     release_json = create_release_json()
     app.outdir.joinpath('api/python-releases.json').write_text(release_json, encoding="utf-8")
+
+    release_ical = create_release_schedule_calendar()
+    app.outdir.joinpath('release-schedule.ics').write_text(release_ical, encoding="utf-8")

peps/pep-0012.rst

@@ -599,10 +599,10 @@ processed output using the ``image`` directive:
 
     .. image:: diagram.png
 
-Any browser-friendly graphics format is possible; PNG should be
+Any browser-friendly graphics format is possible; SVG or PNG are
 preferred for graphics, JPEG for photos and GIF for animations.
-Currently, SVG must be avoided due to compatibility issues with the
-PEP build system.
+Images should be optimised to reduce their file size, and should
+be legible in both light and dark mode in the browser.
 
 For accessibility and readers of the source text, you should include
 a description of the image and any key information contained within

peps/pep-0101.rst

@@ -650,12 +650,6 @@ permissions.
   fuzzy bit because not much can be automated.  You can use an earlier
   announcement as a template, but edit it for content!
 
-- Once the announcement is up on Discourse, send an equivalent to the
-  following mailing lists:
-
-  * python-list@python.org
-  * python-announce@python.org
-
 - Also post the announcement to the
   `Python Insider blog <https://blog.python.org>`_.
   To add a new entry, go to
@@ -786,8 +780,6 @@ else does them.  Some of those tasks include:
 
   * `discuss.python.org`_
 
-  * mailing lists (python-dev, python-list, python-announcements)
-
   * `Python Insider blog <https://blog.python.org>`_
 
 - Enjoy your retirement and bask in the glow of a job well done!

peps/pep-0694.rst

@@ -12,6 +12,7 @@ Post-History: `27-Jun-2022 <https://discuss.python.org/t/pep-694-upload-2-0-api-
               `14-Apr-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0/76316/9>`__
               `06-Aug-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483>`__
               `27-Sep-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/31>`__
+              `07-Dec-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/35>`__
 
 
 Abstract
@@ -84,8 +85,8 @@ In addition, there are a number of major issues with the legacy API:
 
 The new upload API proposed in this PEP provides ways to solve all of these problems, either directly or
 through an extensible approach, allowing servers to implement features such as resumable and parallel uploads.
-This upload API this PEP proposes provides better error reporting, a more robust release testing experience,
-and atomic and simultaneous publishing of all release artifacts.
+This upload API this PEP proposes provides better and more standardized error reporting, a more robust release
+testing experience, and atomic and simultaneous publishing of all release artifacts.
 
 Legacy API
 ==========
@@ -274,17 +275,26 @@ are determined by the index operator.
 Errors
 ------
 
+Unless otherwise specified, all error (4xx and 5xx) responses from the server **MUST** use the :rfc:`9457`
+(Problem Details for HTTP APIs) format.  In particular, the server **MUST** use the "Problem Details JSON
+Object" defined in :rfc:`Section 3 <9457#section-3>` and **SHOULD** use the ``application/problem+json`` media
+type in its responses.
+
 Clients in general should be prepared to handle `HTTP response error status codes
-<https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status>`_ which **MAY** contain payloads of the
-the following format:
+<https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status>`_ which **SHOULD** contain payloads like
+the following, although note that the details are index-specific, as long as they conform to RFC 9457.  By way
+of example, PyPI could return the following error body:
 
 .. code-block:: json
 
     {
+      "type": "https://docs.pypi.org/api/errors/error-types#invalid-filename",
+      "status": 400,
+      "title": "The artifact used an invalid wheel file name format",
+      "details": "See https://packaging.python.org/en/latest/specifications/binary-distribution-format/",
       "meta": {
         "api-version": "2.0"
       },
-      "message": "...",
       "errors": [
         {
           "source": "...",
@@ -293,11 +303,12 @@ the following format:
       ]
     }
 
-Besides the standard ``meta`` key, this has the following top level keys:
+RFC 9457 defines ``type``, ``status``, ``title``, and ``details``.  The ``meta`` and ``errors`` keys are
+"extension members", defined in :rfc:`Section 3.2 <9457#section-3.2>`.  The index **SHOULD** include these
+extension members.
 
-``message``
-    A singular message that encapsulates all errors that may have happened on this
-    request.
+``meta``
+    The same request/response metadata structure as defined in the :ref:`publishing-session` description.
 
 ``errors``
     An array of specific errors, each of which contains a ``source`` key, which is a string that
@@ -683,14 +694,14 @@ The request looks like:
 Besides the standard ``meta`` key, the request JSON has the following additional keys:
 
 ``filename`` (**required**)
-    The name of the file being uploaded.  The filename **MUST** conform to either the `source
-    distribution file name specification
+    The name of the file being uploaded.  The filename **MUST** conform to either the `source distribution
+    file name specification
     <https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-file-name>`_
     or the `binary distribution file name convention
     <https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-name-convention>`_.
-    Indexes **SHOULD** validate these file names at the time of the request, returning a ``400 Bad
-    Request`` error code, as described in the :ref:`session-errors` section when the file names do
-    not conform.
+    Indexes **SHOULD** validate these file names at the time of the request, returning a ``400 Bad Request``
+    error code and an RFC 9457 style error body, as described in the :ref:`session-errors` section when the
+    file names do not conform.
 
 ``size`` (**required**)
     The size in bytes of the file being uploaded.
@@ -1094,7 +1105,11 @@ as experience is gained operating Upload 2.0.
 Change History
 ==============
 
-* `23-Sep-2025 <TBD>`__
+* `06-Dec-2025 <TBD>`__
+
+  * Error responses conform to the :rfc:`9457` format.
+
+* `23-Sep-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/31>`__
 
   * Remove the ``nonce`` and ``gentoken()`` algorithm.  Indexes are now responsible for generating
     an cryptographically secure session token and obfuscated stage URL (but only if they support