@@ -638,33 +638,43 @@ multiple base classes looks like this::
638638 <statement-N>
639639
640640For 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
642642searching 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