Skip to content

Commit 1150321

Browse files
JelleZijlstraencukouAkuli
authored
gh-136843: Document how multiple inheritance works (#136844)
Co-authored-by: Petr Viktorin <encukou@gmail.com> Co-authored-by: Akuli <akuviljanen17@gmail.com>
1 parent d531991 commit 1150321

File tree

3 files changed

+122
-1
lines changed

3 files changed

+122
-1
lines changed

Doc/reference/compound_stmts.rst

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1421,6 +1421,9 @@ is equivalent to ::
14211421
class Foo(object):
14221422
pass
14231423

1424+
There may be one or more base classes; see :ref:`multiple-inheritance` below for more
1425+
information.
1426+
14241427
The class's suite is then executed in a new execution frame (see :ref:`naming`),
14251428
using a newly created local namespace and the original global namespace.
14261429
(Usually, the suite contains mostly function definitions.) When the class's
@@ -1490,6 +1493,119 @@ can be used to create instance variables with different implementation details.
14901493
were introduced in :pep:`318`.
14911494

14921495

1496+
.. _multiple-inheritance:
1497+
1498+
Multiple inheritance
1499+
--------------------
1500+
1501+
Python classes may have multiple base classes, a technique known as
1502+
*multiple inheritance*. The base classes are specified in the class definition
1503+
by listing them in parentheses after the class name, separated by commas.
1504+
For example, the following class definition:
1505+
1506+
.. doctest::
1507+
1508+
>>> class A: pass
1509+
>>> class B: pass
1510+
>>> class C(A, B): pass
1511+
1512+
defines a class ``C`` that inherits from classes ``A`` and ``B``.
1513+
1514+
The :term:`method resolution order` (MRO) is the order in which base classes are
1515+
searched when looking up an attribute on a class. See :ref:`python_2.3_mro` for a
1516+
description of how Python determines the MRO for a class.
1517+
1518+
Multiple inheritance is not always allowed. Attempting to define a class with multiple
1519+
inheritance will raise an error if one of the bases does not allow subclassing, if a consistent MRO
1520+
cannot be created, if no valid metaclass can be determined, or if there is an instance
1521+
layout conflict. We'll discuss each of these in turn.
1522+
1523+
First, all base classes must allow subclassing. While most classes allow subclassing,
1524+
some built-in classes do not, such as :class:`bool`:
1525+
1526+
.. doctest::
1527+
1528+
>>> class SubBool(bool): # TypeError
1529+
... pass
1530+
Traceback (most recent call last):
1531+
...
1532+
TypeError: type 'bool' is not an acceptable base type
1533+
1534+
In the resolved MRO of a class, the class's bases appear in the order they were
1535+
specified in the class's bases list. Additionally, the MRO always lists a child
1536+
class before any of its bases. A class definition will fail if it is impossible to
1537+
resolve a consistent MRO that satisfies these rules from the list of bases provided:
1538+
1539+
.. doctest::
1540+
1541+
>>> class Base: pass
1542+
>>> class Child(Base): pass
1543+
>>> class Grandchild(Base, Child): pass # TypeError
1544+
Traceback (most recent call last):
1545+
...
1546+
TypeError: Cannot create a consistent method resolution order (MRO) for bases Base, Child
1547+
1548+
In the MRO of ``Grandchild``, ``Base`` must appear before ``Child`` because it is first
1549+
in the base class list, but it must also appear after ``Child`` because it is a parent of
1550+
``Child``. This is a contradiction, so the class cannot be defined.
1551+
1552+
If some of the bases have a custom :term:`metaclass`, the metaclass of the resulting class
1553+
is chosen among the metaclasses of the bases and the explicitly specified metaclass of the
1554+
child class. It must be a metaclass that is a subclass of
1555+
all other candidate metaclasses. If no such metaclass exists among the candidates,
1556+
the class cannot be created, as explained in :ref:`metaclass-determination`.
1557+
1558+
Finally, the instance layouts of the bases must be compatible. This means that it must be
1559+
possible to compute a *solid base* for the class. Exactly which classes are solid bases
1560+
depends on the Python implementation.
1561+
1562+
.. impl-detail::
1563+
1564+
In CPython, a class is a solid base if it has a
1565+
nonempty :attr:`~object.__slots__` definition.
1566+
Many but not all classes defined in C are also solid bases, including most
1567+
builtins (such as :class:`int` or :class:`BaseException`)
1568+
but excluding most concrete :class:`Exception` classes. Generally, a C class
1569+
is a solid base if its underlying struct is different in size from its base class.
1570+
1571+
Every class has a solid base. :class:`object`, the base class, has itself as its solid base.
1572+
If there is a single base, the child class's solid base is that class if it is a solid base,
1573+
or else the base class's solid base. If there are multiple bases, we first find the solid base
1574+
for each base class to produce a list of candidate solid bases. If there is a unique solid base
1575+
that is a subclass of all others, then that class is the solid base. Otherwise, class creation
1576+
fails.
1577+
1578+
Example:
1579+
1580+
.. doctest::
1581+
1582+
>>> class Solid1:
1583+
... __slots__ = ("solid1",)
1584+
>>>
1585+
>>> class Solid2:
1586+
... __slots__ = ("solid2",)
1587+
>>>
1588+
>>> class SolidChild(Solid1):
1589+
... __slots__ = ("solid_child",)
1590+
>>>
1591+
>>> class C1: # solid base is `object`
1592+
... pass
1593+
>>>
1594+
>>> # OK: solid bases are `Solid1` and `object`, and `Solid1` is a subclass of `object`.
1595+
>>> class C2(Solid1, C1): # solid base is `Solid1`
1596+
... pass
1597+
>>>
1598+
>>> # OK: solid bases are `SolidChild` and `Solid1`, and `SolidChild` is a subclass of `Solid1`.
1599+
>>> class C3(SolidChild, Solid1): # solid base is `SolidChild`
1600+
... pass
1601+
>>>
1602+
>>> # Error: solid bases are `Solid1` and `Solid2`, but neither is a subclass of the other.
1603+
>>> class C4(Solid1, Solid2): # error: no single solid base
1604+
... pass
1605+
Traceback (most recent call last):
1606+
...
1607+
TypeError: multiple bases have instance lay-out conflict
1608+
14931609
.. _async:
14941610

14951611
Coroutines

Doc/reference/datamodel.rst

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2629,7 +2629,7 @@ Notes on using *__slots__*:
26292629
* :attr:`~object.__class__` assignment works only if both classes have the
26302630
same *__slots__*.
26312631

2632-
* :ref:`Multiple inheritance <tut-multiple>` with multiple slotted parent
2632+
* :ref:`Multiple inheritance <multiple-inheritance>` with multiple slotted parent
26332633
classes can be used,
26342634
but only one parent is allowed to have attributes created by slots
26352635
(the other bases must have empty slot layouts) - violations raise
@@ -2779,6 +2779,8 @@ Resolving MRO entries
27792779
Core support for typing module and generic types.
27802780

27812781

2782+
.. _metaclass-determination:
2783+
27822784
Determining the appropriate metaclass
27832785
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
27842786
.. index::

Doc/tutorial/classes.rst

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -663,6 +663,9 @@ Taken together, these properties make it possible to design reliable and
663663
extensible classes with multiple inheritance. For more detail, see
664664
:ref:`python_2.3_mro`.
665665

666+
In some cases multiple inheritance is not allowed; see :ref:`multiple-inheritance`
667+
for details.
668+
666669

667670
.. _tut-private:
668671

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy