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

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

Порядок задаётся не только списком непосредственных родителей. Python сохраняет локальный порядок базовых классов, учитывает MRO каждого родителя и не допускает ситуацию, когда порядок наследования одного класса противоречит уже установленному порядку другого.

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

Множественное наследование позволяет собирать поведение из нескольких классов, но создаёт неоднозначность: один и тот же метод может находиться в нескольких ветвях иерархии. Простое правило «искать слева направо» недостаточно, потому что оно может нарушать порядок, заданный предками.

Для предсказуемого кооперативного множественного наследования Python применяет C3-линеаризацию. Она обеспечивает монотонность: добавление подкласса не должно неожиданно менять относительный порядок уже существующих классов, если иерархия остаётся совместимой.

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

Рассмотрим ромбовидную иерархию: два класса наследуются от общего базового класса, а итоговый класс наследуется от обоих. Метод общего предка должен быть найден один раз и в предсказуемой позиции.

Неверное понимание MRO приводит к вызову не того метода, пропуску части цепочки super() или ошибке создания класса из-за несовместимого порядка наследования. Особенно опасно напрямую вызывать конкретного родителя: это обходит вычисленный MRO и может нарушить работу других классов в цепочке.

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

Python строит для каждого класса последовательность классов — его MRO. Для класса C(B1, B2) она формируется с учётом самого C, MRO родителей B1 и B2, а также списка непосредственных родителей [B1, B2].

C3-линеаризация выбирает первый подходящий класс из голов списков. Кандидат подходит, если он не встречается в хвосте какого-либо списка. После выбора класс удаляется из всех списков, и процесс продолжается.

Например:

class A:
    def run(self):
        return ["A"]

class B(A):
    def run(self):
        return super().run() + ["B"]

class C(A):
    def run(self):
        return super().run() + ["C"]

class D(B, C):
    def run(self):
        return super().run() + ["D"]

print([cls.__name__ for cls in D.__mro__])
print(D().run())

Для D MRO имеет вид D, B, C, A, object. Поэтому super() в D передаёт управление B, затем B передаёт его C, а C — A. Результатом будет последовательность ['A', 'C', 'B', 'D'], поскольку каждый метод добавляет своё значение после результата следующего метода.

super() не означает «вызвать метод непосредственного родителя». Он ищет следующий класс относительно текущего класса и экземпляра в MRO. Поэтому кооперативная цепочка работает только тогда, когда участвующие методы используют super() и совместимы по сигнатурам.

Проверить порядок можно через атрибут __mro__ или функцию mro(). Если C3 не может построить непротиворечивую последовательность, Python отклоняет объявление класса с ошибкой TypeError, а не выбирает произвольный порядок.

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

В проекте есть базовый обработчик и два миксина: один добавляет журналирование, другой — проверку прав. Итоговый класс наследуется от обоих, и каждый метод handle должен выполниться ровно один раз.

Первый вариант — вызвать методы родителей напрямую. Он кажется простым, но жёстко фиксирует порядок, может повторно вызвать общего предка и перестаёт корректно работать после изменения состава миксинов.

Второй вариант — использовать super() во всех переопределённых методах и согласовать их сигнатуры. Такой подход зависит от корректного MRO, зато сохраняет кооперативную цепочку и позволяет добавлять новые миксины без ручного перечисления родителей.

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

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

Вопрос: означает ли super() вызов метода непосредственного родителя?

Ответ: нет. super() создаёт прокси, который начинает поиск после указанного класса в MRO конкретного объекта. Поэтому следующий класс может быть не непосредственным родителем, а другим участником множественного наследования.
Вопрос: что произойдёт, если два класса задают несовместимый порядок общих предков?

Ответ: Python не создаст итоговый класс и выбросит TypeError. Это защитное поведение: выбор произвольного порядка мог бы сделать вызов методов непредсказуемым и нарушить локальные требования базовых классов.
Вопрос: почему прямой вызов метода родителя опасен в кооперативной иерархии?

Ответ: прямой вызов обращается к конкретному классу, минуя MRO. Из-за этого можно пропустить миксин, вызвать общий предок дважды или нарушить ожидаемый порядок обработки. В кооперативной иерархии каждый метод обычно должен передавать управление дальше через super().