The Downside of “Helper” Functions

Before we get to metaclass code, let’s get a better handle on its rationale. Like the decorators of the prior chapter, metaclasses are optional in principle. We can usually achieve the same effect by passing class objects through functions—known interchangeably as helper or manager functions—much as we can achieve the goals of decorators by passing functions and classes through manager code. Just like decorators, though, metaclasses:

• Provide a more uniform and explicit structure

• Help ensure that application programmers won’t forget to augment their classes according to an API’s requirements

• Avoid code redundancy and its associated maintenance costs by factoring class customization logic into a single location

To illustrate, suppose we want to automatically insert a method into a set of classes. Of course, we could do this with simple inheritance if the subject method is known when we code the classes. In that case, we can simply code the method in a superclass and have all the classes in question inherit from it:

class Extras:
    def extra(self, args):              # Normal inheritance: too static
        …

class Client1(Extras): …                # Clients inherit extra methods
class Client2(Extras): …

X = Client1()                           # Make an instance
X.extra()                               # Run the extra methods

Sometimes, though, it’s impossible to predict such augmentation when classes are coded. Consider the case where classes are augmented in response to choices made in a user interface at runtime or loaded from an editable configuration file. Although we could code every class in our imaginary set to manually check these, too, it’s a lot to ask of clients (the required function here is abstract—it’s something to be filled in):

def extra(self, arg): …

class Client1: …                        # Client augments: too distributed
if required():
    Client1.extra = extra

class Client2: …
if required():
    Client2.extra = extra               # Add the extra method – maybe

X = Client1()
X.extra()

We can add methods to a class after the class statement like this because, as we’ve learned, a class-level method is just a plain function that is associated with a class and has a first argument to receive a self instance when called through one. Although this works, it might become untenable for larger method sets and puts all the burden of augmentation on each client class (and assumes they’ll remember to do this at all).

It would be better from a maintenance perspective to isolate the decision logic in a single place. We might encapsulate some of this extra work by routing classes through a helper function—a function that would extend the class as required and handle all the work of runtime testing and configuration:

def extra(self, arg): …

def extras(Class):                      # Helper function: too manual
    if required():
        Class.extra = extra

class Client1: …
extras(Client1)

class Client2: …
extras(Client2)

X = Client1()
X.extra()

This code runs the class through a helper function immediately after it is created. Although functions like this one can achieve our goal here, they still put a burden on class coders, who must understand the requirements and adhere to them in their code. It would be even better if there was a simple way to enforce the augmentation in the subject classes, so that they don’t need to deal with the augmentation so explicitly and would be less likely to forget to use it altogether. In other words, we’d like to be able to insert some code to run automatically at the end of a class statement to augment the class.

This is exactly what metaclasses do—by declaring a metaclass, we tell Python to route the creation of the class object to another class we provide:

def extra(self, arg): …

class Extras(type):
    def __init__(Class, classname, superclasses, attributedict):
        if required():
            Class.extra = extra

class Client1(metaclass=Extras): …      # Metaclass declaration only
class Client2(metaclass=Extras): …      # Client class is instance of meta

X = Client1()                           # X is instance of client class
X.extra()

Because Python invokes the metaclass automatically at the end of the class statement when the new class is created, it can augment, register, wrap, or otherwise manage the class as needed. Moreover, the only requirement for the client classes is that they declare their metaclass; every class that does so will automatically acquire whatever augmentation the metaclass provides, both now and in the future if the metaclass changes.

Metaclasses can also augment their class instances with inherited methods, which are akin to normal class methods but not inherited by the instances of their class instances—an inheritance extension and tongue twister whose true nature requires more info ahead (and quite possibly, sedation). Through both changes and methods, though, metaclasses can customize class behavior broadly.

Of course, this is the standard rationale, which you’ll need to judge for yourself—in truth, clients might forget to list a metaclass just as easily as they could forget to call a helper function! Still, the explicit nature of metaclasses may make this less likely. Although it may be difficult to glean from this small and hypothetical example, metaclasses generally handle such tasks better than more manual approaches.

Metaclasses Versus Class Decorators: Round 1

Having said that, it’s also important to note that the class decorators described in the preceding chapter sometimes overlap with metaclasses—in terms of both utility and benefit. Like metaclasses, class decorators can be used to manage both classes and their later instances, and their syntax makes their usage similarly explicit and arguably more obvious than helper-function calls.

For example, suppose we recoded the last section’s helper function to return the augmented class instead of simply modifying it in place. This would allow a greater degree of flexibility because the manager would be free to return any type of object that implements the class’s expected interface:

def extra(self, arg): …

def extras(Class):
    if required():
        Class.extra = extra
    return Class               # Return the augmented class

class Client1: …
Client1 = extras(Client1)      # Rebind to augmented class

class Client2: …
Client2 = extras(Client2)

X = Client1()
X.extra()

If you think this is starting to look reminiscent of class decorators, you’re right. In the prior chapter, we emphasized class decorators’ role in augmenting instance creation calls. Because they work by automatically rebinding a class name to the result of a function, though, there’s no reason that we can’t use them to augment the class by changing it before any instances are ever created. That is, class decorators can apply extra logic to classes, not just instances, at class creation time:

def extra(self, arg): …

def extras(Class):             # From helper to decorator
    if required():
        Class.extra = extra
    return Class

@extras
class Client1: …               # Client1 = extras(Client1)

@extras
class Client2: …               # Rebinds class independent of instances

X = Client1()                  # Makes instance of augmented class
X.extra()                      # X is instance of original Client1

Decorators essentially automate the prior example’s manual name rebinding here. Just as for metaclasses, because this decorator returns the original class, instances are made from that class, not from a wrapper object. In fact, instance creation is not intercepted at all in this example.

In this specific case—adding methods to a class when it’s created—the choice between metaclasses and decorators is arbitrary. Decorators can be used to manage both instances and classes and intersect most strongly with metaclasses in the second of these roles, but this discrimination is not absolute. In fact, the roles of each are suggested in part by their mechanics.

As we’ll detail ahead, decorators technically correspond to metaclass calls used to make and initialize new classes. Metaclasses, though, have additional customization hooks beyond class creation. Their methods inherited by classes, for example, have no direct counterpart in class decorators sans extra code. This can make metaclasses more complex but also better suited for augmenting classes in some contexts.

