Метаклассы: шесть шагов создания класса, из которых видно, что делать метаклассом, а что уже не надо

База: у класса тоже есть тип

Слово «метакласс» пугает сильнее, чем стоило бы, и почти всегда из-за одного пропущенного шага. Шаг такой: у класса тоже есть тип.

Про объекты это привычно. Написали x = 5 — у x есть тип, и это int. Объявили class Order и создали order = Order() — у order есть тип, и это Order. Вопрос, который обычно не задают: а какой тип у самого Order?

Ответ: type. Класс — такой же объект, как число или строка, и у него тоже есть тип. Тип класса и называется метаклассом.

Дальше модель складывается в две строки, и запоминать надо именно их:

• объект — экземпляр своего класса;
• класс — экземпляр своего метакласса.

Отсюда — ответ уровня Junior, который можно произнести на собеседовании целиком: метакласс управляет созданием классов примерно так же, как класс управляет созданием экземпляров. Класс решает, каким получится объект; метакласс решает, каким получится класс.

На этом уровне достаточно. Если на собеседовании спросили «что такое метакласс», ответ выше — верный ответ, а не его упрощённая версия: он ничего не искажает и не обещает сверх того, что есть, и договаривать до конца необходимости нет. Урок помечен как продвинутый не поэтому. Всё дальнейшее — про то, из каких шагов складывается «создание класса», в какой момент можно вмешаться в каждый и почему на практике вмешиваться почти никогда не нужно.

Механизм 1: класс — экземпляр метакласса, и отсюда весь протокол

Проверяется это одной строкой — и заодно видно, что цепочка на type и кончается:

class Plain:
    pass
 
print(type(Plain))          # <class 'type'>
print(type(type))           # <class 'type'>

Plain — объект. Его тип — type. Метакласс — это просто тип, чьи экземпляры — классы; чтобы написать свой, наследуются от type. Никакой отдельной сущности в языке для метаклассов нет.

Отсюда сразу следует неочевидное: Class(...) — это вызов экземпляра метакласса. Поэтому перехватить создание экземпляров можно, определив __call__ у метакласса, а не у класса. Ровно так делают синглтоны:

class Singleton(type):
    _instances = {}
 
    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super().__call__(*args, **kwargs)
        return cls._instances[cls]

Механизм 2: шесть шагов, и порядок между ними важнее их списка

Справочник перечисляет шаги коротко.

А два самых полезных хука описаны отдельно, в другом разделе, — и именно из-за этого их место в порядке обычно угадывают.

Ключевое здесь — чьё это действие: оба хука вызывает сам type.__new__, то есть они происходят внутри третьего шага, а не после него.

Что из этого следует практически:

• __init_subclass__ не увидит того, что метакласс делает в __init__ — тот шаг ещё впереди. А метакласс в __init__ уже видит результат обоих хуков.
• Имя, базы и пространство имён можно менять только до третьего шага. Дальше они перестают быть аргументами и становятся свойствами существующего класса.
• Декоратор класса вызывается последним, когда всё уже готово: After the class object is created, it is passed to the class decorators included in the class definition (После создания объекта класса он передаётся декораторам класса, указанным в определении класса).

Что «последним» значит для декоратора класса

Из «вызывается последним» легко вывести «поэтому ничего не может», и это неверно. Он получает готовый объект класса — а с готовым классом можно почти всё. Прогон bench/metaclass/decorator_capabilities.py:

__name__ после декоратора                            Переименован
новый атрибут виден                                  добавлено декоратором
декоратор вернул другой класс: имя                   Подменённый
класс на object: __bases__ = (Base,)                 TypeError
класс на Base: __bases__ = (Another,)                Another

Переименовать — может. Дописать и переписать атрибуты — может. Вернуть вместо класса совсем другой объект, и имя в модуле свяжется с ним, — тоже может. С базами сложнее, но запрет не про декоратор: присваивание __bases__ разрешено не всегда (у класса, наследующего прямо от object, оно даёт TypeError), и это правило самого type, а не следствие момента вызова.

Настоящая граница проходит по другому месту — по времени, а не по силе:

Тот же прогон печатает порядок событий, и в нём видно, что тело класса выполняется в отображении из __prepare__ задолго до декоратора:

__prepare__ дал своё отображение
в пространство имён кладут 'a'
в пространство имён кладут 'b'
Meta.__new__ видит имена: ['a', 'b']
декоратор: тело уже выполнено, класс собран

Механизм 3: что умеет только метакласс

Три умения, и все три следуют из порядка.

Первое — перехватить выполнение тела класса. __prepare__ выдаёт словарь, в который тело будет писаться, и потому видит каждое присваивание отдельно. Ничем другим этого не сделать: к моменту __init_subclass__ тело уже выполнено, и на руках только результат.

class NoDuplicates(dict):
    def __setitem__(self, key, value):
        if key in self:
            raise TypeError(f"имя {key!r} определено в теле класса дважды")
        super().__setitem__(key, value)
 
class StrictMeta(type):
    @classmethod
    def __prepare__(mcls, name, bases, **kwargs):
        return NoDuplicates()

Обычный класс дубль имени пропускает молча — просто побеждает последнее присваивание. С таким метаклассом получается TypeError на этапе определения класса.

