Learning Python - Mark Lutz [567]
Classic classes in 2.6 are a bit different, though—because they reflect the class model in older Python releases, they do not have a __class__ link, and like built-in types in 2.6 they are instances of type, not a type class:
C:\misc> c:\python26\python
>>> class C: pass # In 2.6 classic classes,
... # classes have no class themselves
>>> X = C()
>>> type(X)
>>> type(C) >>> X.__class__ >>> C.__class__ AttributeError: class C has no attribute '__class__' Metaclasses Are Subclasses of Type So why do we care that classes are instances of a type class in 3.0? It turns out that this is the hook that allows us to code metaclasses. Because the notion of type is the same as class today, we can subclass type with normal object-oriented techniques and class syntax to customize it. And because classes are really instances of the type class, creating classes from customized subclasses of type allows us to implement custom kinds of classes. In full detail, this all works out quite naturally—in 3.0, and in 2.6 new-style classes: type is a class that generates user-defined classes. Metaclasses are subclasses of the type class. Class objects are instances of the type class, or a subclass thereof. Instance objects are generated from a class. In other words, to control the way classes are created and augment their behavior, all we need to do is specify that a user-defined class be created from a user-defined metaclass instead of the normal type class. Notice that this type instance relationship is not quite the same as inheritance: user-defined classes may also have superclasses from which they and their instances inherit attributes (inheritance superclasses are listed in parentheses in the class statement and show up in a class’s __bases__ tuple). The type from which a class is created, and of which it is an instance, is a different relationship. The next section describes the procedure Python follows to implement this instance-of type relationship. Class Statement Protocol Subclassing the type class to customize it is really only half of the magic behind metaclasses. We still need to somehow route a class’s creation to the metaclass, instead of the default type. To fully understand how this is arranged, we also need to know how class statements do their business. We’ve already learned that when Python reaches a class statement, it runs its nested block of code to create its attributes—all the names assigned at the top level of the nested code block generate attributes in the resulting class object. These names are usually method functions created by nested defs, but they can also be arbitrary attributes assigned to create class data shared by all instances. Technically speaking, Python follows a standard protocol to make this happen: at the end of a class statement, and after running all its nested code in a namespace dictionary, it calls the type object to create the class object: class = type(classname, superclasses, attributedict) The type object in turn defines a __call__ operator overloading method that runs two other methods when the type object is called: type.__new__(typeclass, classname, superclasses, attributedict) type.__init__(class, classname, superclasses, attributedict) The __new__ method creates and returns the new class object, and then the __init__ method initializes the newly created object. As we’ll see in a moment, these are the hooks that metaclass subclasses of type generally use to customize classes. For example, given a class definition like the following: class Spam(Eggs): # Inherits from Eggs data = 1 # Class data attribute def meth(self, arg): # Class method attribute pass Python will internally run the nested code block to create two attributes of the class (data and meth), and then call the type object to generate the class object at the end of the class statement: Spam = type('Spam', (Eggs,), {'data': 1, 'meth': meth, '__module__': '__main__'}) Because this call is made