Conversely, because metaclasses are designed to manage classes, applying them to managing instances alone is less optimal. Because they are also responsible for making the class itself, metaclasses incur this as an extra step in instance-management roles and are perhaps less appropriate than decorators.

We’ll explore some of these differences in working code later in this chapter. To better understand how metaclasses do their work, though, we first need to get a clearer picture of their underlying model.

Classes Are Instances of type

The first of these prerequisites was covered previously by “The Python Object Model” in Chapter 32, which in turn assumes knowledge of the MRO (method resolution order) covered in Chapter 31. You should review that content now if needed, especially if you’ve jumped into this chapter at random. We’re not going to repeat its coverage in full here, but some of its conclusions are crucial to understanding metaclasses. Namely:

• Instances are created from classes

• Classes are instances of a metaclass

• The type built-in is the topmost metaclass

• Metaclasses customize type with normal class statements

In short, classes are types, types are classes, and metaclasses customize types. Per Chapter 32, the relationship between metaclasses and classes is subtly different from that between classes and their nonclass instances. The latter do not generate more instances, and while attribute inheritance uses the same core mechanisms and MRO everywhere, classes search a metaclass tree that nonclass instances do not.

We’ll study the nuts and bolts of inheritance ahead, but it’s easy to see this model’s fundamentals in code. Built-in objects like lists are actually nonclass instances made from a class, which itself is made from the built-in type:

>>> type([]), type(type([]))         # List instance is created from list class
(<class 'list'>, <class 'type'>)     # List class is created from type class

>>> type(list), type(type)           # Same, but with type names
(<class 'type'>, <class 'type'>)     # Type of type is type: top of hierarchy

Apart from the literal syntax of built-ins, this works the same way for user-defined classes, which are really just user-defined types—their nonclass instances are made from the class, which itself is made from the built-in type:

>>> class Hack: pass                 # User-defined classes work the same
>>> I = Hack()                       # Made from class, which is made from type

>>> type(I), type(type(I))
(<class '__main__.Hack'>, <class 'type'>)

Although their behavior varies in ways we explored in Chapter 32, both classes and nonclass instances are “instances” in some sense. In fact, the __class__ attribute in both tells us what they were made from:

>>> [].__class__, list.__class__     # Instances and classes are both "instances"
(<class 'list'>, <class 'type'>)     # type(X) is normally same as X.__class__

>>> I.__class__, Hack.__class__
(<class '__main__.Hack'>, <class 'type'>)

Because classes are created from the root type class by default, most programmers don’t need to think about this model. However, it’s key to understanding the way that metaclasses work—as the next section explains.

Metaclasses Are Subclasses of Type

Why would we care that classes are instances of a type class? It turns out that this is the hook that allows us to code metaclasses. Specifically, we can create classes from subclasses of type that customize it with normal object-oriented techniques and class syntax. And these type subclasses are known as metaclasses.

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 and default type class.

Before we see how, it’s important to bear in mind that this type instance relationship is not quite the same as normal inheritance. User-defined classes may also have superclasses from which they and their instances inherit attributes as usual. As we’ve seen, inheritance superclasses are listed in parentheses in the class statement, show up in a class’s __bases__ tuple, and are searched for attributes fetched from nonclass instances.

However, the type from which a class is created and of which it is an instance is a different relationship. Inheritance searches instance and class namespace dictionaries, but classes may also acquire behavior from their type that is not exposed to the normal inheritance search. In fact, metaclasses define a separate, secondary inheritance tree available only to classes and used as a fallback when the normal superclass search fails.

To lay the groundwork for understanding this distinction, the next section describes the procedure and syntax Python uses to implement this instance-of relationship.

Class Statements Call a Type

Subclassing the type class to customize it is really only half of the metaclass backstory. We still need to somehow route a class’s creation to the metaclass instead of the default type. To comprehend the way that 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 the class’s 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 corresponding to the class’s local scope, Python calls the type object to create the new class object like this:

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, after which the __init__ method initializes the newly created object. As you’ll see in a moment, these are the hooks that metaclass subclasses of type generally use to perform class customizations at creation time.

For example, given a class definition like the following for Hack:

class Super: …                    # Inherited names here

class Hack(Super):                # Inherits from Super
    data = 1                      # Class data attribute
    def meth(self, arg):          # Class method attribute
        return self.data + arg

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’s processing (extra names like __module__ are added automatically from the code’s context):

Hack = type('Hack', (Super,), {'data': 1, 'meth': meth, '__module__': '__main__'})

In fact, you can call type this way yourself to create a class dynamically—albeit here with a fabricated method function and empty superclasses tuple (Python adds the object superclass automatically to topmost classes as we learned in Chapter 32, and the enclosing module’s name is again implied):

>>> c = type('Hack', (), {'data': 1, 'meth': (lambda x, y: x.data + y)})
>>> i = c()
>>> c, i
(<class '__main__.Hack'>, <__main__.Hack object at 0x108077c20>) 
>>> i.data, i.meth(2)
(1, 3)

The class produced by a direct type call is exactly like that you’d get from running a class statement (again, if you’ve forgotten what some of the following are about, flip, click, or tap back to Chapter 32 for a refresher):

>>> c.__bases__
(<class 'object'>,)
>>> i.__class__.__mro__
(<class '__main__.Hack'>, <class 'object'>)

>>> [a for a in dir(i) if not a.startswith('__')]
['data', 'meth']

>>> [(a, v) for (a, v) in c.__dict__.items() if not a.startswith('__')]
[('data', 1), ('meth', <function <lambda> at 0x1082179c0>)]

Because this type call is made automatically at the end of the class statement, though, it’s an ideal hook for augmenting or otherwise processing a class. The trick lies in replacing the default type with a custom subclass that will intercept this call. The next section shows how.

Class Statements Can Choose a Type

As we’ve just seen, classes are created by the type class by default. To tell Python to create a class with a custom metaclass instead, you simply need to declare a metaclass to intercept the normal instance creation call for a user-defined class. To do so, list the desired metaclass as a keyword argument in the class header:

class Hack(metaclass=Meta):                   # Use Meta instead of type default

If no such declaration is present, the metaclass to be called defaults to the type built-in, per the prior section. When used, though, this declaration overrides the type default and routes the class creation call at the close of the class statement to Meta instead:

class = Meta(classname, superclasses, attributedict)

