Understanding __init_subclass__

PEP 487 sets out to take two common metaclass usecases and make them more accessible without having to understand all the ins and outs of metaclasses. The two new features, __init_subclass__ and __set_name__ are otherwise independent, they don't rely on one another.

__init_subclass__ is just a hook method. You can use it for anything you want. It is useful for both registering subclasses in some way, and for setting default attribute values on those subclasses.

We recently used this to provide 'adapters' for different version control systems, for example:

class RepositoryType(Enum):    HG = auto()    GIT = auto()    SVN = auto()    PERFORCE = auto()class Repository():    _registry = {t: {} for t in RepositoryType}    def __init_subclass__(cls, scm_type=None, name=None, **kwargs):        super().__init_subclass__(**kwargs)        if scm_type is not None:            cls._registry[scm_type][name] = clsclass MainHgRepository(Repository, scm_type=RepositoryType.HG, name='main'):    passclass GenericGitRepository(Repository, scm_type=RepositoryType.GIT):    pass

This trivially let us define handler classes for specific repositories without having to resort to using a metaclass or decorators.

__init_subclass__ and __set_name__ are orthogonal mechanisms - they're not tied to each other, just described in the same PEP. Both are features that needed a full-featured metaclass before. The PEP 487 addresses 2 of the most common uses of metaclasses:

• how to let the parent know when it is being subclassed (__init_subclass__)
• how to let a descriptor class know the name of the property it is used for (__set_name__)

As the PEP says:

While there are many possible ways to use a metaclass, the vast majority of use cases falls into just three categories: some initialization code running after class creation, the initialization of descriptors and keeping the order in which class attributes were defined.

The first two categories can easily be achieved by having simple hooks into the class creation:

• An __init_subclass__ hook that initializes all subclasses of a given class.
• upon class creation, a __set_name__ hook is called on all the attribute (descriptors) defined in the class, and

The third category is the topic of another PEP, PEP 520.

Notice also, that while __init_subclass__ is a replacement for using a metaclass in this class's inheritance tree, __set_name__ in a descriptor class is a replacement for using a metaclass for the class that has an instance of the descriptor as an attribute.

The main point of __init_subclass__ was, as the title of the PEP suggest, to offer a simpler form of customization for classes.

It's a hook that allows you to tinker with classes w/o the need to know about metaclasses, keep track of all aspects of class construction or worry about metaclass conflicts down the line. As a message by Nick Coghlan on the early phase of this PEP states:

The main intended readability/maintainability benefit is from the perspective of more clearly distinguishing the "customises subclass initialisation" case from the "customises runtime behaviour of subclasses" case.

A full custom metaclass doesn't provide any indication of the scope of impact, while __init_subclass__ more clearly indicates that there's no persistent effects on behaviour post-subclass creation.

Metaclasses are considered magic for a reason, you don't know what their effects will be after the class will be created. __init_subclass__, on the other hand, is just another class method, it runs once and then it's done. (see its documentation for exact functionality.)

The whole point of PEP 487 is about simplifying (i.e removing the need to use) metaclasses for some common uses.

__init_subclass__ takes care of post-class initialization while __set_name__ (which makes sense only for descriptor classes) was added to simplify initializing descriptors. Beyond that, they aren't related.

The third common case for metaclasses (keeping definition order) which is mentioned, was also simplified. This was addressed w/o a hook, by using an ordered mapping for the namespace (which in Python 3.6 is a dict, but that's an implementation detail :-)