From 5c3c5cbd9edcb5e070859053630bc6d91eed1a3c Mon Sep 17 00:00:00 2001 From: Jelle Zijlstra Date: Mon, 18 Aug 2025 12:39:58 -0700 Subject: [PATCH 1/2] PEP 800: Note Python 3.12 behavior change, note reference impl --- peps/pep-0800.rst | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/peps/pep-0800.rst b/peps/pep-0800.rst index 887f7b81d1f..920b257a635 100644 --- a/peps/pep-0800.rst +++ b/peps/pep-0800.rst @@ -190,7 +190,17 @@ 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 `), 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 over time. +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 namedtuple classes, were themselves disjoint bases. +This behavior was changed in Python 3.12 by [PR #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 +370,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. +[Mypy PR #19678](https://github.com/python/mypy/pull/19678) implements support for disjoint bases +in mypy and in the stubtest tool. Appendix ======== From ef38963ae9a81d2faacc8007ad29b997b3506982 Mon Sep 17 00:00:00 2001 From: Jelle Zijlstra Date: Mon, 18 Aug 2025 13:10:51 -0700 Subject: [PATCH 2/2] Adam feedback --- peps/pep-0800.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/peps/pep-0800.rst b/peps/pep-0800.rst index 920b257a635..5c13bbbdd2e 100644 --- a/peps/pep-0800.rst +++ b/peps/pep-0800.rst @@ -191,11 +191,12 @@ add support for alternative implementations (for example, branching on the value stubs could condition the presence of the ``@disjoint_base`` decorator on the implementation where necessary. 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 over time. +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 namedtuple classes, were themselves disjoint bases. -This behavior was changed in Python 3.12 by [PR #96028](https://github.com/python/cpython/pull/96028). +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 `__. 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. @@ -372,8 +373,8 @@ Reference Implementation The runtime implementation of the ``@disjoint_base`` decorator will be available in typing-extensions 4.15.0. -[Mypy PR #19678](https://github.com/python/mypy/pull/19678) implements support for disjoint bases -in mypy and in the stubtest tool. +`python/mypy#19678 `__ +implements support for disjoint bases in mypy and in the stubtest tool. Appendix ========