Классы, датаклассы и __slots__: сгенерированный бойлерплейт и словарь экземпляра

К концу урока ты будешь знать, какая одна строка снизила под с 8 ГБ до 3 ГБ — и какой сюрприз два спринта спустя доказывает, что компромисс настоящий.

Что на самом деле делает оператор class

class Candle: — это исполняемый код, а не декларация: Python выполняет тело в свежем пространстве имён, затем вызывает type(name, bases, namespace), чтобы изготовить объект класса. Методы — просто функции, попавшие в это пространство имён; Candle.__dict__ — то место, где их находит поиск атрибутов из урока 2. Два следствия важны ежедневно. Первое: присваивания в теле класса выполняются один раз — изменяемый атрибут класса (cache = {}) общий для всех экземпляров, классический баг разделяемого состояния. Второе: раз класс строится вызовом type, этот вызов можно перехватить — декораторы вроде @dataclass пост-обрабатывают готовый класс, именно так он добавляет методы без магии метаклассов.

Механика @dataclass: что генерируется и связка eq/hash

@dataclass читает аннотации класса и синтезирует бойлерплейт: __init__ (параметры в порядке аннотаций), __repr__ и __eq__, сравнивающий кортеж полей. Дефолты, которые обязательно знать:

from dataclasses import dataclass, field

@dataclass
class Order:
    id: int
    tags: list[str] = field(default_factory=list)  # НЕ tags: list = []
    note: str = ""        # простые дефолты допустимы для неизменяемых

@dataclass(frozen=True)   # __setattr__ поднимает исключение; __hash__ генерируется
class Money:
    amount: int
    currency: str

• Изменяемые дефолты: tags: list = [] поднимает ValueError ещё при создании класса — датаклассы требуют default_factory, потому что общий список-дефолт — тот же баг однократно исполненного тела класса. (Обычные классы позволяют эту ошибку молча; датаклассы превратили её в ошибку времени определения.)
• Связка eq/hash — контракт из урока 1, теперь в форме генератора: дефолтный eq=True даёт __eq__ и, следовательно, __hash__ = None; экземпляры нехешируемы. frozen=True делает экземпляры неизменяемыми (присваивание поднимает FrozenInstanceError) и вместе с eq=True генерирует __hash__ по полям — замороженные датаклассы безопасны как ключи словаря. Лазейка eq=True, unsafe_hash=True хеширует изменяемый класс и называется «unsafe» по причине из урока 1: измените хешированное поле — и объект потерян в своей корзине.
• order=True добавляет __lt__/__le__/…, сравнивающие кортежи полей, — удобно для sorted(), неверно, если порядок полей не совпадает с вашим смысловым порядком.

slots: словарь в обмен на память и скорость

Если ты загружаешь миллионы однородных объектов, а RSS (Resident Set Size — объём физической памяти, занятой процессом) заметно выше, чем говорит математика полезной нагрузки, — первый вопрос, который стоит задать себе: несёт ли каждый экземпляр __dict__, который ему никогда не понадобится?

Объявление __slots__ = ("ts", "o", "h", "l", "c") говорит созданию класса: не давай экземплярам __dict__; вместо этого выдели фиксированные смещения в C-структуре и создай по одному слот-дескриптору на имя (data-дескриптор — машинерия урока 2, — читающий/пишущий смещение). Честные числа: пустой обычный объект — ~56 байт плюс его __dict__ на ~64–100+ байт после заполнения (словари с разделяемыми ключами в Python ≥3.3 смягчают это для однородных классов, но на маленьких объектах словарь всё равно доминирует); слотированный экземпляр хранит только ссылки — для пятиполевого Candle примерно 104 байта против ~250+ со словарём; так 8 ГБ из Хука стали 3 ГБ. Доступ к атрибутам тоже ускоряется на ~10–25%: чтение по фиксированному смещению быстрее зондирования словаря.

Издержки структурные, а не косметические. Нет __dict__ — значит нет динамических атрибутов (candle.debug_flag = 1 поднимает AttributeError), нет vars(obj), и часть инструментов, полагающихся на словарь (наивные сериализаторы, functools.cached_property, манкипатчинг в тестах), ломается. Наследование — место, где слоты тихо отказывают: подкласс без собственных __slots__ снова вводит __dict__, и экономия испаряется; множественное наследование от двух классов с непустыми __slots__ поднимает TypeError: multiple bases have instance lay-out conflict. И слоты задаются на класс: каждый подкласс объявляет только свои новые поля. С датаклассами интеграция прямая начиная с Python 3.10: @dataclass(slots=True) пересоздаёт класс с __slots__ из полей — эргономичный дефолт для массовых объектов-значений.

Когда вместо этого NamedTuple или attrs

typing.NamedTuple даёт настоящий кортеж: неизменяемый, хешируемый, итерируемый, распаковываемый, по памяти ~как слоты — правильный выбор для маленьких записей-значений, текущих через код, ожидающий кортежи; неправильный, когда нужна мутация или методы, меняющие состояние (а равенство с обычными кортежами умеет удивлять: Point(1, 2) == (1, 2) — True). attrs старше датаклассов и оправдывает зависимость, когда нужны валидаторы/конвертеры полей без рукописных дескрипторов. Эмпирическое правило: датакласс по умолчанию, slots=True на объёме, frozen для ключей словаря, NamedTuple на границах API, говорящих кортежами, attrs — когда повалидационная работа с полями того стоит.