@@ -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+
14241427The class's suite is then executed in a new execution frame (see :ref: `naming `),
14251428using 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
14951611Coroutines
0 commit comments