Python type hints may not be not for me in practice

Original Article ↗ Hacker News Discussion ↗

Python’s growing ecosystem of type hints is polarizing developers who prize the language’s “executable pseudocode” feel. Supporters argue that annotations, static checkers like mypy/pyright, and tools such as Pydantic greatly improve refactoring, documentation, and robustness in larger or long-lived codebases, especially when libraries are well-typed. Critics counter that the evolving typing APIs, noisy errors around untyped dependencies, and pressure toward more verbose, class-heavy designs add cognitive load and maintenance chores that often outweigh the benefits for small scripts, rapid prototyping, or teams used to dynamic workflows.

Evolution and Stability of Python Typing

  • Typing has changed on almost every minor release: new union syntax, Optional/Union shifts, generics moving between modules, TypeAlias vs type, forward-decl changes.
  • Some see this as significant churn and maintenance overhead for long‑lived projects; others argue old APIs mostly keep working and deprecations are slow and signposted.
  • Tools like Ruff can auto-upgrade annotations to newer idioms, partially easing migration.

When Type Hints Help vs Hurt

  • Pro-typing arguments:
    • Catch bugs early, especially during refactors.
    • Act as “enforced documentation” for arguments/returns.
    • Greatly aid IDE autocompletion and navigation.
    • Make large codebases and onboarding easier.
  • Skeptical views:
    • Mental load is high for people who write Python infrequently.
    • Many “type errors” turn out to be annotation bugs, not logic bugs.
    • For small scripts and quick utilities, hints feel like pure overhead.

Interacting with Untyped or Dynamic Libraries

  • Major pain point: partially typed projects with untyped or heavily dynamic dependencies (ORMs, magic-heavy libraries).
  • Leads to noisy “partially unknown” types and false positives, especially in VS Code/pyright.
  • Mitigations mentioned: configure checkers to ignore untyped code, write stub files, or suppress errors; some prefer wrapper layers that convert to well-typed dataclasses/Pydantic models.

Readability, Verbosity, and Python’s Character

  • Several commenters feel hints make Python less like “executable pseudocode” and more like Java/C#, sacrificing aesthetic cleanliness.
  • Others counter that explicit types improve readability by making data shapes obvious, at the cost of some visual clutter.
  • Concern that typing culture nudges designs toward more classes and ceremony purely to satisfy checkers.

Runtime vs Static Checking

  • Clarification: hints are static; Python remains dynamically and strongly typed.
  • Some want stricter, TS-like or “typed dialect” Python with mandatory checking.
  • Others prefer using hints + static tools (mypy, pyright) and, when necessary, runtime validators (Pydantic, beartype, typeguard).

Pragmatic Usage Patterns

  • Common compromise: annotate “the easy 80%” (function signatures, main data models), skip or relax typing where it’s awkward.
  • Several note that LLMs and tools can now auto-generate or retrofit many annotations, reducing the cost of adoption.