Importantly again, the metaclass keyword specifies an instance-of relationship, which implies inheritance only through the secondary metaclass tree we’ll formalize ahead. Normal inheritance superclasses can be listed in the header as well and take precedence by residing in the primary class tree. In the following, for example, the new class Hack inherits from superclass Super normally but is also an instance of—and is created by—metaclass Meta:

class Hack(Super, metaclass=Meta):            # Normal supers OK: listed first

In this form, superclasses must be listed before the metaclass; in effect, the ordering rules used for keyword arguments in function calls apply here too. This order also has implications for inheritance, which we’ll formalize soon, but first, we need to learn how to code the metaclasses that tap into calls triggered by this special class syntax.

Metaclass Method Protocol

When a specific metaclass is declared per the prior sections’ syntax, the call to create the class object run at the end of the class statement is modified to invoke the metaclass instead of the type default, as we just saw:

class = Meta(classname, superclasses, attributedict)

Assuming the metaclass is a subclass of type, though, the type class’s inherited __call__ method delegates creation and initialization of the new class object to the metaclass if the metaclass defines custom versions of the methods that handle these steps. In other words, the Meta call may wind up triggering these method calls in turn:

class = Meta.__new__(Meta, classname, superclasses, attributedict)
Meta.__init__(class, classname, superclasses, attributedict)

To demonstrate, here’s the preceding class example again, augmented with a metaclass specification:

class Hack(Super, metaclass=Meta):     # Inherits from Super, instance of Meta
    data = 1                           # Class data attribute
    def meth(self, arg):               # Class method attribute
        return self.data + arg

At the end of this class statement, Python internally runs the following to create the class object—again, a call you could make manually, too, but automatically run by Python’s class machinery:

Hack = Meta('Hack', (Super,), {'data': 1, 'meth': meth, '__module__': '__main__'})

If the metaclass defines its own versions of __new__ or __init__, they will be invoked during this call by the inherited type class’s __call__ method. The net effect is to automatically run methods the metaclass provides as part of the class-construction process. The next section shows how we might go about coding this final piece of the metaclass puzzle.

A Basic Metaclass

Perhaps the simplest metaclass you can code is simply a subclass of type with a __new__ method that creates the class object by running the default method in type. A metaclass __new__ like this is run by the __call__ method inherited from type by virtue of normal inheritance overrides; this method typically performs whatever augmentation is required and calls the type superclass’s __new__ method to create and return the new class object:

class Meta(type):
    def __new__(meta, classname, supers, classdict):
        # Run by inherited type.__call__
        return type.__new__(meta, classname, supers, classdict)

This metaclass doesn’t really do anything (we might as well let the default type create the class), but it demonstrates the way a metaclass taps into the metaclass hook to customize—because the metaclass is called at the end of a class statement, and because the type object’s __call__ dispatches to the __new__ and __init__ methods, code we provide in these methods can manage all the classes created from the metaclass.

To demo, Example 40-1 is our inane metaclass again, but in more tangible form, with prints added to the metaclass and the file at large to trace the process.

class MetaOne(type):
    def __new__(meta, classname, supers, classdict):
        print('In MetaOne.new:', meta, classname, supers, classdict, sep='\n...')
        return type.__new__(meta, classname, supers, classdict)

class Super:
    pass

print('Making class')
class Hack(Super, metaclass=MetaOne):     # Inherits from Super, instance of MetaOne
    data = 1                              # Class data attribute
    def meth(self, arg):                  # Class method attribute
        return self.data + arg

print('Making instance')
X = Hack()
print('Attrs:', X.data, X.meth(2))

Here, class Hack inherits from Super and is an instance of MetaOne, but X is an instance of and inherits from Hack. When run, notice how the metaclass is invoked at the end of the class statement and before we ever make an instance of the new class—metaclasses process classes, and classes process nonclass instances:

$ python3 metaclass1.py
Making class
In MetaOne.new:
...<class '__main__.MetaOne'>
...Hack
...(<class '__main__.Super'>,)
...{'__module__': '__main__', 'data': 1, 'meth': <function Hack.meth at 0x…>}
Making instance
Attrs: 1 3

Presentation note: this chapter’s examples often truncate hex addresses and omit some irrelevant built-in __X__ names in namespace dictionaries, both for brevity and because built-in attributes tend to change over time. Run these examples on your own for full, if transient, fidelity.

Customizing Construction and Initialization

Metaclasses can also tap into the __init__ protocol invoked by the type object’s __call__. In general, __new__ creates and returns the class object, and __init__ initializes the already created class passed in as an argument. These methods work in non-type classes, too, but __new__ is rare in such classes. Metaclasses can use either or both hooks to manage classes at creation time, as Example 40-2 illustrates.

class MetaTwo(type):
    def __new__(meta, classname, supers, classdict):
        print()
        print('In MetaTwo.new:', meta, classname, supers, classdict, sep='\n...')
        return type.__new__(meta, classname, supers, classdict)

    def __init__(Class, classname, supers, classdict):
        print()
        print('In MetaTwo.init:', Class, classname, supers, classdict, sep='\n...')
        print('...init class object:', list(Class.__dict__.keys()))

class Super:
    pass

print('Making class')
class Hack(Super, metaclass=MetaTwo):     # Inherits from Super, instance of MetaTwo
    data = 1                              # Class data attribute
    def meth(self, arg):                  # Class method attribute
       return self.data + arg

print('\nMaking instance')
X = Hack()
print('Attrs:', X.data, X.meth(2))

In this case, the class initialization method is run after the class construction method, but both methods run at the end of the class statement and before any nonclass instances are made. Conversely, an __init__ in Hack would run later at nonclass-instance creation time and would not be affected or run by the metaclass’s __init__:

$ python3 metaclass2.py
Making class
In MetaTwo.new:
...<class '__main__.MetaTwo'>
...Hack
...(<class '__main__.Super'>,)
...{'__module__': '__main__', 'data': 1, 'meth': <function Hack.meth at 0x…>}

In MetaTwo.init:
...<class '__main__.Hack'>
...Hack
...(<class '__main__.Super'>,)
...{'__module__': '__main__', 'data': 1, 'meth': <function Hack.meth at 0x…>}
...init class object: ['__module__', 'data', 'meth', '__doc__']

Making instance
Attrs: 1 3

Other Metaclass Coding Techniques

