El ecosistema de Python cuenta actualmente con cinco verificadores de tipos que reciben atención creciente: mypy, Pyrefly, Pyright, ty y Zuban. Para los responsables de mantener librerías, ejecutar los cinco sobre el código fuente propio resulta una carga excesiva, ya que cada herramienta impone anotaciones, directivas de ignore y sobreescrituras distintas que ensucian el código. Este artículo de Pyrefly propone invertir las prioridades: en lugar de invertir el esfuerzo en revisar el código interno con todos los verificadores, conviene pasar la mayor cantidad posible de herramientas sobre la suite de tests, que es lo que refleja cómo los usuarios reales consumen la API pública.
La experiencia con Polars ilustra la idea. Hacer que la implementación de DataType.__eq__ satisfaga a mypy, Pyrefly y ty requirió cuatro comentarios type-ignore distintos en apenas siete líneas. Sin embargo, cuando el mismo caso se prueba como test del comportamiento público, las cinco herramientas lo validan sin errores. La conclusión es clara: los verificadores discrepan en cómo escribir el código interno, pero coinciden en cómo debe comportarse la API.
Pyrefly, desarrollado por Meta, se posiciona como una opción estricta, rápida y conforme con la especificación de typing, y permite configurar el nivel de rigor. El texto invita a priorizar los tests sobre el código fuente y a reportar los fallos que aparezcan al adoptarlo.