Merge branch 'main' into emails

Author: msullivan

.github/CODEOWNERS

@@ -687,7 +687,7 @@ 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
@@ -698,6 +698,7 @@ peps/pep-0819.rst  @emmatyping
 peps/pep-0820.rst  @encukou
 peps/pep-0821.rst  @JelleZijlstra
 peps/pep-0822.rst  @methane
+peps/pep-0826.rst  @savannahostrowski
 # ...
 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

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-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.
 

peps/pep-0743.rst

@@ -2,19 +2,29 @@ PEP: 743
 Title: Add Py_OMIT_LEGACY_API to the Python C API
 Author: Victor Stinner <vstinner@python.org>,
         Petr Viktorin <encukou@gmail.com>,
-PEP-Delegate: C API Working Group
 Discussions-To: https://discuss.python.org/t/59323
-Status: Draft
+Status: Rejected
 Type: Standards Track
 Created: 11-Mar-2024
 Python-Version: 3.15
 Post-History: `11-Mar-2024 <https://discuss.python.org/t/48243>`__,
               `27-Jul-2024 <https://discuss.python.org/t/59323>`__,
-
+Resolution: `20-Feb-2026 <https://discuss.python.org/t/59323/20>`__
 
 .. highlight:: c
 
 
+Rejection Notice
+================
+
+The Steering Council has rejected this PEP in its current form:
+
+   While we agree that the problem the PEP tries to solve is one worth solving,
+   we’re not convinced this is the correct approach.
+
+See `the full post <https://discuss.python.org/t/59323/20>`_.
+
+
 Abstract
 ========
 

peps/pep-0783.rst

@@ -86,10 +86,10 @@ The platform tags will take the form:
 
 .. code-block:: text
 
-   pyodide_${YEAR}_${PATCH}_wasm32
+   pyodide_${PYTHON_MAJOR_MINOR}_${PATCH}_wasm32
 
 Each one of these will be used with a specified Python version. For example, the
-platform tag ``pyodide_2025_0`` will be used with Python 3.13.
+platform tag ``pyodide_314_0`` will be used with Python 3.14.
 
 Emscripten Wheel ABI
 --------------------
@@ -193,6 +193,24 @@ Security Implications
 
 There are no security implications in this PEP.
 
+Rejected Ideas
+==============
+
+Alternative Options for the Platform Tag
+----------------------------------------
+
+* ``pyodide_${YEAR}_${PATCH}`` -- This avoids potential confusion between e.g.,
+  ``314_0`` and Python ``3.14.0``. On the other hand, it makes the link between
+  ABI and Python minor version ambiguous.
+
+* ``pyodide_${MAJOR}_${MINOR}_${ABI_PATCH}`` -- this would handle a future
+  two-digit major version, but the ABI patch version would be too easily
+  confused with a Python patch version e.g., ``3_14_0`` seems to imply Python
+  ``3.14.0`` specifically rather than Python 3.14.x.
+
+* No ABI patch version -- we hope never to need the patch version, but it's
+  good to be prepared for unforseen problems.
+
 How to Teach This
 =================
 

peps/pep-0797.rst

@@ -404,8 +404,8 @@ New APIs and important information about how to use them will be added to the
 Reference Implementation
 ========================
 
-The reference implementation of this PEP can be found
-`here <https://github.com/python/cpython/compare/main...ZeroIntensity:cpython:shared-object-proxy>`_.
+A reference implementation of this PEP can be found at
+`python/cpython#145150 <https://github.com/python/cpython/pull/145150>`_.
 
 Rejected Ideas
 ==============
@@ -426,7 +426,8 @@ Acknowledgements
 ================
 
 This PEP would not have been possible without discussion and feedback from
-Eric Snow, Petr Viktorin, Kirill Podoprigora, Adam Turner, and Yury Selivanov.
+Eric Snow, Petr Viktorin, Kirill Podoprigora, Adam Turner, Yury Selivanov, and
+Steve Dower.
 
 Copyright
 =========