Although redefining the type superclass’s __new__ and __init__ methods is the most common way to insert logic into the class object creation process with the metaclass hook, other schemes are possible. They may not dovetail as neatly into the notion of metaclass methods we’ll study ahead, but they do support creation-time tasks.

# A simple function can serve as a metaclass too

def MetaFunc(classname, supers, classdict):
    print('In MetaFunc:', classname, supers, classdict, sep='\n...')
    return type(classname, supers, classdict)

class Super:
    pass

print('Making class')
class Hack(Super, metaclass=MetaFunc):           # Run simple function at end
    data = 1                                     # Function returns class
    def meth(self, arg):
        return self.data + arg

print('Making instance')
X = Hack()
print('Attrs:', X.data, X.meth(2))

$ python3 metaclass3.py
Making class
In MetaFunc:
...Hack
...(<class '__main__.Super'>,)
...{'__module__': '__main__', 'data': 1, 'meth': <function Hack.meth at 0x…>}
Making instance
Attrs: 1 3

# A normal class instance can serve as a metaclass too

class MetaObj:
    def __call__(self, classname, supers, classdict):
        print('In MetaObj.call:', classname, supers, classdict, sep='\n...')
        Class = self.__New__(classname, supers, classdict)
        self.__Init__(Class, classname, supers, classdict)
        return Class

    def __New__(self, classname, supers, classdict):
        print('In MetaObj.new: ', classname, supers, classdict, sep='\n...')
        return type(classname, supers, classdict)

    def __Init__(self, Class, classname, supers, classdict):
        print('In MetaObj.init:', classname, supers, classdict, sep='\n...')
        print('...init class object:', list(Class.__dict__.keys()))

class Super:
    pass

print('Making class')
class Hack(Super, metaclass=MetaObj()):         # MetaObj() is normal class instance
    data = 1                                    # Called at end of statement
    def meth(self, arg):
        return self.data + arg

print('Making instance')
X = Hack()
print('Attrs:', X.data, X.meth(2))

$ python3 metaclass4.py
Making class
In MetaObj.call:
...Hack
...(<class '__main__.Super'>,)
...{'__module__': '__main__', 'data': 1, 'meth': <function Hack.meth at 0x…>}
In MetaObj.new: 
...Hack
...(<class '__main__.Super'>,)
...{'__module__': '__main__', 'data': 1, 'meth': <function Hack.meth at 0x…>}
In MetaObj.init:
...Hack
...(<class '__main__.Super'>,)
...{'__module__': '__main__', 'data': 1, 'meth': <function Hack.meth at 0x…>}
...init class object: ['__module__', 'data', 'meth', '__doc__']
Making instance
Attrs: 1 3

# Instances inherit from classes and their supers normally

class SuperMetaObj:
    def __call__(self, classname, supers, classdict):
        print('In SuperMetaObj.call:', classname, supers, classdict, sep='\n...')
        Class = self.__New__(classname, supers, classdict)
        self.__Init__(Class, classname, supers, classdict)
        return Class

class SubMetaObj(SuperMetaObj):
    def __New__(self, classname, supers, classdict):
        print('In SubMetaObj.new: ', classname, supers, classdict, sep='\n...')
        return type(classname, supers, classdict)

    def __Init__(self, Class, classname, supers, classdict):
        print('In SubMetaObj.init:', classname, supers, classdict, sep='\n...')
        print('...init class object:', list(Class.__dict__.keys()))

class Super:
    pass

print('Making class')
class Hack(Super, metaclass=SubMetaObj()):   # Invoke Sub instance via Super.__call__
   …rest of file same as Example 40-4…

$ python3 metaclass5.py 
Making class
In SuperMetaObj.call:
…as before…
In SubMetaObj.new:
…as before…
In SubMetaObj.init:
…as before…
Making instance
Attrs: 1 3

Managing Classes with Metaclasses and Decorators

Now that we understand the hook metaclasses use to insert code to be run at class construction time, let’s put it to better use. In general, such code can be used to augment classes arbitrarily, and in many of the same ways as the class decorators of the online-only “Decorators” chapter. This doesn’t make these two tools identical—metaclasses also support the notion of inherited methods coming up later—but they are functionally redundant in some roles.

"Extend a class with a metaclass"

def triple(obj):
    return obj.value * 3                                  # Functions to insert
                                                          # Methods if in a class
def concat(obj):                                          # Where "obj" is "self"
    return obj.value + 'Code!'

class Extender(type):
    def __new__(meta, classname, supers, classdict):      # On client-class creation
        classdict['triple'] = triple                      # Add funcs as attributes 
        classdict['concat'] = concat
        return type.__new__(meta, classname, supers, classdict)

class Client1(metaclass=Extender):
    def __init__(self, value):                            # Created from Extender
        self.value = value                                # Own + inserted methods
    def double(self):
        return self.value * 2

class Client2(metaclass=Extender):                        # Created from Extender
    value = 'grok'                                        # Inherited class data

X = Client1('hack')                                       
print(X.double(), X.triple(), X.concat(), sep='\n')

Y = Client2()                                             
print(Y.triple(), Y.concat(), sep='\n')

$ python3 extend_meta.py
hackhack
hackhackhack
hackCode!
grokgrokgrok
grokCode!

"Extend a class with a decorator"

def triple(obj):
    return obj.value * 3

def concat(obj):
    return obj.value + 'Code!'

def extender(aClass):
    aClass.triple = triple                   # Manages class, not instance
    aClass.concat = concat                   # Same as metaclass __call__
    return aClass

@extender
class Client1:                               # Client1 = Extender(Client1)
    def __init__(self, value):               # Rebound at end of class stmt
        self.value = value
    def double(self):
        return self.value * 2

@extender
class Client2:
    value = 'grok'

X = Client1('hack')                                       
print(X.double(), X.triple(), X.concat(), sep='\n')

Y = Client2()                                             
print(Y.triple(), Y.concat(), sep='\n')

import time

def tracer(func):                         # Use function, not class with __call__
    calls = 0                             # Else self is decorator instance only
    def onCall(*args, **kwargs):
        nonlocal calls
        calls += 1
        print(f'call {calls} to {func.__name__}')
        return func(*args, **kwargs)
    return onCall

