Wann würdest du eine dataclass einem NamedTuple oder einem Pydantic-Modell vorziehen?

Nimm eine dataclass für interne veränderliche Strukturen, wo du normale Attribute und geschenktes init, repr und eq willst. Nimm ein NamedTuple, wenn du einen unveränderlichen, tupelartigen Record willst, der sich billig entpacken und hashen lässt. Nimm Pydantic an den Systemgrenzen, wo du Laufzeitvalidierung, Coercion und Serialisierung für Daten brauchst, die per HTTP, aus Config-Dateien oder aus Queues ankommen.

Meine Regel ist: Pydantic bewacht die Ränder, dataclasses leben drinnen. Alles, was eine Grenze überquert, ein Request Body, eine Environment-Config, eine Nachricht aus einer Queue, bekommt ein Pydantic-Modell, weil ich es einmal, laut, an der Stelle des Eintreffens validiert und konvertiert haben will. Alles stromabwärts davon kann eine schlichte dataclass mit aktivierten slots sein, denn ich weiß bereits, dass die Daten gut sind, und ich will nicht für jedes Objekt, das ich in einer Schleife konstruiere, Validierungskosten zahlen. Was Leute übersehen: ein dataclass-Feld als int zu annotieren macht zur Laufzeit gar nichts, übergib einen String und er wird fröhlich gespeichert. NamedTuple nutze ich seltener, hauptsächlich für kleine unveränderliche Records, die Dict-Keys sein oder entpackt werden müssen, etwa ein Koordinatenpaar oder ein Cache-Key. In einem Service, an dem ich gearbeitet habe, hat der Wechsel eines internen Hot Paths von Pydantic-Modellen zu geslotteten dataclasses die Laufzeit eines Batch-Jobs spürbar gesenkt, allein weil wir die erneute Validierung bereits geprüfter Daten übersprungen haben.