>>> class Foobar:

...     pass

...

>>> type(Foobar)

<class 'type'>

>>> foo = Foobar()

>>> type(foo)

<class '__main__.Foobar'>

>>> isinstance(foo, Foobar)

True

>>> isinstance(Foobar, type)

True

Simple metaclass use*

We can use type directly to make a class, without any class statement:

>>> MyClass = type('MyClass', (), {})

>>> MyClass

<class '__main__.MyClass'>

The class statement isn't just syntactic sugar, it does some extra things, like setting the __module__, __qualname__ or __doc__ properties.

We can make a custom metaclass:

>>> class Meta(type):

...     pass

And then we can use it [15]:

>>> class Complex(metaclass=Meta):

...     pass

>>> type(Complex)

<class '__main__.Meta'>

Now we got a rough idea of what we'll be dealing with ...

>>> class Funky:

...     def __call__(self):

...         print("Look at me, I work like a function!")

>>> f = Funky()

>>> f()

Look at me, I work like a function!

The slots*

When you define a magic method in your class the function won't end up in a dictionary, it will end up as a pointer in a struct that describes the class. That struct [7] has a field for each magic method. For some reason these fields are called type slots.

Now there's another feature, implemented via the __slots__ attribute [17]. A class with __slots__ will create instances that don't have a __dict__ (they use a little bit less memory). A side-effect of this is that instances cannot have other fields than what was specified in __slots__: if you try to set an unexpected field you'll get an exception.

For the scope of this article when slots are mentioned it will mean the type slots, not __slots__.

Object attribute lookup*

Now this is something that's easy to get wrong because of the many slight differences to old-style objects in Python 2. [5]

Assuming Class is the class and instance is an instance of Class, evaluating instance.foobar roughly equates to this:

• Call the type slot for Class.__getattribute__ (tp_getattro). The default does this: [10]
  • Does Class.__dict__ have a foobar item that is a data descriptor [8]?
    • If yes, return the result of Class.__dict__['foobar'].__get__(instance, Class). [6]
  • Does instance.__dict__ have a foobar item in it?
    • If yes, return instance.__dict__['foobar'].
  • Does Class.__dict__ have a foobar item that is not a data descriptor [9]?
    • If yes, return the result of Class.__dict__['foobar'].__get__(instance, klass). [6]
• If the attribute still wasn't found, call the type slot for Class.__getattr__ (tp_name).

Still not clear? Perhaps a diagram normal attribute lookup helps:

To avoid creating confusions with the “.” operator doing crazy things I've used “:” in this diagram to signify the location.

Class attribute lookup*

Because classes needs to be able support the classmethod and staticmethod properties [6] when you evaluate something like Class.foobar the lookup is slightly different than what would happen when you evaluate instance.foobar.

Assuming Class is an instance of Metaclass, evaluating Class.foobar roughly equates to this:

• Call the type slot for Metaclass.__getattribute__ (tp_getattro). The default does this: [11]
  • Does Metaclass.__dict__ have a foobar item that is a data descriptor [8]?
    • If yes, return the result of Metaclass.__dict__['foobar'].__get__(Class, Metaclass). [6]
  • * Does Class.__dict__ have a foobar item that is a descriptor (of any kind)?
    • If yes, return the result of Class.__dict__['foobar'].__get__(None, Class). [6]
  • Does Class.__dict__ have a foobar item in it?
    • If yes, return Class.__dict__['foobar'].
  • Does Metaclass.__dict__ have a foobar item that is not a data descriptor [9]?
    • If yes, return the result of Class.__dict__['foobar'].__get__(instance, klass). [6]
• If the attribute still wasn't found, call the type slot for __getattr__ (tp_name).

The whole shebang would look like this in a diagram:

To avoid creating confusions with the “.” operator doing crazy things I've used “:” in this diagram to signify the location.

Magic method lookup*

For magic methods the lookup is done on the class, directly in the big struct with the slots: [12]

• Does the object's class have a slot for that magic method (roughly object->ob_type->tp_<magicmethod> in C code)? If yes, use it. If it's NULL then the operation is not supported.

In C internals parlance:

• object->ob_type is the class of the object.
• ob_type->tp_<magicmethod> is the type slot.

This looks much simpler, however, the type slots are filled with wrappers around your functions, so descriptors work as expected: [12]

>>> class Magic:

...     @property

...     def __repr__(self):

...         def inner():

...             return "It works!"

...         return inner

...

>>> repr(Magic())

'It works!'

Thats it. Does that mean there are places that don't follow those rules and lookup the slot differently? Sadly yes, read on ...

The __new__ method*

One of the most common point of confusion with both classes and metaclasses is the __new__ method. It has some very special conventions.

The __new__ method is the constructor (it returns the new instance) while __init__ is just a initializer (the instance is already created when __init__ is called).

Suppose have a class like this: [20]

class Foobar:

    def __new__(cls):

        return super().__new__(cls)

Now if you recall the previous section, you'd expect that __new__ would be looked up on the metaclass, but alas, it wouldn't be so useful that way [19] so it's looked up statically.

When the Foobar class wants this magic method it will be looked up on the same object (the class), not on a upper level like all the other magic methods. This is very important to understand, because both the class and the metaclass can define this method:

• Foobar.__new__ is used to create instances of Foobar
• type.__new__ is used to create the Foobar class (an instance of type in the example)

The __prepare__ method*

This method is called before the class body is executed and it must return a dictionary-like object that's used as the local namespace for all the code from the class body. It was added in Python 3.0, see PEP-3115.