def timer(label='', trace=True):                # On decorator args: retain args
    def onDecorator(func):                      # On @: retain decorated func
        def onCall(*args, **kargs):             # On calls: call original
            start   = time.perf_counter()       # State is scopes + func attribute
            result  = func(*args, **kargs)
            elapsed = time.perf_counter() - start
            onCall.alltime += elapsed
            if trace:
                funcname, alltime = func.__name__, onCall.alltime
                print(f'{label}{funcname}: {elapsed:.5f}, {alltime:.5f}')
            return result
        onCall.alltime = 0
        return onCall
    return onDecorator

"Apply any decorator to all methods of a class, with a metaclass"

from types import FunctionType
from decorators import tracer, timer

def decorateAll(decorator):
    class MetaDecorate(type):
        def __new__(meta, classname, supers, classdict):
            for attr, attrval in classdict.items():
                if type(attrval) is FunctionType:
                    classdict[attr] = decorator(attrval)
            return type.__new__(meta, classname, supers, classdict)
    return MetaDecorate

class Person(metaclass=decorateAll(tracer)):       # Use a metaclass
    def __init__(self, name, pay):                 # Pass any function decorator
        self.name = name
        self.pay  = pay
    def giveRaise(self, percent):
        self.pay *= (1.0 + percent)
    def lastName(self):
        return self.name.split()[-1]

def tester(aPerson):
    sue = aPerson('Sue Jones', 100_000)
    bob = aPerson('Bob Smith', 50_000)
    print(f'{sue.name=}, {bob.name=}')
    sue.giveRaise(.10) 
    print(f'{sue.pay=:,.2f}')
    print('Last names:', sue.lastName(), bob.lastName())

if __name__ == '__main__': tester(Person)

$ python3 decoall_meta.py
call 1 to __init__
call 2 to __init__
sue.name='Sue Jones', bob.name='Bob Smith'
call 1 to giveRaise
sue.pay=110,000.00
call 1 to lastName
call 2 to lastName
Last names: Jones Smith

class Person(metaclass=decorateAll(tracer)):               # Apply tracer
class Person(metaclass=decorateAll(timer())):              # Apply timer, defaults
class Person(metaclass=decorateAll(timer(label='**'))):    # Decorator arguments

"Apply any decorator to all methods of a class, with a decorator"

from types import FunctionType
from decoall_meta import tester
from decorators import tracer, timer

def decorateAll(decorator):
    def DecoDecorate(aClass):
        for attr, attrval in aClass.__dict__.items():
            if type(attrval) is FunctionType:
                setattr(aClass, attr, decorator(attrval))    # Not __dict__
        return aClass
    return DecoDecorate

@decorateAll(tracer)                          # Use class deco, pass any func deco
class Person:                                 # Applies func decorator to methods
    def __init__(self, name, pay):            # Person = decorateAll(..)(Person)
        self.name = name                      # Person = DecoDecorate(Person)
        self.pay  = pay
    def giveRaise(self, percent):
        self.pay *= (1.0 + percent)
    def lastName(self):
        return self.name.split()[-1]

if __name__ == '__main__': tester(Person)

$ python3 decoall_deco.py
…same as Example 40-9…

@decorateAll(tracer)                        # Apply tracer
@decorateAll(timer())                       # Apply timer, defaults
@decorateAll(timer(label='**'))             # Decorator arguments
@decorateAll(timer(label='**', trace=0))    # More decorator arguments

Metaclass Versus Superclass

In even simpler terms, watch what happens in the following: as an instance of the M metaclass type, class C acquires M’s attribute, but this attribute is not made available for inheritance by C’s own instance I—the acquisition of names by metaclass instances is distinct from the normal inheritance used for nonclass instances:

>>> class M(type): attr = 1
>>> class C(metaclass=M): pass         # C is meta instance and acquires meta attr
>>> I = C()                            # I inherits from class but not meta!
>>> C.attr
1
>>> I.attr
AttributeError: 'C' object has no attribute 'attr' 
>>> 'attr' in C.__dict__, 'attr' in M.__dict__
(False, True)

By contrast, if M morphs from metaclass to superclass, then names in superclass S become available to later instances of C by inheritance—that is, by searching the __dict__ attribute dictionaries of objects in the MRO of I’s class as usual, much like the mapattrs example we coded back in Chapter 32 (a nonclass-instance-only tool):

>>> class S: attr = 1
>>> class C(S): pass                   # C is type instance and inherits from supers
>>> I = C()                            # I inherits from class and supers
>>> C.attr
1
>>> I.attr
1
>>> 'attr' in C.__dict__, 'attr' in S.__dict__
(False, True)

This is why metaclasses often do their work by manipulating a new class’s namespace dictionary if they wish to influence the behavior of later instance objects—instances will see names in their class but not its metaclass. Watch what happens, though, if the same name is available in both attribute sources—the inheritance name in the primary superclass tree is used instead of the instance acquisition name in the secondary metaclass tree:

>>> class M(type): attr = 1
>>> class S: attr = 2
>>> class C(S, metaclass=M): pass       # Supers have precedence over metas
>>> I = C()                             # Classes search supers before metas
>>> C.attr, I.attr                      # Instance search only supers
(2, 2)
>>> 'attr' in C.__dict__, 'attr' in S.__dict__, 'attr' in M.__dict__
(False, True, True)

This is true regardless of the relative height of the inheritance and instance sources—superclass inheritance always beats metaclass acquisition because primary trees are searched before secondary trees:

>>> class M(type): attr = 1
>>> class S2: attr = 2
>>> class S1(S2): pass
>>> class C(S1, metaclass=M): pass      # Super two levels above meta: still wins
>>> I = C()
>>> C.attr, I.attr
(2, 2)

In fact, classes acquire metaclass attributes through their __class__ link, in the same way that nonclass instances inherit from classes through their __class__—which makes sense, given that classes are also instances of metaclasses. The chief distinction is that instance inheritance does not also follow a class’s __class__ but instead restricts its scope to the __dict__ of each class in the superclass tree, following __bases__ along the way:

>>> I.__class__                # Followed by inheritance: instance's class
<class '__main__.C'>
>>> C.__bases__                # Followed by inheritance: class's supers
(<class '__main__.S1'>,) 
>>> C.__class__                # Followed by instance acquisition: metaclass
<class '__main__.M'>

Really, though, Python checks the __dict__ of each class on the class’s MRO before falling back on doing the same for its metaclass—and runs the second of these steps only for fetches run on classes, not nonclass instances:

