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

Внутри переопределённого getattribute нужно делегировать поиск через object.getattribute(self, имя) или через корректный вызов super(). Обращение к атрибуту через self.имя внутри этого метода снова вызывает getattribute и обычно приводит к бесконечной рекурсии.

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

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

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

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

Метод getattribute вызывается раньше стандартного поиска атрибута. Если его реализация пытается получить внутреннее состояние через обычную запись вроде self._log, Python снова вызывает тот же метод, который снова обращается к self._log.

В результате возникает RecursionError либо побочный эффект выполняется многократно. Ошибка особенно неприятна в отладочном или логирующем коде: попытка записать информацию об ошибке сама может породить новую ошибку.

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

Безопасный вариант — передать поиск базовой реализации:

class Logged:
    def __getattribute__(self, name):
        value = object.__getattribute__(self, name)
        print(f'прочитан атрибут: {name}')
        return value

    def __init__(self):
        self.value = 10

item = Logged()
print(item.value)

Вызов object.__getattribute__(self, name) не обращается к self.__dict__ через синтаксис атрибутов и поэтому не запускает переопределённый метод повторно. Кроме того, он выполняет обычные правила поиска: учитывает дескрипторы, атрибуты класса и словарь экземпляра с соответствующими приоритетами.

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

Для доступа к внутреннему состоянию также можно использовать object.__getattribute__(self, '_state'). Прямое чтение self.__dict__ небезопасно: получение самого __dict__ тоже является обращением к атрибуту и может повторно войти в getattribute. Однако экземпляры с __slots__ вообще могут не иметь __dict__.

Переопределять getattribute следует только при необходимости перехватывать успешные обращения ко всем атрибутам. Если требуется обработать лишь отсутствующие атрибуты, безопаснее и проще использовать getattr.

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

В прокси для удалённого сервиса нужно логировать чтение атрибутов и при необходимости загружать данные лениво. Рассматривались три варианта: переопределить только __getattr__, перехватить все обращения через __getattribute__ или реализовать отдельные свойства.

getattr не создаёт рекурсии и проще в сопровождении, но не видит уже существующие атрибуты. Свойства дают явный контроль и хорошую типизацию, но требуют заранее описывать каждое поле. getattribute покрывает весь интерфейс прокси, однако увеличивает риск рекурсии, влияет на производительность и требует аккуратного исключения внутренних атрибутов.

Выбран был getattribute с делегированием через object.__getattribute__ и отдельным безопасным хранилищем состояния. Это позволило централизованно логировать доступ, не смешивая внутренние поля прокси с удалёнными атрибутами; при этом критичные внутренние операции не проходили через сетевой слой.

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

Всегда ли неявный вызов специального метода проходит через переопределённый getattribute экземпляра?

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

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

Что произойдёт, если getattribute завершится AttributeError?

При обычном синтаксическом обращении к атрибуту Python может передать управление getattr, если этот метод определён. Таким образом, __getattribute__ отвечает за первичный поиск и может сознательно сообщить, что атрибут не найден, а __getattr__ служит резервным механизмом.

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

Почему прямой вызов object.getattribute может быть неправильным в сложной иерархии классов?

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

В кооперативной иерархии следует рассмотреть super().__getattribute__(name): он учитывает порядок разрешения методов и позволяет нескольким классам последовательно обработать запрос. Прямой вызов object предпочтителен, когда требуется именно гарантированно стандартный поиск без участия промежуточных переопределений.