Skip to content

Commit dc07e9c

Browse files
Added CatDog example
1 parent 6710156 commit dc07e9c

File tree

1 file changed

+36
-26
lines changed

1 file changed

+36
-26
lines changed

Doc/tutorial/classes.rst

Lines changed: 36 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -638,33 +638,43 @@ multiple base classes looks like this::
638638
<statement-N>
639639

640640
For most purposes, in the simplest cases, you can think of the search for
641-
attributes inherited from a parent class as depth-first, left-to-right, not
641+
attributes inherited from a parent class as breadth-first, left-to-right, not
642642
searching twice in the same class where there is an overlap in the hierarchy.
643-
Thus, if an attribute is not found in :class:`!DerivedClassName`, it is searched
644-
for in :class:`!Base1`, then (recursively) in the base classes of :class:`!Base1`,
645-
and if it was not found there, it was searched for in :class:`!Base2`, and so on.
646-
647-
In fact, it is slightly more complex than that; the method resolution order
648-
changes dynamically to support cooperative calls to :func:`super`. This
649-
approach is known in some other multiple-inheritance languages as
650-
call-next-method and is more powerful than the super call found in
651-
single-inheritance languages.
652-
653-
Dynamic ordering is necessary because all cases of multiple inheritance exhibit
654-
one or more diamond relationships (where at least one of the parent classes
655-
can be accessed through multiple paths from the bottommost class). For example,
656-
all classes inherit from :class:`object`, so any case of multiple inheritance
657-
provides more than one path to reach :class:`object`. To keep the base classes
658-
from being accessed more than once, the dynamic algorithm linearizes the search
659-
order in a way that preserves the left-to-right ordering specified in each
660-
class, that calls each parent only once, and that is monotonic (meaning that a
661-
class can be subclassed without affecting the precedence order of its parents).
662-
Taken together, these properties make it possible to design reliable and
663-
extensible classes with multiple inheritance. For more detail, see
664-
:ref:`python_2.3_mro`.
665-
666-
In some cases multiple inheritance is not allowed; see :ref:`multiple-inheritance`
667-
for details.
643+
For examnple::
644+
645+
>>> class Animal:
646+
... def who_am_i(self):
647+
... print("I'm an Animal")
648+
...
649+
>>> class Cat(Animal):
650+
... pass
651+
...
652+
>>> class Dog(Animal):
653+
... def who_am_i(self):
654+
... print("I'm a Dog")
655+
...
656+
>>> class CatDog(Cat, Dog):
657+
... pass
658+
...
659+
>>> cat_dog = CatDog()
660+
>>> cat_dog.who_am_i()
661+
I'm a Dog
662+
663+
In reality it is a little more complicated. Python uses the C3 method
664+
resolution order (MRO). Each class has a built-in attribute
665+
:attr:`~type.__mro__` that returns a tuple of classes that are considered
666+
during method resolution::
667+
668+
>>> for cls in CatDog.__mro__:
669+
... print(cls)
670+
...
671+
<class '__main__.CatDog'>
672+
<class '__main__.Cat'>
673+
<class '__main__.Dog'>
674+
<class '__main__.Animal'>
675+
<class 'object'>
676+
677+
For more details, see :ref:`python_2.3_mro`.
668678

669679

670680
.. _tut-private:

0 commit comments

Comments
 (0)