Merge branch 'main' into 694-woodruff-dpo

Author: warsaw

peps/pep-0011.rst

@@ -83,7 +83,6 @@ aarch64-apple-darwin      clang
 aarch64-unknown-linux-gnu glibc, gcc
 i686-pc-windows-msvc
 x86_64-pc-windows-msvc
-x86_64-apple-darwin       BSD libc, clang
 x86_64-unknown-linux-gnu  glibc, gcc
 ========================= =====
 
@@ -103,6 +102,7 @@ Target Triple                 Notes                      Contacts
 ============================= ========================== ========
 aarch64-unknown-linux-gnu     glibc, clang               Victor Stinner, Gregory P. Smith
 wasm32-unknown-wasip1         WASI SDK, Wasmtime         Brett Cannon, Michael Droettboom
+x86_64-apple-darwin           macOS, clang               Sam Gross, Barry Warsaw, Ronald Oussoren
 x86_64-unknown-linux-gnu      glibc, clang               Victor Stinner, Gregory P. Smith
 ============================= ========================== ========
 
@@ -123,7 +123,7 @@ aarch64-linux-android                                        Russell Keith-Magee
 aarch64-pc-windows-msvc                                      Steve Dower
 arm64-apple-ios                  iOS on device               Russell Keith-Magee, Ned Deily
 arm64-apple-ios-simulator        iOS on M1 macOS simulator   Russell Keith-Magee, Ned Deily
-armv7l-unknown-linux-gnueabihf   Raspberry Pi OS, glibc, gcc Gregory P. Smith
+armv7l-unknown-linux-gnueabihf   32-bit Raspberry Pi OS, gcc Gregory P. Smith
 powerpc64le-unknown-linux-gnu    glibc, clang                Victor Stinner
 
                                  glibc, gcc                  Victor Stinner

peps/pep-0503.rst

@@ -10,6 +10,8 @@ Created: 04-Sep-2015
 Post-History: 04-Sep-2015
 Resolution: https://mail.python.org/pipermail/distutils-sig/2015-September/026899.html
 
+.. canonical-pypa-spec:: :ref:`packaging:simple-repository-api`
+
 
 Abstract
 ========

peps/pep-0691.rst

@@ -13,6 +13,8 @@ Created: 04-May-2022
 Post-History: `05-May-2022 <https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553>`__
 Resolution: https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553/70
 
+.. canonical-pypa-spec:: :ref:`packaging:simple-repository-api`
+
 
 Abstract
 ========

peps/pep-0728.rst

@@ -3,12 +3,13 @@ Title: TypedDict with Typed Extra Items
 Author: Zixuan James Li <p359101898@gmail.com>
 Sponsor: Jelle Zijlstra <jelle.zijlstra@gmail.com>
 Discussions-To: https://discuss.python.org/t/pep-728-typeddict-with-typed-extra-items/45443
-Status: Draft
+Status: Accepted
 Type: Standards Track
 Topic: Typing
 Created: 12-Sep-2023
 Python-Version: 3.15
 Post-History: `09-Feb-2024 <https://discuss.python.org/t/pep-728-typeddict-with-typed-extra-items/45443>`__,
+Resolution: `15-Aug-2025 <https://discuss.python.org/t/pep-728-typeddict-with-typed-extra-items/45443/159>`__
 
 
 Abstract
@@ -123,6 +124,24 @@ Given the usage of pre-:pep:`692` type annotation for ``**kwargs`` in existing
 codebases, it will be valuable to accept and type extra items on TypedDict so
 that the old typing behavior can be supported in combination with ``Unpack``.
 
