Are you expected to run five Python type-checkers now?
Python’s increasingly complex typing ecosystem—now involving multiple competing type checkers like mypy and pyright—is raising questions about whether gradual typing in a dynamic language is worth the overhead. Commenters highlight fragmentation, duplicated effort (e.g. library authors running several tools to keep users’ IDEs happy), and awkward syntax, while others argue that static analysis still catches real bugs and improves large Python codebases. The thread broadens into a debate over whether teams should double down on typed Python or instead migrate to statically typed languages like Rust, Go, or TypeScript, especially as AI-assisted coding reduces some of Python’s traditional ergonomics advantage.
Fragmented Python Typing Ecosystem
- Multiple static type checkers (mypy, pyright, pyrefly/ty, etc.) create incompatibilities; library authors sometimes run several to avoid user-facing type errors.
- Some see this as evidence typing was bolted on poorly and should have been part of the language/interpreter from the start.
- Others argue running many checkers is descriptive, not prescriptive: a reflection of current fragmentation, not necessarily a recommendation.
- There are reports of each checker catching different classes of bugs (e.g., overloads vs.
Noneissues), motivating dual use despite annoyance.
Value and Limits of Gradual Typing
- Pro-typing comments: catches real bugs, especially in large/complex codebases; helps IDEs, LSPs, and documentation; is especially valuable for libraries/APIs others consume.
- Critics: annotations are often verbose, non-inferred, and feel like “checked comments”; dynamic features become harder to use; type specs (e.g., narrowing) are underspecified; some see little benefit versus tests.
- Some view Python’s partial typing as “worst of both worlds”: you still pay dynamic-runtime costs and can’t fully rely on the types at runtime.
Dynamic vs. Statically Typed Languages
- One camp: if you want strict typing, move to Rust/Go/C#/TypeScript, which offer better performance, tooling, and cleaner type systems.
- Another camp: migration is often impossible (brownfield code, ML/data stacks, client libraries), so improving Python’s typing is still worthwhile.
- Several defend dynamic languages as productive and expressive; bugs from missing types are seen as manageable with tests and good discipline, especially in web frameworks.
ML, Ecosystem, and Tooling
- Python remains entrenched for ML/data: NumPy/Pandas/ML libraries and preinstalled availability keep it dominant.
- Some argue LLM-assisted coding erodes Python’s advantages: static languages plus strong compilers give better feedback for humans and agents.
- Tooling complaints include packaging, virtualenv ergonomics, and the growing stack of linters/formatters/type-checkers; others say tools like uv + ty/ruff largely solve this for them.
Operator Overloading and __eq__
- Debate over non-bool
__eq__results (arrays, query expressions, DSLs). - Some see this as powerful and readable (e.g., dataframe filters, ORMs); others view it as a “footgun” that undermines clarity and expectations around equality.