Are you expected to run five Python type-checkers now?

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. None issues), 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.