JSON to Python

A dataclass gives you attribute access, a readable repr, and equality without writing a constructor. This generates one per object in the sample with type hints throughout, snake_case field names, and a comment recording the original JSON key wherever the rename changes it.

Python's hints are annotations rather than enforcement, which changes what the output is for — it is documentation your editor can check, not a guarantee about the data:

• intJSON integers. Python integers are arbitrary precision, so this is the one language here with no width to worry about.
• floatAnything fractional. Note that a JSON integer will happily be assigned to a float-hinted field at runtime, because nothing checks.
• Optional[str]Optional or nullable, with a None default. Spelled this way rather than str | None so the output runs on Python 3.7 as well as 3.10.
• List[str]Arrays, from typing rather than the builtin generic, for the same compatibility reason.
• Optional[Any]A field with no observable type.

Why are the optional fields at the bottom?

Because Python raises TypeError at class-creation time — not at instantiation — if a field with a default comes before one without. Optional fields default to None, so they have to come last, and the generator reorders them so the class compiles exactly as written. It is the one place where the field order here deliberately differs from your JSON.

Why a dataclass and not a Pydantic model?

A dataclass is standard library, so this runs anywhere Python 3.7 does with nothing to install. Pydantic would add real validation — and a dependency, to a snippet you may only want for type hints. If you do want the validation, the field list transfers across unchanged: change the base class and the hints start being enforced.

Do the type hints actually do anything at runtime?

No. Nothing checks them, so Root(id="not a number") constructs happily and fails somewhere later. They exist for mypy, pyright, and your editor. This is the substantive difference between the Python output and the Rust or Kotlin output: those will not compile if the shape is wrong, this will run.

How do I build one of these from a dict?

Root(**payload) works when the keys already match the field names, which after snake_casing they often will not — that is what the # JSON key: comments are marking. For a mismatched payload you need a mapping step, or a library like dacite or Pydantic that does the aliasing for you.

How are optional fields decided?

Every record in an array is inspected, not just the first. A field that appears in some records and not others is typed as optional, and a value that is sometimes null widens accordingly. Generators that read only the first element get this wrong on exactly the payloads where it matters.

What happens to a key that is a reserved word?

It is renamed to something legal in the target language, and where the language supports it, an annotation records the original JSON key so serialisation still round-trips.