>>> [x.__name__ for x in C.__mro__]     # See Chapter 32 for all things MRO
['C', 'S1', 'S2', 'object']
>>> [x.__name__ for x in M.__mro__]     # Primary/secondary trees: class/meta
['M', 'type', 'object']

These two MROs for class and metaclass are simply the flattened versions of what we called the primary and secondary class trees earlier. Nonclass-instance inheritance searches just the first, but class inheritance searches both if needed. In fact, metaclasses work in much the same way, as the next section explains.

Metaclass Inheritance

As it turns out, instance inheritance works in similar ways, whether the “instance” is a nonclass instance created from a class or a class created from a metaclass derived from type. While classes straddle the primary and secondary trees, both trees use the same mechanism to look up names. This yields a single attribute search procedure spanning two trees, which fosters the parallel notion of metaclass inheritance hierarchies.

The following demos this conceptual merger. In it, instance I inherits from all its classes; class C inherits from both superclasses and metaclasses; and metaclass M1 inherits from higher metaclasses:

>>> class M2(type): attr4 = 4                 # Metaclass inheritance tree
>>> class M1(M2):   attr3 = 3                 # Gets __bases__, __class__, __mro__

>>> class S: attr2 = 2                        # Superclass inheritance tree
>>> class C(S, metaclass=M1): attr1 = 1       # Gets __bases__, __class__, __mro__

>>> I = C()                                   # I gets __class__ but not others
>>> I.attr1, I.attr2                          # Instance inherits from super tree
(1, 2) 
>>> C.attr1, C.attr2, C.attr3, C.attr4        # Class gets names from both trees!
(1, 2, 3, 4) 
>>> M1.attr3, M1.attr4                        # Metaclass inherits names too!
(3, 4)
>>> I.attr3
AttributeError: 'C' object has no attribute 'attr3'. Did you mean: 'attr1'?

The failure at the end of this listing is pivotal. Both inheritance paths—class and metaclass—employ the same links to build class MROs scanned by inheritance. But this is not applied transitively—instances do not inherit their class’s metaclass names, though they may request them explicitly:

>>> I.__class__                # Links used at instance with no __bases__
<class '__main__.C'>
>>> C.__bases__
(<class '__main__.S'>,) 

>>> C.__class__                # Links used at class after its __bases__
<class '__main__.M1'>
>>> M1.__bases__               # Link also used in metaclass inheritance
(<class '__main__.M2'>,) 

>>> I.__class__.attr4          # Route inheritance to the class's meta tree
4
>>> I.attr4                    # Though class's __class__ not followed normally
AttributeError: 'C' object has no attribute 'attr4'. Did you mean: 'attr1'?

And as usual, both trees have flattened MROs and instance links actually used by inheritance:

>>> M1.__class__                        # Metaclasses are classes too
<class 'type'>
>>> [x.__name__ for x in C.__mro__]     # __bases__ tree from I.__class__
['C', 'S', 'object']
>>> [x.__name__ for x in M1.__mro__]    # __bases__ tree from C.__class__
['M1', 'M2', 'type', 'object']

If you care about metaclasses—or must use code that does—study these examples carefully. In effect, nonclass instances have no __bases__ to search but follow __class__ to __bases__ once, and classes follow __bases__ before following a single __class__ to another __bases__. Because this is crucial to the meaning of attribute names in Python, the next section begins making it more formal.

Python Inheritance Algorithm: The Simple Version

Now that we know about metaclass acquisition, we’re finally able to formalize the inheritance rules that they augment. Inheritance deploys two distinct but similar lookup routines, both of which are founded on MROs computed from the prior section’s __bases__ links per Chapter 32. The combination yields the following first-cut definition of Python’s attribute inheritance algorithm run for explicit attribute fetches:

To look up an explicit attribute name:

1. From a nonclass instance I, search the instance, then its class, and then all its superclasses, using:

   1. The __dict__ of the instance I

   2. The __dict__ of all classes on the __mro__ found at I’s __class__, from left to right

2. From a class C, search the class, then all its superclasses, and then its metaclasses tree, using:

   1. The __dict__ of all classes on the __mro__ found at C itself, from left to right

   2. The __dict__ of all metaclasses on the __mro__ found at C’s __class__, from left to right

3. In rules 1 and 2, also allow for these exceptions covered ahead:

   • Give precedence to data descriptors present in step b sources

   • Skip step a and begin the search at step b for built-in operations

   • Perform a custom MRO search for a proxied object in super objects

Rules 1 and 2 are applied for normal, explicit attribute fetch only, and there are exceptions for built-ins, descriptors, and super, which we’ll clarify in a moment. In addition, a __getattr__ or __getattribute__ may also be used for missing or all names, respectively, per the online-only “Managed Attributes” chapter, and attribute assignment follows different rules.

The first two rules here, however, are the essentials. They specify the inheritance search of two separate trees, which works the same in each tree but spans trees for class inheritance alone. The MRO pseudocode of Chapter 32 summarizes this even more concisely:

[I.__dict__] + [x.__dict__ for x in I.__class__.__mro__]

[x.__dict__ for x in C.__mro__] + [x.__dict__ for x in C.__class__.__mro__]

In this, the first line is sources searched by rule 1 for inheritance from a nonclass instance I—both the instance itself and the flattened version of the primary class tree. The second line is rule 2’s sources for inheritance from a class C—the flattened versions of both the primary class tree and the secondary metaclass tree.

Put another way, nonclass instances and classes both search a class tree’s MRO at their __class__ as a second step, but classes first search their own MRO’s superclass tree instead of a single __dict__ namespace dictionary. In code, class header lines define both of the trees searched by listing superclasses and specify links to secondary trees with metaclass keywords. When omitted, superclass defaults to object and metaclass to type.

Most programmers need only be aware of the first of these rules (1) and perhaps the first step of the second (2a). There’s an extra acquisition step added for metaclasses (2b), but it’s essentially the same as others—a subtle equivalence, to be sure, but metaclass acquisition is not as novel as it may seem. It’s just one step of the procedure.

>>> class C: pass                          # Inheritance special case...
>>> I = C()                                # Class data descriptors have precedence
>>> I.__class__, I.__dict__
(<class '__main__.C'>, {})

>>> I.__dict__['book'] = 'lp6e'            # Dynamic data in the instance
>>> I.__dict__['__class__'] = 'hack'       # Assign keys, not attributes
>>> I.__dict__['__dict__']  = {}

