¿Cuándo elegirías un dataclass en vez de un NamedTuple o un modelo de Pydantic?

Usa un dataclass para estructuras internas mutables donde quieres atributos normales y tener gratis init, repr y eq. Usa un NamedTuple cuando quieras un registro inmutable, parecido a una tupla, que se desempaqueta y se hashea barato. Usa Pydantic en las fronteras del sistema, donde necesitas validación en tiempo de ejecución, conversión y serialización de datos que llegan por HTTP, ficheros de configuración o colas.

Mi regla es que Pydantic vigila los bordes y los dataclasses viven dentro. Todo lo que cruza una frontera, un cuerpo de petición, una configuración de entorno, un mensaje de una cola, lleva un modelo de Pydantic porque quiero que se valide y se convierta una vez, en alto, en el punto en el que llega. Todo lo que viene después puede ser un dataclass normal con slots activados, porque ya sé que los datos son buenos y no quiero pagar el coste de validación en cada objeto que construyo dentro de un bucle. Lo que se le escapa a la gente es que anotar un campo de dataclass como int no hace nada en ejecución, así que le pasas una cadena y guarda la cadena tan contento. NamedTuple lo uso menos, sobre todo para registros pequeños e inmutables que tienen que ser claves de diccionario o desempaquetarse, como un par de coordenadas o una clave de caché. En un servicio en el que trabajé, pasar una ruta interna caliente de modelos de Pydantic a dataclasses con slots recortó de forma apreciable el tiempo de un batch, solo por saltarnos revalidar datos que ya habíamos comprobado.