__slots__ et les dataclasses slots=True : des instances plus légères, aux attributs fixes

Ce que c'est

Par défaut, chaque instance porte un __dict__ pour ses attributs ainsi qu'un slot __weakref__. Déclarer __slots__ = ("x", "y") réserve un stockage fixe pour ces noms ; la référence du langage indique que cela interdit la création de __dict__ et de __weakref__ sauf s'ils figurent dans la liste, que l'espace économisé peut être important et que la recherche d'attribut peut être plus rapide. @dataclass(slots=True) (3.10) génère __slots__ à partir des champs et, selon la documentation, renvoie une nouvelle classe au lieu de l'originale ; weakref_slot=True (3.11) réintroduit __weakref__ pour que les instances puissent faire l'objet de références faibles.

Pourquoi c'est important

Les programmes qui conservent des millions de petits enregistrements (lignes de journal analysées, nœuds de graphe, entrées de cache) paient le prix d'un dictionnaire par instance. Les slots détectent aussi les fautes de frappe : affecter un nom absent de __slots__ lève une AttributeError au lieu de créer silencieusement un nouvel attribut.

Comment l'appliquer

• Utiliser @dataclass(slots=True, frozen=True) pour des enregistrements de type valeur créés en masse ; mesurer avec tracemalloc sur un échantillon représentatif avant et après, et ne conserver le changement que si l'économie est significative.
• Déclarer __slots__ dans chaque classe de la hiérarchie (un tuple vide là où aucun attribut n'est ajouté). La référence indique qu'en cas d'héritage d'une classe sans __slots__, les instances ont toujours __dict__ et __weakref__, ce qui annule l'économie.
• Ajouter "__dict__" à __slots__ quand des attributs dynamiques sont réellement nécessaires, et weakref_slot=True (ou "__weakref__") quand les instances vont dans un WeakValueDictionary ou une autre structure à références faibles.
• Lister les champs d'une dataclass avec dataclasses.fields(), et non en lisant __slots__ ; la documentation note que les champs déjà dotés d'un slot dans une classe de base sont omis du __slots__ généré.

Pièges

Comme slots=True renvoie une nouvelle classe, les méthodes écrites dans le corps de classe d'origine continuaient de référencer l'ancienne classe via la cellule implicite __class__. La documentation de la 3.13 avertit qu'un super() sans argument dans une telle méthode lève un TypeError et indique super() à deux arguments comme contournement ; le journal des modifications de la 3.14 enregistre la correction (gh-90562). Le code devant fonctionner de la 3.10 à la 3.13 écrit donc super(ClassName, self) ou déplace l'appel vers une classe de base sans slots. La documentation avertit aussi que passer des paramètres à un __init_subclass__ de classe de base avec slots=True lève un TypeError. La référence indique que l'héritage multiple à partir de plusieurs bases dotées de slots non vides lève un TypeError, et que les attributs de classe ne peuvent pas servir à définir des valeurs par défaut pour des variables dotées de slots, puisqu'ils écraseraient le descripteur. cached_property a besoin d'un __dict__, il ne fonctionne donc pas sur des classes dotées de slots.