>>> I.book                                 # I.name comes from I.__dict__ as usual
'lp6e'                                     # But I.__class__ and I.__dict__ do not!
>>> I.__class__, I.__dict__
(<class '__main__.C'>, {'book': 'lp6e', '__class__': 'hack', '__dict__': {}})

>>> class D:
        def __get__(self, instance, owner): print('D.__get__')
        def __set__(self, instance, value): print('D.__set__')

>>> class C: d = D()            # Data-descriptor attribute
>>> I = C()
>>> I.d                         # Inherited data descriptor access
D.__get__ 
>>> I.d = 1
D.__set__ 
>>> I.__dict__['d'] = 'hack'    # Define same name in instance namespace dict
>>> I.d                         # But doesn't hide data descriptor in class!
D.__get__

>>> class D:
        def __get__(self, instance, owner): print('D.__get__')

>>> class C: d = D()
>>> I = C()
>>> I.d                         # Inherited nondata descriptor access
D.__get__ 
>>> I.__dict__['d'] = 'hack'    # Hides class names per normal inheritance rules
>>> I.d
'hack'

Python Inheritance Algorithm: The Less Simple Version

With both the data descriptor special case and general descriptor invocation factored in with class and metaclass trees, Python’s formal inheritance algorithm can be stated as follows—a complex procedure which assumes knowledge of descriptors, metaclasses, and MROs but is the final arbiter of attribute names nonetheless:

To look up an explicit attribute name:

1. From a nonclass instance I, search the instance, its class, and its superclasses, as follows:

   1. Search the __dict__ of all classes on the __mro__ found at I’s __class__

   2. If a data descriptor was found in step a, call its __get__ and exit

   3. Else, return a value in the __dict__ of the instance I

   4. Else, call a nondata descriptor or return a value found in step a

2. From a class C, search the class, its superclasses, and its metaclasses tree as follows:

   1. Search the __dict__ of all metaclasses on the __mro__ found at C’s __class__

   2. If a data descriptor was found in step a, call its __get__ and exit

   3. Else, call any descriptor or return a value in the __dict__ of a class on C’s own __mro__

   4. Else, call a nondata descriptor or return a value found in step a

3. In rules 1 and 2, built-in operations essentially use just step a sources (see ahead)

4. The super built-in performs a custom MRO search for a proxied object (see ahead)

Some fine print here: in this procedure, items are attempted in sequence as numbered, and Python runs at most one (for instances) or two (for classes) MRO searches per name lookup—the first appearance of a name in a given MRO wins, regardless of its kind. Because each MRO (a.k.a. __mro__) is a flattened representation of a class tree with duplicates removed, you can also think of these as one or two tree searches.

In addition, the implied object superclass provides some defaults at the top of every class and metaclass tree (that is, at the end of every MRO). And beyond all this, method __getattr__ may be run if defined when an attribute is not found, and method __getattribute__ may be run for every attribute fetch, though they are special-case extensions to the name lookup model (really, the latter replaces inheritance for the defining class’s instances, and can trigger the former with an attribute exception). See the online-only “Managed Attributes” chapter for more on these tools as well as descriptors.

Also, note here again that this algorithm applies only to normal and explicit attribute fetch. The rules for attribute assignment vary; the implicit lookup of method names for built-ins doesn’t follow these rules in full; and the proxied lookup of attributes performed by super is entirely custom. The next sections cover these exceptions separately.

>>> class C:                              # Inheritance special case...
        attr = 1                          # Built-ins skip a step
        def __str__(self): return('class')

>>> I = C()
>>> I.__str__(), str(I)                   # Both from class if not in instance
('class', 'class')

>>> I.__str__ = lambda: 'instance'
>>> I.__str__(), str(I)                   # Explicit=>instance, built-in=>class!
('instance', 'class')

>>> I.attr                                # Asymmetric with normal or explicit names
1
>>> I.attr = 2; I.attr
2

>>> class D(type):
        def __str__(self): return('D class')
>>> class C(D):
        pass
>>> C.__str__(C), str(C)                  # Explicit=>super, built-in=>metaclass!
('D class', "<class '__main__.C'>")

>>> class C(D):
        def __str__(self): return('C class')
>>> C.__str__(C), str(C)                  # Explicit=>class, built-in=>metaclass!
('C class', "<class '__main__.C'>")

>>> class C(metaclass=D):
        def __str__(self): return('C class')
>>> C.__str__(C), str(C)                  # Built-in=>user-defined metaclass
('C class', 'D class')

>>> class C(metaclass=D):
        pass
>>> C.__str__(C), str(C)                  # Explicit=>object, built-in=>metaclass
("<class '__main__.C'>", 'D class')

>>> C.__str__
<slot wrapper '__str__' of 'object' objects>

>>> for k in (C, C.__class__, type): 
        print([x.__name__ for x in k.__mro__])
['C', 'object']
['D', 'type', 'object']
['type', 'object']

The Inheritance Wrap-Up

And with all those details in hand, you finally have the complete Python inheritance story—or at least as much as we can cover in this text. It’s a tangled tale that today spans instances, classes, superclasses, metaclasses, descriptors, super, built-ins, and MROs, and all for the sake of looking up a simple attribute name.

Some practical needs warrant exceptions, of course, but you should carefully consider the implications of an object-oriented language that applies inheritance—its foundational operation—in such a labyrinthian fashion. At a minimum, this should underscore the importance of keeping your own code simple to avoid making it dependent on the darker corners of such convoluted rules. As always, your code’s users and maintainers will be glad you did.

For more fidelity on this story, see Python’s internal implementation of inheritance—a low-level but complete saga chronicled today in its files object.c and typeobject.c, the former for normal instances and the latter for classes. Delving into internals shouldn’t be required to use Python, but it’s the ultimate and sometimes sole source of truth in a complex and perpetually changing system. This is especially true in boundary cases born of accrued exceptions that raise the bar for learners and users, a downside we’ll revisit briefly in the next and closing chapter.

For now, let’s move on to one last bit of metaclass “magic”—its methods, which rely on its inheritance offshoot.

Metaclass Methods Versus Class Methods

Though they differ in inheritance visibility, metaclass methods are designed to manage class-level data, just like the class methods we studied in Chapter 32. In fact, their roles can overlap—much as metaclasses can in general with class decorators—but metaclass methods are not accessible except through the class and do not require an explicit classmethod class-level declaration in order to be bound with the class.