+Previous Discussions
+--------------------
+
+The new features introduced in this PEP would address several long-standing feature
+requests in the type system. Previous discussions include:
+
+- `Mypy issue <https://github.com/python/mypy/issues/7981>`__ asking for a "final TypedDict"
+  (2019). While the discussion focuses on the ``@final`` decorator, the underlying feature request
+  would be addressed by this PEP.
+- `Mailing list thread <https://mail.python.org/archives/list/typing-sig@python.org/thread/66RITIHDQHVTUMJHH2ORSNWZ6DOPM367/>`__
+  asking for a way to say that a ``TypedDict`` can contain arbitrary extra keys (2020).
+- `Discussion <https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314/87>`__
+  about an extension of the ``Unpack`` mechanism introduced by :pep:`692` (2023).
+- `PEP 705 <https://discuss.python.org/t/pep-705-typeddict-read-only-and-other-keys/36457>`__ in an earlier
+  draft proposed a similar feature (2023); it was removed to keep that PEP simpler.
+- `Discussion <https://discuss.python.org/t/do-we-want-an-exact-typeddict-if-so-how-final-extras-never/44418>`__
+  about an "exact" ``TypedDict`` (2024).
+
 Rationale
 =========
 
@@ -317,7 +336,7 @@ extra items::
         name: str
 
     def f(movie: Movie) -> None:
-        del movie["name"]  # Not OK. The value type of 'name' is 'Required[int]'
+        del movie["name"]  # Not OK. The value type of 'name' is 'Required[str]'
         del movie["year"]  # OK. The value type of 'year' is 'NotRequired[int]'
 
 Interaction with ``Unpack``
@@ -708,8 +727,8 @@ with signatures matching ``dict[str, VT]``
     reveal_type(not_required_num_dict.popitem())  # OK. Revealed type is 'tuple[str, int]'
 
     def f(not_required_num_dict: IntDictWithNum, key: str):
-      not_required_num_dict[key] = 42  # OK
-      del not_required_num_dict[key]  # OK
+        not_required_num_dict[key] = 42  # OK
+        del not_required_num_dict[key]  # OK
 
 :ref:`Notes on indexed accesses <pep728-type-narrowing>` from the previous section
 still apply.
@@ -723,7 +742,7 @@ because such dict can be a subtype of dict::
     def f(might_not_be_a_builtin_dict: dict[str, int]):
         int_dict: IntDict = might_not_be_a_builtin_dict # Not OK
 
-    not_a_builtin_dict: CustomDict = {"num": 1}
+    not_a_builtin_dict = CustomDict({"num": 1})
     f(not_a_builtin_dict)
 
 Runtime behavior
@@ -747,12 +766,22 @@ valid definition that indicates all extra items must be ``None``.)
 How to Teach This
 =================
 
-The choice of the spelling ``"extra_items"`` is intended to make this
-feature more understandable to new users compared to shorter alternatives like
-``"extra"``.
-
-Details of this should be documented in both the typing spec and the
-:mod:`typing` documentation.
+The new features introduced in this PEP can be taught together with the concept
+of inheritance as it applies to ``TypedDict``. A possible outline could be:
+
+- Basics of ``TypedDict``: a ``dict`` with a fixed set of keys and value types.
+- ``NotRequired``, ``Required``, and ``total=False``: keys that may be missing.
+- ``ReadOnly``: keys that cannot be modified.
+- Inheritance: subclasses can add new keys. As a corollary, a value of a ``TypedDict``
+  type may contain additional keys at runtime that are not specified in the type.
+- ``closed=True``: disallowing additional keys and restricting inheritance.
+- ``extra_items=VT``: allowing additional keys with a specified value type.
+
+The concept of a closed ``TypedDict`` should also be cross-referenced in documentation
+for related concepts. For example, type narrowing with the ``in`` operator works
+differently, perhaps more intuitively, with closed ``TypedDict`` types. In addition, when ``Unpack``
+is used for keyword arguments, a closed ``TypedDict`` can be useful to restrict the
+allowed keyword arguments.
 
 Backwards Compatibility
 =======================

peps/pep-0750.rst

@@ -7,7 +7,7 @@ Author: Jim Baker <jim.baker@python.org>,
         Lysandros Nikolaou <lisandrosnik@gmail.com>,
         Dave Peck <davepeck@davepeck.org>
 Discussions-To: https://discuss.python.org/t/71594
