[eyko]

Can't speak for the parent commenter but their situation felt familiar. I'm in a new role where I'm contributing to a very large Python codebase (first commit from over a decade ago) and whilst there's a lot of more recent code written with type hints, they're not enforced and they're not always reliable or consistent. On my second contribution, I introduced a bug that pyright immediately spotted after I upped the checks from basic to strict. Our Sentry reports a lot of non-critical bugs that are being triggered in production that in many cases are _already_ highlighted by the type checker. It's just a big enough codebase that it's not practical to attempt to fix them all.

If I were starting a project today in Python, I would definitely try setting up my tooling and processes to enforce type checking to at least some extent. Fortunately, we have a lot of guardrails that recover from the typical exceptions that occur in those cases, but as I experienced first hand, it's very easy to introduce new bugs when relying only on my intuition for those difficult-to-spot cases. Tooling definitely helps there.

My previous role had me writing TypeScript and Rust so there's always the temptation, or bias, to advocate for strict typing everywhere, but I'm conscious that it's neither practical nor feasible in large codebases with hundreds of contributors (most of whom may be more accustomed to dynamically typed languages).