June 8, 2026
Too many checkers, not enough chill
Are you expected to run five Python type-checkers now?
Python devs told to juggle five code babysitters, and the comments are melting down
TLDR: The article says Python library makers should test their public features with as many type-checking tools as possible, even if they only use one on their own code. Commenters turned that into a bigger fight, with many saying this proves Python’s type system is messy, overcomplicated, and pushing people toward other languages.
A Python blog post tried to answer a very modern coder panic: are developers really supposed to run five different tools just to check their code? The author’s big argument was surprisingly simple: if you maintain a Python library, the most important thing is not checking your private behind-the-scenes code, but making sure your public-facing features work for people using different checkers. In plain English, test what your users touch. Easy enough — until the community arrived with popcorn.
And wow, the reactions were not calm. One camp basically said this whole situation proves Python’s typing system feels bolted on after the fact, with one commenter saying the idea of running five checkers on test suites perfectly captures that “tacked on” vibe. Another group went even further, using the moment to campaign for ditching Python entirely in favor of stricter, compiled languages that catch mistakes faster. Translation: some readers didn’t just reject the advice — they treated it like an accidental ad for leaving the language.
Then there was the comedy gold around the article’s weirdest example: a case where a == b might not return simple true-or-false. That triggered a mini identity crisis in the comments, with people basically yelling, “Why would equality not mean equal?” Others pushed back on the article’s testing advice, arguing many tests poke at internal behavior, not just the public surface. So the real drama wasn’t just about tools — it was a full-on fight over whether Python coding has become too messy, too clever, and maybe a little too ridiculous for its own good.
Key Points
- •The article recommends running as many Python type checkers as possible on a library’s test suite and at least one on its source code.
- •It argues that type checking tests is more important for library maintainers because tests exercise the public API that users depend on.
- •The article uses Polars as a case study for adding Pyrefly to continuous integration.
- •According to the article, Pyrefly’s stricter behavior compared with mypy required code rewrites, more explicit annotations, and exposed bugs that were largely fixed in Pyrefly v1.
- •The Polars `DataType.__eq__` example shows that making one API satisfy multiple type checkers can require overloads and checker-specific ignore directives.