Второе — перехватить создание экземпляра через __call__. Это то, из чего делают синглтоны, кеши экземпляров и подмену возвращаемого объекта.

Третье — подменить имя, базы или пространство имён. Всё это аргументы Meta.__new__, то есть третьего шага; к моменту __init_subclass__ и тем более декоратора класс уже создан, и менять их поздно.

Всё остальное, за чем обычно тянутся к метаклассу, — регистрация подклассов, проверка обязательных атрибутов, автоматические имена дескрипторов — закрывается двумя хуками из PEP 487.

Строку про имя, базы и пространство имён в этой таблице стоит читать точно. Речь в ней про них как про аргументы создания класса: подсунуть своё отображение под тело, подменить имя или базы до того, как класс собран, может только метакласс. Готовому классу декоратор имя переставит — это показано выше прогоном. Граница между двумя инструментами проходит по времени, а не по силе.

Механизм 4: граница __init_subclass__

Хук вызывается у родителя, когда создаётся потомок. Справочник сравнивает его с декоратором прямо:

Слово «будущие» — это и есть граница:

class Registry:
    registered = []
 
    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Registry.registered.append(cls.__name__)
 
class First(Registry): pass
class Second(Registry): pass
 
print(Registry.registered)      # ['First', 'Second'] — сам Registry не попал

Метакласс, наоборот, срабатывает и на том классе, который его указал: Meta.__new__ вызывается для базового класса так же, как для наследников. Если реестр обязан включать базовый класс — это одна из немногих причин взять метакласс.

И ещё одно: super().__init_subclass__(**kwargs) в первой строке — не формальность. Без него выполнится хук ближайшего родителя, а у всех классов дальше по MRO — нет, и молча: ни ошибки, ни предупреждения не будет.

Глубже: что метакласс стоит на самом деле

Не время. Класс с пустым метаклассом создаётся за 7,09 мкс против 6,98 мкс без него (3.13.7, лучшее из семи прогонов) — разница в пределах шума, и платится она один раз за класс, а не за экземпляр.

Время берётся ровно за одно: перехват __call__ добавляет вызов метода на Python в путь, который иначе идёт целиком в C. 223,3 нс на экземпляр против 59,6 — в 3,7 раза, и на каждом создании. Замер сделан на пустом классе, так что добавка здесь постоянная: у класса, который что-то делает в __init__, та же надбавка весит заметно меньше. Одиночка, сделанный метаклассом, платит эту цену при каждом обращении, включая те, где объект уже создан.

Настоящая же цена — вот эта:

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

Заметьте, где эта ошибка возникает: в чужом файле — у того, кто пишет наследника и вашего метакласса не выбирал. Он всего лишь захотел унаследоваться и от вашего класса, и от чего-то ещё со своим метаклассом — например, от ABC или от Enum. Починить это он может только двумя способами: не наследоваться либо написать третий метакласс, объединяющий два чужих.

Как отвечать на собеседовании

Короткий ответ: метакласс — это тип класса. Класс — экземпляр метакласса ровно так же, как объект — экземпляр класса, и метакласс управляет созданием классов примерно так же, как класс управляет созданием экземпляров. Отсюда и Class(...) — это вызов __call__ у метакласса, потому что класс его экземпляр.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Своими силами метакласс умеет две вещи, которых не умеет больше ничто: перехватить выполнение тела класса через __prepare__ и перехватить создание экземпляра через __call__. Самые частые задачи — регистрация подклассов, проверка их полей, имя дескриптора — с 3.6 решаются __init_subclass__ и __set_name__ дешевле и без конфликта метаклассов. Это совет по проектированию, а не равенство возможностей: подготовка пространства имён, замена баз и перехват создания экземпляра остаются только у метакласса.

Одна формулировка, на которой легко ошибиться вслух, — про декоратор класса. Сказать «декоратор не может заменить класс» неверно: заменить как раз может — он вправе вернуть вместо класса другой объект, и имя в модуле свяжется с ним. Его граница в другом: он не участвует в создании класса. Отображение, в котором выполнялось тело, и аргументы type.__new__ к его приходу уже история, и повлиять на то, что увидят __set_name__ и __init_subclass__, он не может. Разница между ним и метаклассом — по времени вмешательства, а не по силе.

Если спросят «когда вы последний раз писали метакласс» — честный ответ обычно «не писал», и он правильный. Хороший признак того, что вопрос понят: назвать не время как цену, а конфликт метаклассов, и добавить, что платит за него чужой код. И держать границу у замеров: 7,09 против 6,98 мкс и 223,3 против 59,6 нс сняты на одной машине и на пустом классе (3.13.7) — содержательно в них не число, а то, за что именно берётся плата.

Дальше спросят

Частые заблуждения

История версий

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

class Base:
  registry = []

  def __init_subclass__(cls, **kwargs):
      super().__init_subclass__(**kwargs)
      Base.registry.append(cls.__name__)


class A(Base):
  pass


class B(A):
  pass


print(Base.registry)

['A', 'B']

['Base', 'A', 'B']

['A']

[]

Проверьте себя

Чем измерено

Числа этой статьи получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона: на чём считали, что получилось и с каким разбросом.

• bench/metaclass/cost.py
• bench/metaclass/decorator_capabilities.py
• bench/metaclass/order.py