If your __prepare__ returns an object x then this:

class Class(metaclass=Meta):

    a = 1

    b = 2

    c = 3

Will make the following changes to x:

x['a'] = 1

x['b'] = 2

x['c'] = 3

This x object needs to look like a dictionary. Note that this x object will end up as an argument to Metaclass.__new__ and if it's not an instance of dict you need to convert it before calling super().__new__. [21]

Interestingly enough this method doesn't have __new__'s special lookup. It appears it doesn't have it's own type slot and it's looked up via the class attribute lookup, if you read back a bit. [6]

Metaclasses are callables*

If you look again at the diagrams, you'll notice that making an instance goes through Metaclass.__call__. This means you can use any callable as the metaclass:

>>> class Foo(metaclass=print):  # pointless, but illustrative

...     pass

...

Foo () {'__module__': '__main__', '__qualname__': 'Foo'}

>>> print(Foo)

None

If you use a function as the metaclass then subclasses won't inherit your function metaclass, but the type of whatever that function returned.

Subclasses inherit the metaclass*

One advantage compared to class decorators is the fact that subclasses inherit the metaclass.

This is a consequence of the fact that Metaclass.__call__(...) returns an object which usually has Metaclass as the __class__.

Restrictions with multiple metaclasses*

In the same tone of classes allowing you to have multiple baseclasses, each one of those baseclasses may have a different metaclass. But with a twist: everything has to be linear - the inheritance tree must have a single leaf.

For example, this is not accepted because there would be two leafs (Meta1 and Meta2):

>>> class Meta1(type):

...     pass

...

>>> class Meta2(type):

...     pass

...

>>> class Base1(metaclass=Meta1):

...     pass

...

>>> class Base2(metaclass=Meta2):

...     pass

...

>>> class Foobar(Base1, Base2):

...     pass

...

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

This will work (and will use the leaf as the metaclass):

>>> class Meta(type):

...     pass

...

>>> class SubMeta(Meta):

...     pass

...

>>> class Base1(metaclass=Meta):

...     pass

...

>>> class Base2(metaclass=SubMeta):

...     pass

...

>>> class Foobar(Base1, Base2):

...     pass

...

>>> type(Foobar)

<class '__main__.SubMeta'>

The method signatures*

There are still few important details missing, like the method signatures. Lets look at class and metaclass with all the important stuff implemented.

Note the extra **kwargs - those are the extra keywords arguments you can pass in the class statement. [22]

>>> class Meta(type):

...     @classmethod

...     def __prepare__(mcs, name, bases, **kwargs):

...         print('  Meta.__prepare__(mcs=%s, name=%r, bases=%s, **%s)' % (

...             mcs, name, bases, kwargs

...         ))

...         return {}

As mentioned before, __prepare__ can return objects that are not dict instances, so you need to make sure your __new__ handles that. [21]

...     def __new__(mcs, name, bases, attrs, **kwargs):

...         print('  Meta.__new__(mcs=%s, name=%r, bases=%s, attrs=[%s], **%s)' % (

...             mcs, name, bases, ', '.join(attrs), kwargs

...         ))

...         return super().__new__(mcs, name, bases, attrs)

It's uncommon to see __init__ being implemented in a metaclass because it's not that powerful - the class is already constructed when __init__ is called. It roughly equates to having a class decorator with the difference that __init__ would get run when making subclasses, while class decorators are not called for subclasses.

...     def __init__(cls, name, bases, attrs, **kwargs):

...         print('  Meta.__init__(cls=%s, name=%r, bases=%s, attrs=[%s], **%s)' % (

...             cls, name, bases, ', '.join(attrs), kwargs

...         ))

...         return super().__init__(name, bases, attrs)

The __call__ method will be called when you make instances of Class.

...     def __call__(cls, *args, **kwargs):

...         print('  Meta.__call__(cls=%s, args=%s, kwargs=%s)' % (

...             cls, args, kwargs

...         ))

...         return super().__call__(*args, **kwargs)

...

Using Meta, note the extra=1: [22]

>>> class Class(metaclass=Meta, extra=1):

...     def __new__(cls, myarg):

...         print('  Class.__new__(cls=%s, myarg=%s)' % (

...             cls, myarg

...         ))

...         return super().__new__(cls)

...

...     def __init__(self, myarg):

...         print('  Class.__init__(self=%s, myarg=%s)' % (

...             self, myarg

...         ))

...         self.myarg = myarg

...         return super().__init__()

...

...     def __str__(self):

...         return "<instance of Class; myargs=%s>" % (

...             getattr(self, 'myarg', 'MISSING'),

...         )

  Meta.__prepare__(mcs=<class '__main__.Meta'>, name='Class', bases=(),

                   **{'extra': 1})

  Meta.__new__(mcs=<class '__main__.Meta'>, name='Class', bases=(),

               attrs=[__qualname__, __new__, __init__, __str__, __module__],

               **{'extra': 1})

  Meta.__init__(cls=<class '__main__.Class'>, name='Class', bases=(),

                attrs=[__qualname__, __new__, __init__, __str__, __module__],

                **{'extra': 1})

Note that Meta.__call__ is called when we make instance of Class:

>>> Class(1)

  Meta.__call__(cls=<class '__main__.Class'>, args=(1,), kwargs={})

  Class.__new__(cls=<class '__main__.Class'>, myarg=1)

  Class.__init__(self=<instance of Class; myargs=MISSING>, myarg=1)

<instance of Class; myargs=1>