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

После этого урока ты будешь знать, почему RecursionError в __init__ — это цепочка промахов по атрибуту, и как та же механика питает property, поля ORM и связанные методы.

Настоящий порядок поиска: object.getattribute

Каждый obj.x вызывает type(obj).__getattribute__(obj, "x"), и дефолтная реализация выполняет алгоритм — порядок важен и является источником большинства загадок «почему мой атрибут игнорируется». Когда в следующий раз задашься вопросом, почему property нельзя затенить или почему запись в self.__dict__['x'] ничего не меняет снаружи, — пройди эти пять шагов:

1. Пройти type(obj).__mro__, ища "x" в __dict__ каждого класса.
2. Если найден и это data-дескриптор (определяет __set__ или __delete__) — вызвать его __get__; до словаря экземпляра дело не дойдёт.
3. Иначе проверить obj.__dict__ — здесь побеждает обычный атрибут экземпляра.
4. Иначе, если найденный на шаге 1 атрибут класса — non-data-дескриптор (только __get__; функции — ровно это), вызвать его __get__. Обычные атрибуты класса возвращаются как есть.
5. Нигде нет → AttributeError, который запускает __getattr__, если тот определён.

Так что «экземпляр затеняет класс» верно лишь для случаев без дескрипторов и без data. property определяет __set__ (даже read-only — его __set__ поднимает AttributeError) и потому является data-дескриптором: именно поэтому property нельзя случайно затенить через self.x = 1 — само присваивание маршрутизируется в property.__set__. И именно поэтому функции, будучи non-data-дескрипторами, затенить можно: obj.method = lambda: ... работает. Связанные методы существуют потому, что шаг 4 вызывает function.__get__(obj, cls), возвращающий объект bound method, — методы не особый синтаксис, а протокол дескрипторов, применённый к функциям.

getattr против getattribute

__getattribute__ перехватывает каждый доступ к атрибуту — переопределите его, и вы платите его стоимость за любой self.anything, а любой self.attr внутри него рекурсирует, если не делегировать через object.__getattribute__(self, name). __getattr__ — дешёвый хук: вызывается только после того, как обычный поиск поднял AttributeError. Это делает его правильным выбором для ленивой загрузки и прокси — ноль накладных расходов на попаданиях — и это же породило рекурсию из Хука: промах атрибута внутри __getattr__ снова входит в __getattr__. Защитный паттерн:

class LazyClient:
    def __init__(self):
        self._cache = {}          # присвоено до того, как возможен промах

    def __getattr__(self, name):  # вызывается ТОЛЬКО на промахе поиска
        # защищаемся от промахов на внутренних именах,
        # чтобы не уйти в рекурсию
        if name.startswith("_"):
            raise AttributeError(name)
        client = expensive_build(name)
        self._cache[name] = client
        self.__dict__[name] = client   # следующий доступ: обычное попадание, __getattr__ пропущен
        return client

Запись результата в self.__dict__ — трюк, который стоит украсть: второй доступ — попадание в словарь экземпляра на шаге 3, и __getattr__ больше не срабатывает — лениво при первом касании, нативная скорость потом.

Пишем дескриптор: валидируемые поля и set_name

Дескриптор — любой объект, чей класс определяет __get__/__set__/__delete__ и который лежит в атрибуте класса (атрибуты экземпляра дескрипторами не считаются никогда). Классическое продакшен-применение — переиспользуемое валидируемое поле: валидация пишется один раз и вешается на много атрибутов:

class Positive:
    def __set_name__(self, owner, name):     # вызывается при создании класса
        self.slot = "_" + name               # узнаёт имя своего атрибута

    def __get__(self, obj, objtype=None):
        if obj is None:
            return self                      # доступ через класс: Account.balance
        return getattr(obj, self.slot)

    def __set__(self, obj, value):           # __set__ делает его DATA-дескриптором
        if value <= 0:
            raise ValueError(f"{self.slot[1:]} must be positive, got {value!r}")
        setattr(obj, self.slot, value)

class Account:
    balance = Positive()    # одна строка на валидируемое поле
    limit = Positive()

    def __init__(self, balance, limit):
        self.balance = balance   # проходит через Positive.__set__
        self.limit = limit

__set_name__ (Python 3.6+) — тихий герой: дескриптор узнаёт, какому атрибуту его присвоили, и вы перестаёте передавать имя дважды (balance = Positive("balance")). Это ровно та машинерия, что лежит под полями Django ORM, колонками SQLAlchemy и моделями в стиле pydantic: объект-поле уровня класса перехватывает каждое чтение и запись, так что user.email = "x" может валидировать, помечать экземпляр «грязным» для UPDATE или приводить типы, — а User.email (заметьте obj is None в __get__) возвращает само поле, чтобы query-DSL строил выражения User.email == "a@b.c". Компромисс честный: каждый доступ к атрибуту становится вызовом на уровне Python, примерно в 2–5 раз медленнее чтения из словаря экземпляра, — поэтому ORM «тормозит» в плотных циклах по миллиону строк, а массовые пути (values_list, .model_dump) обходят дескрипторы.