Python Is Effectively Two Languages: Typed vs. Untyped and Why It’s a Good Thing

Everyone using Python knows that the language supports optional type hints, a feature that has created a split in the community between those who ignore typing and those who eagerly adopt the growing ecosystem of type‑checking tools.

In practice Python behaves like two very similar languages: an untyped version and a typed version. While they share a large common core, they differ fundamentally in how developers solve problems.

The author proposes viewing code as either infrastructure code or business‑logic code. Infrastructure code provides powerful, easy‑to‑use interfaces (e.g., Flask, Django ORM, SQLAlchemy, dependency‑injection frameworks, serialization libraries, or class definitions) that enable and empower business‑logic code, which is the code developers write to deliver actual value to users.

Although this abstraction has limits—libraries can blur the line between the two—the distinction remains useful, especially in typical software‑company codebases where both kinds coexist.

Infrastructure code often cannot be fully typed because the current Python type system lacks the power needed for libraries like cattrs or attrs. Consequently, untyped Python has historically been the preferred choice for infrastructure, while typed Python is less suitable for such code.

Business‑logic code, on the other hand, pairs well with typed Python. Type hints move many errors from runtime to type‑checking time, simplify refactoring, provide strong editor support (auto‑completion, navigation), and can reduce the need for extensive testing.

To make this combination effective, infrastructure code should expose typed interfaces at its boundaries rather than being typed internally. Notable examples of this trend include SQLAlchemy 2.0 and modern web frameworks like FastAPI. As the type system matures, some infrastructure may become fully typed, but the most interesting parts will likely remain untyped.

The overall benefit is that mastering one style (typed or untyped) makes learning the other easier, thereby greatly enhancing a developer’s capabilities.

In summary, the rise of typed Python is beneficial for the community, untyped Python will not disappear, and developers should use each where appropriate and strive to combine them effectively.