Классы

Затем, что __init__ получает уже созданный объект и не может решить, каким он будет.

Разделение простое: __new__ — конструктор, он объект создаёт и возвращает; __init__ — инициализатор, он полученный объект настраивает и обязан вернуть None.

Пока класс изменяемый и обычный, разница незаметна. Она становится принципиальной в двух случаях.

Неизменяемые типы. У tuple, str, int, frozenset значение задаётся при создании и больше не меняется — настраивать в __init__ нечего:

class Point(tuple):
    def __new__(cls, x, y):
        return super().__new__(cls, (x, y))     # единственное место, где можно задать содержимое

p = Point(1, 2)
print(p, p[0])      # → (1, 2) 1

Возврат чужого объекта. __new__ может вернуть не новый экземпляр — на этом стоят синглтоны, кеши объектов и фабрики, выбирающие подкласс по данным. Тонкость: если __new__ вернул объект не этого класса, __init__ вызван не будет вовсе.

Практически: в прикладном коде __new__ нужен редко, и почти всегда его хотят зря — для «синглтона» обычно достаточно модульной переменной, для фабрики — classmethod с понятным именем. Но при наследовании от неизменяемого встроенного типа обойти его невозможно.

Компилятор дописывает ему подсказку — это не рантайм-магия, а решение фазы компиляции.

Если в теле метода встречается super, компилятор добавляет в функцию скрытую свободную переменную __class__, указывающую на класс, в котором метод определён. Видно прямо:

class A:
    def m(self): return super()

print(A.m.__code__.co_freevars)     # → ('__class__',)

class B:
    def m(self): return 1

print(B.m.__code__.co_freevars)     # → ()   подсказки нет

Дальше super() берёт __class__ и первый позиционный аргумент (то есть self) и превращается в super(__class__, self).

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

И главное, что стоит унести: super() идёт не к родителю, а к следующему классу в MRO инстанса. Для одиночного наследования это одно и то же, для множественного — нет, и именно поэтому кооперативное наследование работает только когда его соблюдают все участники цепочки.

Потому что запрет в Java породил интерфейсы, а потом дефолтные методы в интерфейсах — то есть множественное наследование, вошедшее через другую дверь.

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

class X: pass
class Y(X): pass

class Ok(Y, X): pass       # потомок раньше предка — порядок существует
print([c.__name__ for c in Ok.__mro__])
# → ['Ok', 'Y', 'X', 'object']

class Bad(X, Y): pass      # предок раньше потомка — противоречие
# → TypeError: Cannot create a consistent method resolution order (MRO)

Ошибка на этапе создания класса, а не при вызове метода — это и есть та гарантия, ради которой алгоритм выбран.

Практически множественное наследование в Python живёт в одной форме — mixin: маленький класс без своего состояния, добавляющий поведение. socketserver.ThreadingMixIn, collections.abc, половина Django. Это работает и читается.

Что не работает: наследование от двух полноценных классов со своим состоянием и своими __init__. Здесь super() требует, чтобы все участники цепочки вызывали super().__init__() и принимали **kwargs, и стоит одному нарушить — цепочка рвётся молча. Правило: если оба родителя хранят данные, это композиция, а не наследование.

Потому что второе ломается на подклассах — и на классах, которые притворяются.

type(x) == C требует точного совпадения. Подкласс, который везде обязан работать как родитель, проваливает проверку — это прямое нарушение принципа подстановки:

class Money(int): pass
m = Money(5)
print(type(m) == int)      # → False
print(isinstance(m, int))  # → True

Второе отличие тоньше: isinstance проходит через __instancecheck__ метакласса, и это точка расширения. На ней стоят ABC из урока 11 — isinstance(x, collections.abc.Iterable) работает для любого класса с __iter__, вообще без наследования. И на ней же стоят typing.Protocol с runtime_checkable.

Где type(x) is C всё-таки уместен: когда точность и есть цель — сериализатор, который обязан различать bool и int (а bool наследник int, и isinstance(True, int) истинно), диспетчеризация по конкретному типу, отладочная проверка. В таких случаях пишут is, а не ==: типы — синглтоны.

И самый частый правильный ответ — не проверять тип вообще. Урок 11: если нужно «это последовательность», спрашивать надо про протокол, а не про класс.