In other words, metaclass methods can be thought of as implicit class methods, with limited visibility:

>>> class M(type):
        def a(cls):                        # Metaclass method: gets class
            cls.x = cls.y + cls.z

>>> class C(metaclass=M):
         y, z = 11, 22
         @classmethod                      # Class method: gets class
         def b(cls):
             return cls.x

>>> C.a()            # Call metaclass method; visible to class only
>>> C.x              # Creates class data on C, accessible to normal instances
33

>>> I = C()
>>> I.x, I.y, I.z
(33, 11, 22)

>>> I.b()            # Class method: sends class, not instance; visible to instance
33
>>> I.a()            # Metaclass methods: accessible through class only
AttributeError: 'C' object has no attribute 'a'

This yields two very different ways to create class methods whose asymmetry is left as suggested pondering here.

Operator Overloading in Metaclass Methods

Just in case your head is not yet spinning, metaclasses, just like normal classes, may also employ operator overloading to make built-in operations applicable to their instance classes. The __getitem__ indexing method in the following metaclass, for example, is a metaclass method designed to process classes themselves—the classes that are instances of the metaclass, not those classes’ own nonclass instances:

>>> class M(type):
        def __getitem__(cls, i):         # Meta method for processing classes:
            return cls.data[i]           #  Built-ins skip class, use meta
                                         #  Explicit names search class + meta
>>> class C(metaclass=M):                #  Data descriptors in meta used first
        data = 'hack'

>>> C[0]                  # Metaclass instance names: visible to class only
'h'
>>> C.__getitem__
<bound method M.__getitem__ of <class '__main__.C'>>

>>> I = C()
>>> I.data, C.data        # Normal inheritance names: visible to instance and class
('hack', 'hack') 
>>> I[0]
TypeError: 'C' object is not subscriptable

And if that’s not abstruse enough, when both class and metaclass overload the same operator, the former applies to classes and the latter to nonclass instances:

>>> class C(metaclass=M):
        data = 'hack'
        def __getitem__(self, i):
            return self.data[i]
 
>>> I = C()
>>> I.data = 'code'
>>> C[0], I[0]            # C's [] from metaclass, I's [] from class 
('h', 'c')

All of which leads us to the closing compare-and-contrast of the next section.

Metaclass Methods Versus Instance Methods

The inescapable conclusion of this technical novel is that metaclass methods provide a separate—and arguably redundant—way to code object behavior with classes in Python. As we’ve learned, the usual way to implement objects is with classes and their nonclass instances. Here’s the normal case—with class data, constructor, regular method, and operator overloading available to instances and subclasses:

>>> class Employee:                               # A "normal" class
        rate = 50                                 # With shared class data
        def __init__(self, name, hours):          # Plus instance data and methods
            self.name = name
            self.hours = hours
        def pay(self):
            print(f'💰 {self.name} ⇨ ${self.rate * self.hours:,.2f}')
        def __iadd__(self, hours):
            self.hours += hours
            return self

As usual, we make an instance of a normal class like this by calling it with constructor arguments:

>>> pat = Employee('Pat', 2_000)                  # A "normal" nonclass instance
>>> pat.pay()                                     # Methods inherited from class
💰 Pat ⇨ $100,000.00
>>> pat += 1_000                                  # Updates instance data
>>> pat.pay()
💰 Pat ⇨ $150,000.00

And to make more instances, we simply call the class again:

>>> pat2 = Employee('Pat2', 1_000)                # Another "normal" instance
>>> pat2.pay()
💰 Pat2 ⇨ $50,000.00
>>> pat2
<__main__.Employee object at 0x10cf5c680>

The equivalent metaclass can also provide data, regular methods, and operator overloading. But per-instance constructors don’t quite apply; methods receive and process a class, not instances of it; and this behavior is for subclasses and instance classes in the secondary “type” tree only:

>>> class MetaEmployee(type):                     # A metaclass class
        rate = 50                                 # With metaclass data and methods
        def pay(cls):
            print(f'💰 {cls.name} ⇨ ${cls.rate * cls.hours:,.2f}')
        def __iadd__(cls, hours):
            cls.hours += hours
            return cls

Because metaclass instances are classes, we define a new class per instance instead of running a call and code instance data as class attributes, though all the behavior defined in the metaclass applies to its instance classes:

>>> class pat(metaclass=MetaEmployee):            # A metaclass instance: class
        name = 'Pat'                              # With class data per instance
        hours = 2_000
 
>>> pat.pay()                                     # Methods inherited from metaclass
💰 Pat ⇨ $100,000.00
>>> pat += 1_000                                  # Updates class data
>>> pat.pay()
💰 Pat ⇨ $150,000.00

We haven’t made any normal instances here—just a class that nevertheless serves as an information record with both data and behavior methods. Coding differences aside, the main functional divergence in the metaclass approach is that nonclass instances created from such a class don’t inherit any of the behavior defined in a metaclass:

>>> pat2 = pat()                                  # A "normal" instance of class pat
>>> pat2.pay()                                    # Metaclass behavior not available
AttributeError: 'pat' object has no attribute 'pay'

To make additional instances in the metaclass world, we must instead code additional classes:

>>> class pat2(metaclass=MetaEmployee):           # Metaclass instances are classes
        name = 'Pat2'
        hours = 1_000
 
>>> pat2.pay()                                    # With all metaclass data+methods
💰 Pat2 ⇨ $50,000.00

Calling the metaclass with no arguments doesn’t work at all because it makes a class, not an instance of a class—though calling the metaclass with full type arguments does work because it’s equivalent to running a class statement (and yes, the fact that metaclasses are classes, too, makes some of this paragraph’s logic circular, but that’s just how Python works: metaclasses are special-cased for metaclass roles):

>>> pat2 = MetaEmployee('pat2', (), dict(name='Pat2', hours=1_000))
>>> pat2.pay()
💰 Pat2 ⇨ $50,000.00
>>> pat2
<class '__main__.pat2'>

In sum, metaclasses allow us to implement classes that work much like the nonclass instances we’ve used throughout this book. As to why you’d want to swap one kind of instance for another with identical functionality but different coding, we’ll have to defer to other resources to justify the redundancy. Given the many convolutions that metaclasses bring to the table, it’s difficult not to see this as complexity for all in the name of rare and narrow roles. While that has been a recurring theme in both Python and this book, it’s time to wrap up and move on to the conclusion.