Python Is Effectively Two Languages: Typed vs Untyped and Their Roles

Everyone using Python knows that the language supports optional type hints, a feature that has created a small split in the community between those uninterested in typing and those excited about the evolving type‑checking tools.

In practice, Python can be seen as two very similar languages: an untyped Python and a typed Python, which share a large common base but differ fundamentally in how developers solve problems.

One useful way to think about code is to separate it into infrastructure code and business‑logic code. Infrastructure code provides powerful, easy‑to‑use interfaces for difficult tasks such as interacting with browsers (Flask), databases (Django ORM, SQLAlchemy), dependency‑injection frameworks, serialization libraries, or defining classes (attrs, dataclasses). Business‑logic code is the mundane code that solves day‑to‑day problems and delivers value to users.

Note that this abstraction is imperfect—libraries can be thin layers over other libraries, and in most real projects developers write both kinds of code.

Infrastructure code often cannot be fully type‑annotated because the current Python type system is not powerful enough for libraries like cattrs and attrs; the flexibility of untyped Python has historically made it ideal for infrastructure, while untyped code is less suitable for business logic, leading to maintenance challenges in large systems.

Business‑logic code is usually much simpler, and there is far more of it; using typed Python for this code brings many benefits, such as moving whole classes of errors from runtime to type‑checking time, easier refactoring, stronger editor support, and reduced testing needs.

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

This is beneficial because knowing one form of Python (typed or untyped) makes learning the other relatively easy, and mastering both greatly enhances a developer’s capabilities.

The article also reflects on whether a language can excel at both roles, noting similar splits in JavaScript/TypeScript, the business‑logic focus of Java, and Rust’s macro system for infrastructure code.

In conclusion, the rise of typed Python is a positive development for the community, untyped Python will not disappear, and developers should use each approach where appropriate and strive to combine them effectively.