Learning Python - Mark Lutz [424]
New-style classes differ from classic classes in a number of ways, some of which are subtle but can impact existing 2.X code and coding styles. Here are some of the most prominent ways they differ:
Classes and types merged
Classes are now types, and types are now classes. In fact, the two are essentially synonyms. The type(I) built-in returns the class an instance is made from, instead of a generic instance type, and is normally the same as I.__class__. Moreover, classes are instances of the type class, type may be subclassed to customize class creation, and all classes (and hence types) inherit from object.
Inheritance search order
Diamond patterns of multiple inheritance have a slightly different search order—roughly, they are searched across before up, and more breadth-first than depth-first.
Attribute fetch for built-ins
The __getattr__ and __getattribute__ methods are no longer run for attributes implicitly fetched by built-in operations. This means that they are not called for __X__ operator overloading method names—the search for such names begins at classes, not instances.
New advanced tools
New-style classes have a set of new class tools, including slots, properties, descriptors, and the __getattribute__ method. Most of these have very specific tool-building purposes.
We discussed the third of these changes briefly in a sidebar in Chapter 27, and we’ll revisit it in depth in the contexts of attribute management in Chapter 37 and privacy decorators in Chapter 38. Because the first and second of the changes just listed can break existing 2.X code, though, let’s explore these in more detail before moving on to new-style additions.
Type Model Changes
In new-style classes, the distinction between type and class has vanished entirely. Classes themselves are types: the type object generates classes as its instances, and classes generate instances of their type. If fact, there is no real difference between built-in types like lists and strings and user-defined types coded as classes. This is why we can subclass built-in types, as shown earlier in this chapter—because subclassing a built-in type such as list qualifies a class as new-style, it becomes a user-defined type.
Besides allowing us to subclass built-in types, one of the contexts where this becomes most obvious is when we do explicit type testing. With Python 2.6’s classic classes, the type of a class instance is a generic “instance,” but the types of built-in objects are more specific:
C:\misc> c:\python26\python
>>> class C: pass # Classic classes in 2.6
...
>>> I = C()
>>> type(I) # Instances are made from classes
>>> I.__class__ >>> type(C) # But classes are not the same as types >>> C.__class__ AttributeError: class C has no attribute '__class__' >>> type([1, 2, 3]) >>> type(list) >>> list.__class__ But with new-style classes in 2.6, the type of a class instance is the class it’s created from, since classes are simply user-defined types—the type of an instance is its class, and the type of a user-defined class is the same as the type of a built-in object type. Classes have a __class__ attribute now, too, because they are instances of type: C:\misc> c:\python26\python >>> class C(object): pass # New-style classes in 2.6 ... >>> I = C() >>> type(I) # Type of instance is class it's made from >>> I.__class__ >>> type(C) # Classes are user-defined types >>> C.__class__ >>> type([1, 2, 3]) # Built-in types work the same way >>> type(list) >>> list.__class__ The same is true for all classes in Python 3.0, since all classes are automatically new-style, even if they have no explicit superclasses. In fact, the distinction between built-in types and user-defined class types melts away altogether in 3.0: C:\misc> c:\python30\python >>> class C: pass # All classes