Протоколы

Потому что len обязан быть быстрым и одинаковым для всех, а метод — не обязан ни тем ни другим.

Функция len идёт прямо в слот tp_as_sequence->sq_length типа — это чтение поля структуры и вызов C-функции, минуя всю процедуру поиска атрибута из урока 04. Метод x.len() прошёл бы полный путь: дескрипторы данных, __dict__ инстанса, MRO.

Второй аргумент — единообразие интерфейса. len, iter, str, abs, hash — все встроенные функции с одинаковым синтаксисом для всех типов. Не бывает объекта, у которого «длина» называется size, count или length: реализуешь __len__ — работает len(). Гвидо формулировал это как «префиксная запись для операций, применимых ко многим типам».

class G:
    def __len__(self): return 3
g = G()
print(len(g))                # → 3
g.__len__ = lambda: 99       # подменяем на инстансе
print(len(g), g.__len__())   # → 3 99   len берёт из типа

Последняя строка — главное следствие: дандер читается из типа, а не из объекта. Поэтому __getattr__ не может синтезировать протокол, и библиотеки-прокси вынуждены перечислять дандеры списком в коде класса.

Цена решения: набор протоколов фиксирован. Свою «встроенную функцию» с такой же скоростью написать нельзя — она будет обычным вызовом.

ABC — когда контракт твой и ты хочешь его навязать. Protocol — когда контракт описывает чужие классы.

Разница в направлении зависимости. ABC требует явного наследования или регистрации: класс должен знать про твой интерфейс. Protocol проверяется структурно: подходит всё, у чего есть нужные методы, и класс про протокол ничего не знает.

from typing import Protocol, runtime_checkable
from abc import ABC, abstractmethod

class Reader(Protocol):                 # структурно
    def read(self, n: int) -> bytes: ...

class Base(ABC):                        # номинально
    @abstractmethod
    def read(self, n: int) -> bytes: ...

class Mine:
    def read(self, n): return b""

print(isinstance(Mine(), Base))         # → False   не наследовался
# Mine подходит под Reader без единой строки про Reader

Практическое правило. Пишешь библиотеку и принимаешь чужой объект — Protocol: пользователю не придётся наследоваться от твоего класса и тянуть зависимость. Строишь иерархию внутри своего кода, где важно, чтобы наследник не забыл метод, — ABC: он не даст создать инстанс с нереализованным @abstractmethod.

Оба, между прочим, пристроены к языку сильно позже: ABC в 2007-м (PEP 3119), Protocol в 2017-м (PEP 544). Пятнадцать лет между ними — это ровно время, за которое стало ясно, что номинальная проверка не ложится на утиную типизацию.

И runtime_checkable проверяет только наличие методов, не сигнатуры — то есть isinstance с протоколом гораздо слабее, чем кажется.

Затем, что «крякает как утка» невозможно проверить, не покрякав.

До ABC единственным способом узнать, поддерживает ли объект интерфейс, был hasattr — и это плохо работало по двум причинам. Во-первых, наличие метода не означает нужную семантику: у строки есть __getitem__ и __len__, но обращаться с ней как со списком обычно ошибка. Во-вторых, интерфейсы составные — «последовательность» это пять методов, и проверять их по одному в каждой функции неудобно.

from collections.abc import Sequence, Iterable, Hashable
print(isinstance("abc", Sequence))     # → True
print(isinstance({1: 2}, Iterable))    # → True
print(isinstance([1], Hashable))       # → False

collections.abc дал этому именам и одну проверку вместо пяти. Плюс механизм виртуальной регистрации: чужой класс можно объявить реализацией интерфейса, не трогая его код и не наследуясь.

from collections.abc import Sized
class Weird:
    def __len__(self): return 0
Sized.register(Weird)
print(isinstance(Weird(), Sized))      # → True

И второе применение, ради которого ABC используют чаще: mixin-методы. Наследуешь Mapping, реализуешь три метода — получаешь keys, values, items, get, __contains__, __eq__ бесплатно и одинаково с остальным языком.

Так что ABC не отменяют утиную типизацию, а дают ей словарь и заготовки. Настоящая замена появилась только с Protocol.

Потому что специальные методы ищутся в типе, минуя __dict__ объекта и __getattr__.

Это не оптимизация «на всякий случай», а необходимость: a + b, len(x), x[i] исполняются миллионы раз, и полный поиск атрибута на каждой операции стоил бы вдвое дороже самой операции. Поэтому интерпретатор читает готовый указатель из слота типа.

class C: pass
c = C()
c.__add__ = lambda other: "из инстанса"
try:
    c + 1
except TypeError as e:
    print(e)          # → unsupported operand type(s) for +: 'C' and 'int'
print(c.__add__(1))   # → из инстанса   явный вызов работает

Два практических следствия.

Первое: прокси и обёртки нельзя написать через __getattr__. Класс, который прозрачно перенаправляет всё на внутренний объект, обязан объявить каждый дандер явно — __len__, __iter__, __getitem__ и так далее. Именно поэтому unittest.mock.MagicMock содержит длинный список дандеров прямо в коде, а обычный Mock их не поддерживает.

Второе: назначать дандеры надо классу, а не объекту — и вот это работает, потому что CPython пересчитывает слоты при изменении класса 🔧:

C.__add__ = lambda self, other: "из класса"
print(c + 1)      # → из класса