@@ -1421,6 +1421,9 @@ is equivalent to ::
1421
1421
class Foo(object):
1422
1422
pass
1423
1423
1424
+ There may be one or more base classes; see :ref: `multiple-inheritance ` below for more
1425
+ information.
1426
+
1424
1427
The class's suite is then executed in a new execution frame (see :ref: `naming `),
1425
1428
using a newly created local namespace and the original global namespace.
1426
1429
(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.
1490
1493
were introduced in :pep: `318 `.
1491
1494
1492
1495
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
+
1493
1609
.. _async :
1494
1610
1495
1611
Coroutines
0 commit comments