• Choose a category
• All
• Classic-Fiction

By Root 1757 0

It is also true, though, that the instance and class are both derived from the built-in object class, since this is an implicit or explicit superclass of every class:

>>> isinstance(X, object)

True

>>> isinstance(C, object) # Classes always inherit from object

True

The same holds true for built-in types like lists and strings, because types are classes in the new-style model—built-in types are now classes, and their instances derive from object, too:

>>> type('spam')

>>> type(str)

>>> isinstance('spam', object) # Same for built-in types (classes)

True

>>> isinstance(str, object)

True

In fact, type itself derives from object, and object derives from type, even though the two are different objects—a circular relationship that caps the object model and stems from the fact that types are classes that generate classes:

>>> type(type) # All classes are types, and vice versa

>>> type(object)

>>> isinstance(type, object) # All classes derive from object, even type

True

>>> isinstance(object, type) # Types make classes, and type is a class

True

>>> type is object

False

In practical terms, this model makes for fewer special cases than the prior type/class distinction of classic classes, and it allows us to write code that assumes and uses an object superclass. We’ll see examples of the latter later in the book; for now, let’s move on to explore other new-style changes.

Diamond Inheritance Change

One of the most visible changes in new-style classes is their slightly different inheritance search procedures for the so-called diamond pattern of multiple inheritance trees, where more than one superclass leads to the same higher superclass further above. The diamond pattern is an advanced design concept, is coded only rarely in Python practice, and has not been discussed in this book, so we won’t dwell on this topic in depth.

In short, though, with classic classes, the inheritance search procedure is strictly depth first, and then left to right—Python climbs all the way to the top, hugging the left side of the tree, before it backs up and begins to look further to the right. In new-style classes, the search is more breadth-first in such cases—Python first looks in any superclasses to the right of the first one searched before ascending all the way to the common superclass at the top. In other words, the search proceeds across by levels before moving up. The search algorithm is a bit more complex than this, but this is as much as most programmers need to know.

Because of this change, lower superclasses can overload attributes of higher superclasses, regardless of the sort of multiple inheritance trees they are mixed into. Moreover, the new-style search rule avoids visiting the same superclass more than once when it is accessible from multiple subclasses.

Diamond inheritance example

To illustrate, consider this simplistic incarnation of the diamond multiple inheritance pattern for classic classes. Here, D’s superclasses B and C both lead to the same common ancestor, A:

>>> class A:

attr = 1 # Classic (Python 2.6)

>>> class B(A): # B and C both lead to A

pass

>>> class C(A):

attr = 2

>>> class D(B, C):

pass # Tries A before C

>>> x = D()

>>> x.attr # Searches x, D, B, A

1

The attribute here is found in superclass A, because with classic classes, the inheritance search climbs as high as it can before backing up and moving right—Python will search D, B, A, and then C, but will stop when attr is found in A, above B.

However, with new-style classes derived from a built-in like object, and all classes in 3.0, the search order is different: Python looks in C (to the right of B) before A (above B). That is, it searches D, B, C, and then A, and in this case, stops in C:

>>> class A(object):

attr = 1 # New-style ("object" not required in 3.0)

>>> class B(A):

pass

>>> class C(A):

attr = 2

>>> class D(B, C):

pass # Tries C before A

>>> x = D()

>>> x.attr # Searches x, D, B, C

2

This change in