Python supports a limited form of multiple inheritance as well. A class definition with multiple base classes looks as follows:
class DerivedClassName(Base1, Base2, Base3):
<statement-1>
.
.
.
<statement-N>
The only rule necessary to explain the semantics is the resolution
rule used for class attribute references. This is depth-first,
left-to-right. Thus, if an attribute is not found in
DerivedClassName, it is searched in Base1, then
(recursively) in the base classes of Base1, and only if it is
not found there, it is searched in Base2, and so on.
(To some people breadth first---searching Base2 and
Base3 before the base classes of Base1---looks more
natural. However, this would require you to know whether a particular
attribute of Base1 is actually defined in Base1 or in
one of its base classes before you can figure out the consequences of
a name conflict with an attribute of Base2. The depth-first
rule makes no differences between direct and inherited attributes of
Base1.)
It is clear that indiscriminate use of multiple inheritance is a maintenance nightmare, given the reliance in Python on conventions to avoid accidental name conflicts. A well-known problem with multiple inheritance is a class derived from two classes that happen to have a common base class. While it is easy enough to figure out what happens in this case (the instance will have a single copy of ``instance variables'' or data attributes used by the common base class), it is not clear that these semantics are in any way useful.