TypedDicts are better than you think

Original Article ↗ Hacker News Discussion ↗

TypedDicts in Python prompt wider debate about how to model structured data and where static typing fits in a traditionally dynamic language. Commenters compare TypedDicts to dataclasses and libraries like Pydantic, weighing ergonomics, performance, and ease of refactoring—especially in large, dict-heavy codebases. The thread broadens into a clash of philosophies over optional typing, with some seeing type hints and static analysis as essential for maintainability and others arguing they add unnecessary complexity compared to pure dynamic or fully statically typed languages.

Title wording and tone

  • Several dislike “better than you think” / “you” headlines as condescending or click‑baity.
  • Others argue readers understand it’s generic, find the meta‑complaints unproductive, or see it as normal copywriting.
  • Some note irony: provocative titles drive upvotes, but also provoke guideline‑violating meta‑threads.

TypedDict vs dataclasses / slots / Pydantic

  • Pro‑dataclass arguments: faster attribute access, lower memory with slots=True, nicer .attr syntax, and runtime attribute‑name errors.
  • Counterpoints: Python’s general slowness can dwarf L1/cache details; algorithmic choices matter more; __slots__ especially pays off with many tiny objects.
  • Some strongly recommend Pydantic (or msgspec) as “transformative” for modeling and validating data, but others note:
    • TypedDicts (especially total=False) are more ergonomic for modeling partial/patch data, including function kwargs (PEP 692).
    • Pydantic is heavier and slower; good at boundaries, not necessarily for everything.

Patch semantics, None, and modeling optionality

  • Discussion around representing HTTP PATCH‑style updates where a field can be:
    • Left unchanged
    • Set to a value
    • Explicitly set to None / “unset”
  • None alone can’t encode both “leave as is” and “remove”, so people propose:
    • Using sentinels or tagged unions (e.g. set/unset/ignore actions).
    • TypedDicts with optional keys to model “field omitted” vs “present and null”.

Static typing, enforcement, and tooling

  • One side: annotations “do nothing” without a runtime enforcer like Pydantic or decorators; Python happily ignores them.
  • Other side: static type checkers (mypy, Pyright) plus CI can give strong guarantees inside the codebase once external inputs are validated.
  • Disagreement over whether optional typing is “worst of both worlds” or a sweet spot:
    • Critics: no global guarantees, types can lie, external tools aren’t exhaustive.
    • Supporters: any static checking is better than none; hints improve editor support, docs, refactoring.

Static vs dynamic languages and Python’s type system

  • Many argue static types improve readability, correctness, and refactoring even in small scripts; others find them verbose, ugly, and slowing down experimentation.
  • Comparisons arise to Go, TypeScript, Java, C#, Rust, Scala, Haskell, etc., with mixed views:
    • Some think Python’s typing is weaker and fragmented (multiple checkers, subtle differences).
    • Others value its gradual, opt‑in nature and use hints primarily as lightweight metadata.

Real‑world TypedDict use

  • Several recount messy “dict‑everywhere” Python codebases where TypedDicts made it possible to reason about data flow without large refactors.
  • TypedDicts are seen as a low‑risk, drop‑in way to retrofit structure on string‑keyed dicts, whereas dataclasses or full refactors feel too invasive.