Core Python Programming (2nd Edition)

class B(object):
pass
class C(object):
def __init__(self):
print "the default constructor"
Not much change here other than adding (object) to both class declarations, right? That is true, but as
you can see in the diagram, the hierarchy is now a diamond; the real problem is in the MRO now. If we
used the classic class MRO, when instantiating D, we no longer get C.__init__()... we get object.
__init__()! This is the exact reason why the MRO needed to be changed.
Although we saw that it does change the way attributes are looked up in our example above with the GC
class, you do not have to worry about lots of code breaking. Classic classes will still use the old MRO
while new-style classes will use its MRO. Again, if you do not need all of the features of the new-style
classes, there is nothing wrong with continuing to develop using classic classes.
Summary
Classic classes have a depth-first MRO algorithm. Because new-style classes inherit from object, a new
MRO had to be created because of problems ensuing from the now-diamond-shaped class hierarchy.
You can read more about new-style classes, the MROs, and more in:
● Guido van Rossum's essay on the unification of types and classes: http://www.python.org/
download/releases/2.2.3/descrintro
● PEP 252: Making Types Look More Like Classes http://www.python.org/doc/peps/pep-0252
● "What's New in Python 2.2" document http://www.python.org/doc/2.2.3/whatsnew
● Python 2.3 Method Resolution order paper http://python.org/download/releases/2.3/mro/