Краткий ответ

Такой объект должен определить метод mro_entries. При создании класса Python вызывает его и заменяет исходный объект кортежем классов, который метод возвращает; уже после этого формируются MRO, метакласс и сам класс.

Исторический контекст

Механизм mro_entries появился в Python 3.7 как часть изменений, связанных с PEP 560. Он решил проблему поддержки объектов, имитирующих базовые классы, без сложных обходных решений через метаклассы.

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

Постановка проблемы

Обычно каждый элемент списка базовых классов должен быть классом. Если передать туда обычный объект без специального протокола, создание класса завершится ошибкой типа TypeError.

Однако библиотеке может потребоваться динамически подставить один или несколько реальных классов. Важно, чтобы после такой подстановки Python корректно построил MRO, выбрал метакласс и применил обычные правила наследования.

Подробное решение

Если элемент списка базовых классов не является классом, Python проверяет наличие у него mro_entries. Метод получает исходный кортеж базовых объектов и должен вернуть кортеж классов, который заменит данный объект.

class Mixin:
    def feature(self):
        return "ok"

class BaseSpec:
    def __mro_entries__(self, bases):
        return (Mixin,)

class Service(BaseSpec()):
    pass

print(Service().feature())  # ok

В объявлении Service экземпляр BaseSpec не становится базовым классом напрямую. Python заменяет его результатом __mro_entries__, поэтому фактической базой Service становится Mixin.

Возвращаемое значение должно быть кортежем классов. Пустой кортеж допустим: это означает, что объект не добавляет базовых классов. Если метод вернёт некорректное значение или элементы результата не будут допустимыми базами, создание класса завершится исключением.

Подстановка происходит до вычисления MRO и выбора метакласса. Поэтому результат __mro_entries__ может повлиять на порядок разрешения методов и вызвать конфликт метаклассов, даже если исходный объект сам метаклассом не является.

Если замена действительно произошла, Python обычно сохраняет исходный список баз в атрибуте orig_bases. Это позволяет инструментам типизации и introspection узнать, какие объекты были указаны в исходном объявлении класса.

Если элемент списка баз уже является классом, __mro_entries__ для него не используется: он участвует в наследовании напрямую.

Ситуация из практики

Библиотека строит классы моделей через объект-конфигурацию. Этот объект должен выбрать набор примесей в зависимости от настроек, но не должен становиться частью MRO сам.

Возможны два подхода:

использовать метакласс, который анализирует объявление класса. Это даёт полный контроль, но усложняет совместимость с другими метаклассами и увеличивает скрытую магию;
реализовать mro_entries у объекта-конфигурации. Это ограничивает механизм заменой базовых классов, зато сохраняет стандартный процесс создания класса и лучше сочетается с обычным наследованием.

Практичнее выбрать второй вариант, если требуется именно динамическая подстановка баз. В результате MRO остаётся прозрачным: после создания класса в нём находятся реальные классы, а не объекты-конфигурации.

Что кандидаты часто упускают

Вызывается ли mro_entries у обычного класса, если он сам определяет этот метод?

Нет. Класс считается допустимой базой и используется напрямую. Этот протокол предназначен для объектов, которые не являются классами. Наличие метода с таким именем у самого класса не превращает обычное наследование в замену баз.

Когда происходит выбор метакласса: до или после mro_entries?

После. Сначала Python разрешает нестандартные базовые объекты и получает итоговый кортеж классов. Затем по этим классам выбирается наиболее производный совместимый метакласс. Поэтому подставленный класс может изменить выбор метакласса и привести к конфликту, которого не было видно по исходному объекту.

Может ли один объект заменить себя несколькими базовыми классами?

Да. mro_entries возвращает кортеж, а не единственный класс. Python вставляет все элементы этого кортежа на место исходного объекта и затем проверяет их совместимость, порядок MRO и отсутствие недопустимых циклов. Это удобно для составных примесей, но увеличивает риск конфликтов метода разрешения порядка наследования и дублирования базовых классов.