-Status: Accepted
+Status: Final
 Type: Standards Track
 Created: 08-Jul-2024
 Python-Version: 3.14
@@ -17,6 +17,9 @@ Post-History: `09-Aug-2024 <https://discuss.python.org/t/60408>`__,
               `18-Nov-2024 <https://discuss.python.org/t/71594>`__,
 Resolution: `10-Apr-2025 <https://discuss.python.org/t/71594/130>`__
 
+.. canonical-doc:: :ref:`py3.14:template-strings`
+
+
 Abstract
 ========
 

peps/pep-0772.rst

@@ -313,6 +313,9 @@ Code of Conduct
 All Packaging Council Electors and Packaging Council members are subject to, and must abide by the
 PSF `Code of Conduct`_, its enforcement procedures, and its remedies for adjudicated violations.
 
+The Packaging Council will moderate its spaces and support PSF Code of Conduct enforcement as
+appropriate in the area.
+
 .. _electors:
 
 ==========================
@@ -444,7 +447,15 @@ This PEP likely requires an atypical approval process, given the parties that mu
 end, the authors will submit this PEP
 
 #. for a vote with the PSF Board, which must approve the linking of Packaging Council Electors to
-   the PSF Membership, and the deactivation of the Packaging Workgroup
+   the PSF Membership, and the deactivation of the Packaging Workgroup.
+
+   - **RESOLVED** that the Python Software Foundation authorises the creation of a Packaging Council
+     as described in the draft of PEP 772 as published on 25 July 2025, conditional on the PEP
+     authors adding language to PEP 772 that explicitly gives the Packaging Council the authority to
+     enforce the PSF Code of Conduct, in addition to enforcement mechanisms otherwise approved by
+     the Foundation.
+   - Requested language added in `PR 4550 <https://github.com/python/peps/pull/4550/files>`_.
+
 #. for a vote on the pypa-committers mailing list, in accordance with the process outlined in
    :pep:`609`
 #. for formal approval by the Python Steering Council

peps/pep-0800.rst

@@ -190,7 +190,18 @@ use CPython's behavior to determine when to use the ``@disjoint_base`` decorator
 add support for alternative implementations (for example, branching on the value of :py:data:`sys.implementation.name <sys.implementation>`),
 stubs could condition the presence of the ``@disjoint_base`` decorator on the implementation where necessary.
 
-Similarly, the exact set of classes that are disjoint bases at runtime may change in future versions of Python.
+Although the concept of "disjoint bases" (referred to as "solid bases") in the CPython implementation has existed
+for decades, the rules for deciding which classes are disjoint bases have occasionally changed.
+Before Python 3.12, adding a ``__dict__`` or support for weakrefs relative to the base class could make a
+class a disjoint base. In practice, this often meant that Python-implemented classes inheriting from
+classes implemented in C, such as :func:`~collections.namedtuple` classes, were themselves disjoint bases.
+This behavior was changed in Python 3.12 by
+`python/cpython#96028 <https://github.com/python/cpython/pull/96028>`__.
+This PEP focuses on supporting the behavior of Python 3.12 and later, which is simpler and easier to understand.
+Type checkers may choose to implement a version of the pre-3.12 behavior if they wish, but doing this correctly
+requires information that is not currently available in the type system.
+
+The exact set of classes that are disjoint bases at runtime may change again in future versions of Python.
 If this were to happen, the type stubs used by type checkers could be updated to reflect this new reality.
 In other words, this PEP adds the concept of disjoint bases to the type system, but it does not prescribe exactly
 which classes are disjoint bases.
@@ -360,7 +371,10 @@ explain to users why type checkers treat certain branches as unreachable.
 Reference Implementation
 ========================
 
-None yet.
+The runtime implementation of the ``@disjoint_base`` decorator will be available in
+typing-extensions 4.15.0.
+`python/mypy#19678 <https://github.com/python/mypy/pull/19678>`__
+implements support for disjoint bases in mypy and in the stubtest tool.
 
 Appendix
 ========