Skip to content

PEP 800: Note Python 3.12 behavior change, note reference impl #4555

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 18, 2025
Merged

PEP 800: Note Python 3.12 behavior change, note reference impl #4555

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5c3c5cb
PEP 800: Note Python 3.12 behavior change, note reference impl
JelleZijlstra Aug 18, 2025
ef38963
Adam feedback
JelleZijlstra Aug 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 16 additions & 2 deletions peps/pep-0800.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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
========
Expand Down