Lequel des trois styles choisir ?

Pydantic si la donnée vient de l’extérieur et que vous voulez la valider à la frontière. `dataclass` si elle est déjà sûre et qu’un simple conteneur suffit. `TypedDict` si vous annotez des dictionnaires que vous avez déjà, sans toucher au code d’exécution. La structure inférée est la même ; seul son coût diffère.

Pourquoi ma clé est-elle renommée, et où est-elle passée ?

Les attributs Python sont en snake_case : `firstName` devient `first_name`. Dans le style Pydantic, la clé d’origine est conservée par `Field(alias="firstName")`, et l’analyse continue de fonctionner. `dataclass` n’a pas d’alias à offrir — seul le nom est gardé — et `TypedDict` conserve la clé brute, en passant à sa syntaxe fonctionnelle quand une clé n’est pas un nom utilisable.

Que devient une clé nommée `class` ou `def` ?

Elle reçoit un tiret bas : `class_`, `def_`, avec `Field(alias="class")` en Pydantic. Émettre `class: int` produisait un fichier que Python n’analyse même pas — c’était un vrai défaut, trouvé en écrivant cette page et corrigé. `TypedDict` élude la question en écrivant `TypedDict('Root', {"class": int})`.

JSON en Python — Pydantic, dataclass ou TypedDict

Transformez un échantillon JSON en classes Python. Choisissez le style déjà en place dans le projet et collez le résultat tel quel dans models.py.

Instantané Privé Zéro cookie

Nom racine

Style

Entrée JSON

Sortie Python

Ce que fait cet outil

Un échantillon JSON devient des classes Python, une par objet.

{ "id": 1, "firstName": "Ada", "address": { "city": "Paris" } }

from pydantic import BaseModel, Field


class Address(BaseModel):
    city: str


class Root(BaseModel):
    id: int
    first_name: str = Field(alias="firstName")
    address: Address

Les enfants sont déclarés d’abord : une classe doit exister avant qu’une autre en annote un champ. La sortie vise un Python moderne — list[str] et int | str sont écrits directement, ce qui demande 3.10 ou plus.

Trois styles, trois coûts différents

style	ce qu’il vous donne	ce qu’il coûte
Pydantic	la validation à la frontière, des alias pour les clés renommées	une dépendance, et des objets qui ne sont pas ordinaires
dataclass	un conteneur simple, bibliothèque standard seule	aucune validation, et pas d’alias pour une clé renommée
TypedDict	des annotations pour les dictionnaires que vous avez déjà	rien à l’exécution — et donc aucun contrôle non plus

La structure est identique dans les trois ; ce qui change, c’est ce que le type fait pour vous.

Les mots réservés ne cassent plus le fichier

{"class": 1} produisait :

class Root(BaseModel):
    class: int

ce qui n’est pas du Python — le fichier ne s’analyse même pas. Les mots réservés reçoivent maintenant un tiret bas, et l’alias Pydantic garde la clé :

    class_: int = Field(alias="class")

C’était un vrai défaut, trouvé en écrivant cette page puis corrigé. TypedDict s’en tire autrement : une clé qui ne peut pas être un nom d’attribut fait basculer toute la définition vers la syntaxe fonctionnelle, Root = TypedDict('Root', {"class": int}), où les clés sont des chaînes et où tout passe.

Ce qu’un échantillon ne peut pas vous dire

Rien n’est | None et rien n’a de valeur par défaut : chaque champ est obligatoire, parce que l’échantillon le contenait. Un null donne le type None, qui n’accepte rien d’autre — si le champ est « une chaîne, parfois nulle », la retouche est str | None, et = None s’il peut être absent.

Deux clés qui donnent le même snake_case — fooBar et foo_bar — sont tenues séparées par un suffixe numéroté plutôt que fondues, et l’alias garde trace de laquelle était laquelle.

Confidentiel par conception

Tout s’exécute localement dans votre navigateur en JavaScript. Vos données ne sont jamais envoyées sur un serveur, ce qui rend l’outil sûr pour des contenus sensibles, et il fonctionne hors ligne.

Questions fréquentes

Lequel des trois styles choisir ?: Pydantic si la donnée vient de l’extérieur et que vous voulez la valider à la frontière. `dataclass` si elle est déjà sûre et qu’un simple conteneur suffit. `TypedDict` si vous annotez des dictionnaires que vous avez déjà, sans toucher au code d’exécution. La structure inférée est la même ; seul son coût diffère.
Pourquoi ma clé est-elle renommée, et où est-elle passée ?: Les attributs Python sont en snake_case : `firstName` devient `first_name`. Dans le style Pydantic, la clé d’origine est conservée par `Field(alias="firstName")`, et l’analyse continue de fonctionner. `dataclass` n’a pas d’alias à offrir — seul le nom est gardé — et `TypedDict` conserve la clé brute, en passant à sa syntaxe fonctionnelle quand une clé n’est pas un nom utilisable.
Que devient une clé nommée `class` ou `def` ?: Elle reçoit un tiret bas : `class_`, `def_`, avec `Field(alias="class")` en Pydantic. Émettre `class: int` produisait un fichier que Python n’analyse même pas — c’était un vrai défaut, trouvé en écrivant cette page et corrigé. `TypedDict` élude la question en écrivant `TypedDict('Root', {"class": int})`.