Quand choisiriez-vous une dataclass plutôt qu'un NamedTuple ou un modèle Pydantic ?

Prenez une dataclass pour des structures internes mutables où vous voulez des attributs ordinaires et un init, un repr et un eq offerts. Prenez un NamedTuple quand vous voulez un enregistrement immuable, façon tuple, qui se déballe et se hache pour pas cher. Prenez Pydantic aux frontières du système, là où vous avez besoin de validation à l'exécution, de conversion et de sérialisation pour des données qui arrivent par HTTP, par fichier de configuration ou par file de messages.

Ma règle, c'est que Pydantic garde les bords et que les dataclasses vivent à l'intérieur. Tout ce qui franchit une frontière, un corps de requête, une configuration d'environnement, un message pris dans une file, reçoit un modèle Pydantic parce que je veux que ce soit validé et converti une fois, bruyamment, au point d'arrivée. Tout ce qui est en aval peut être une simple dataclass avec slots activé, puisque je sais déjà que les données sont bonnes et que je ne veux pas payer le coût de validation sur chaque objet construit dans une boucle. Ce que les gens ratent, c'est qu'annoter un champ de dataclass comme int ne fait rien à l'exécution : passez une chaîne et elle stockera la chaîne sans broncher. NamedTuple, je m'en sers moins, surtout pour de petits enregistrements immuables qui doivent servir de clés de dictionnaire ou être déballés, comme une paire de coordonnées ou une clé de cache. Sur un service sur lequel j'ai travaillé, passer un chemin critique interne des modèles Pydantic à des dataclasses avec slots a réduit sensiblement la durée d'un job par lots, uniquement en évitant de revalider des données déjà vérifiées.