Разработчики Python-библиотек всё чаще сталкиваются с проблемой: тайп-чекеров стало слишком много. mypy, Pyrefly, Pyright, ty, Zuban — и это не предел. Каждый предъявляет свои требования к коду. Заставлять библиотеку проходить все пять чекеров на исходниках — верный способ утонуть в type: ignore и переписать половину кода под странные частные случаи.
Автор предлагает перевернуть подход. Пользователю плевать, как вы внутри организовали код — через ruff, black или pytest. Ему важно, чтобы публичный API библиотеки корректно проверялся тем тайп-чекером, который стоит у него. Значит, основное усилие стоит направить на тесты: прогнать по ним все пять чекеров и убедиться, что публичные интерфейсы работают без ошибок. Внутреннюю логику можно проверять одним удобным инструментом — это вопрос вкуса разработчика.
Показательный пример — библиотека Polars. Чтобы завести Pyrefly на всём коде, пришлось попотеть: переписывать аннотации, расставлять type: ignore. Для функции DataType.__eq__ из семи строк кода понадобилось четыре комментария, подавляющих ошибки разных чекеров. Код стал похож на свалку. Но когда ту же функцию проверили через тесты на публичном API — все пять чекеров (mypy, Pyrefly, Pyright, ty, Zuban) отработали чисто, без единой ошибки. Потому что тест проверяет то, что реально делает пользователь: вызывает метод с ожидаемыми аргументами.
Разные чекеры делают разный выбор в серых зонах спецификации typing. Одни строже, другие лояльнее. Для внутреннего кода можно выбирать по душе — например, Pyrefly быстрый, строгий и конформный. Но для совместимости с миром проще гонять тесты на всём зоопарке. Это требует меньше усилий, чем заставлять исходники угождать каждому чекеру, и приносит реальную пользу пользователям.