В ранних версиях Python разрешение атрибутов полагалось на простой поиск в глубину по словарю экземпляра, за которым следовала иерархия классов. Этот подход оказался недостаточным для реализации надежного поведения, подобного свойству, когда вычисленные значения должны были перехватывать как чтение, так и запись без двусмысленности. Введение новых стилей классов в Python 2.2 установило протокол дескрипторов, классифицируя дескрипторы по наличию __set__ или __delete__ для решения конфликтов приоритета.
Без строгого правила приоритета интерпретатор не мог решить, должны ли локальные данные экземпляра переопределять определения уровня класса или наоборот. Если бы словари экземпляров всегда имели приоритет, свойства не могли бы проверять присвоения, поскольку значения хранились бы непосредственно в __dict__. Напротив, если бы атрибуты класса всегда преобладали, обычные переменные экземпляров стали бы недоступны, когда имена совпадали бы с методами или другими атрибутами класса.
Алгоритм поиска атрибутов Python требует, чтобы дескрипторы данных — те, которые определяют __set__ или __delete__ — имели приоритет над словарями экземпляров, в то время как неданные дескрипторы (определяющие только __get__) уступают словарям экземпляров. Эта система позволяет @property обеспечивать логику валидации, перехватывая записи, в то время как обычные функции или кэшированные свойства остаются заменяемыми для каждого экземпляра без сложного метапрограммирования.
Команда разработчиков создавала слой валидации данных с высоким пропускным способностью для финансовой торговой платформы. Им потребовались постоянные поля, которые строго проверяли входящие рыночные данные на соответствие регулирующим требованиям, чтобы гарантировать, что недопустимые значения не могут быть присвоены. Кроме того, им нужны были вычисленные метрики, которые могли бы кэшироваться для каждого экземпляра, чтобы избежать дорогого пересчета индексов волатильности во время всплесков высокочастотной торговли.
Одним из рассматриваемых подходов было реализация всех атрибутов в виде свойств с использованием декоратора @property. Это обеспечивало комплексный контроль валидации, перехватывая каждую операцию записи через метод установки свойства. Однако этот дизайн не позволял системе обходить валидацию при загрузке сериализованных данных из доверенных внутренних кэшей, создавая ненужные вычислительные затраты во время массовых операций воспроизведения.
Другой вариант заключался в переопределении __setattr__ в базовом классе, чтобы централизовать логику валидации в одном методе. Хотя такой централизованный контроль предлагал единую точку изменения для правил валидации, это вводило хрупкую ветвящую логику для различения между постоянными полями, требующими валидации, и временными вычислительными кэшами. Более того, такой подход мешал стандартным паттернам доступа к атрибутам, ожидаемым библиотеками сериализации третьих сторон, вызывая сбои интеграции.
Выбранное решение использовало дихотомию протокола дескрипторов непосредственно для удовлетворения обоих требований без накладных расходов централизованности. Команда реализовала ValidatedField как дескриптор данных с методом __set__, обеспечивающим ограничения типов и диапазонов, гарантируя, что он всегда перехватывает присвоения независимо от состояния экземпляра, поскольку дескрипторы данных имеют приоритет над словарями экземпляров. Для вычисленных метрик они создали CachedMetric как неданный дескриптор, реализующий только __get__, позволяя словарю экземпляра затенять дескриптор после того, как значение было вычислено и локально сохранено, тем самым обходя пересчет при последующих доступах.
Эта архитектура обеспечивала строгую валидацию для внешних входных данных, позволяя одновременно гибкое и эффективное кэширование для производных значений. Система успешно обрабатывала объемные рыночные потоки без узких мест валидации во время гидратации кэша. Бенчмаркинг показал 40%-ное снижение накладных расходов на валидацию во время исторических сценариев воспроизведения по сравнению с подходом только с использованием свойств, при этом полностью сохраняя соответствие нормативным требованиям для живой загрузки данных.
Обходит ли удаление атрибута дескриптор данных, если у дескриптора отсутствует метод __delete__?
Когда дескриптор данных реализует __set__, но опускает __delete__, попытка удалить атрибут через del obj.attr не запрашивает обратное обращение к словарю экземпляра. Python по-прежнему распознает объект как дескриптор данных из-за наличия __set__, и операция удаления вызовет AttributeError, указывая на то, что атрибут не может быть удален. Чтобы разрешить удаление, дескриптор должен явно определить __delete__, чтобы удалить значение из экземпляра, или класс должен реализовать пользовательскую логику удаления; механизм поиска никогда не проверяет словарь экземпляра для атрибутов дескриптора данных во время операций удаления.
Почему super().attribute кажется игнорирует дескрипторы данных, определенные в текущем классе?
Прокси super() реализует механизм кооперативного множественного наследования, который начинает поиск в Порядке разрешения методов (MRO) от класса, следующего за текущим классом в иерархии. Поскольку дескриптор определен в самом текущем классе, super() пропускает его во время поиска. Тем не менее, если родительский класс определяет дескриптор данных с тем же именем, super() его найдет и применит стандартные правила приоритета дескрипторов данных, вызывая __get__ с экземпляром и классом владельцем соответственно. Это поведение связано с начальной точкой MRO, а не с какой-либо специальной особенностью для дескрипторов в объектах-прокси super.
Как __slots__ используют протокол дескрипторов для принуждения ограничений хранения?
Когда класс определяет __slots__, интерпретатор Python автоматически создает специализированные внутренние дескрипторы (обычно объекты member_descriptor на уровне C) для каждого имени слота и помещает их в словарь класса. Эти дескрипторы реализуют как __get__, так и __set__, что делает их дескрипторами данных, которые имеют приоритет над любой попыткой сохранить значения в обычном словаре экземпляра. Поскольку экземпляры классов со слотами обычно не имеют __dict__, если "__dict__" явно не включен в список слотов, протокол дескрипторов обеспечивает, чтобы все операции чтения и записи для атрибутов со слотами проходили через эти дескрипторы на уровне C, обеспечивая безопасность типов и эффективность памяти, предотвращая произвольное прикрепление атрибутов.