Core Python Programming (2nd Edition)

gc = GC()
>>> gc.foo() # GC C1 P1
called P1-foo()
>>> gc.bar() # GC C1 P1 P2
called P2-bar()
When calling foo(), it looks in the current class (GC) first. If it cannot be found, it goes up to its
immediate parent, C1. The search fails there so it continues up the tree to its parent, P1, which is where
foo() is found.
Likewise for bar(), it searches through GC, C1, and P1 before then finding it in P2. C2.bar() is never found
because of the resolution order used. Now, you may be thinking, "I would prefer to call C2's bar()
because it is closer to me in the inheritance tree, thus more relevant." In this case, you can still use it,
but you have to do it in the typical unbound fashion by invoking its fully qualified name and providing a
valid instance:
>>> C2.bar(gc)
called C2-bar()
New-Style Classes
Now uncomment the (object) next to the class declarations for P1 and P2 and reexecute. The new-style
method resolution gives us something different:
>>> gc = GC()
>>> gc.foo() # GC C1 C2 P1
called P1-foo()
>>> gc.bar() # GC C1 C2
called C2-bar()
Instead of following the tree up each step, it looks at the siblings first, giving it more of a breadth-first
flavor. When looking for foo(), it checks GC, followed by C1 and C2, and then finds it in P1. If P1 did not
have it, it would have gone to P2. The bottom line for foo() is that both classic and new-style classes
would have found it in P1, but they took different paths to get there.
The result for bar() is different, though. It searches GC and C1, and finds it next in C2 and uses it there.
It does not continue up to the grandparents P1 and P2. In this case, the new-style resolution fit into the
scheme better if you did prefer to call the "closest" bar() from GC. And of course, if you still need to call
one higher up, just do it in an unbound manner as before:
>>> P2.bar(gc)
called P2-bar()
New-style classes also have an __mro__ attribute that tells you what the search order is:
>>> GC.__mro__