Python developers now face a fragmented ecosystem with five active type-checkers: mypy, Pyrefly, Pyright, ty, and Zuban. Library maintainers often struggle to support all these tools without cluttering their source code with repetitive ignore comments. This friction occurs because different checkers make varying design decisions regarding strictness and how they handle under-specified typing information.

Using Polars as a case study, the author demonstrates that satisfying every checker's internal logic can be tedious. For instance, a single method like DataType.__eq__ required four different type-ignore comments across seven lines of code to satisfy mypy, Pyrefly, and ty. This level of pollution makes maintaining source code difficult and distracts from actual development.

Instead of forcing every tool on the source, maintainers should prioritize running multiple checkers over their test suite. This approach ensures the public API works for users regardless of their chosen tool. While the internal implementation might cause disagreements between checkers, they generally agree on the external effects, which is what users actually experience.

Integrating Pyrefly into the Polars CI pipeline uncovered a medium-priority bug and improved the developer experience. By focusing on the public API, developers avoid codebase pollution while still providing better autocomplete and bug protection. Running one checker on source code and several on tests balances internal speed with external compatibility.