¿Cinco type-checkers en Python ya son demasiado?

Si trabajas con Python en un equipo mediano o grande, seguro ya viste esta escena: alguien abre un pull request, el código pasa por un formatter, por un linter, por tests, por un type-checker, y luego por otro type-checker más porque una parte del stack usa una configuración distinta. Lo que debía darte confianza termina dejando una sensación rara: ¿de verdad necesitamos tantas herramientas para responder la misma pregunta, si este código está bien tipado o no?

La discusión no es solo una pelea entre fans de una herramienta u otra. Refleja un problema real del ecosistema Python: demasiadas opciones compitiendo por resolver el mismo dolor. Y cuando el equipo crece, cada herramienta extra suma costo de adopción, tiempo de mantenimiento, reglas que documentar y diferencias de comportamiento que nadie quiere depurar a las 6 de la tarde.

El problema no es el tipado, es la fragmentación

Python ya no es el lenguaje de “escribe lo que quieras y listo” para muchos equipos. El tipado estático se volvió parte del flujo normal en backend, data engineering y tooling interno. Según la documentación oficial de Python, el sistema de type hints existe desde PEP 484 y se ha ido ampliando con el tiempo; hoy no es una rareza, es una práctica común en proyectos serios. Puedes revisar la base en la documentación de typing de Python: https://docs.python.org/3/library/typing.html.

El punto incómodo es otro: el ecosistema no se consolidó alrededor de una sola implementación dominante. Tienes mypy, pyright, pyre, pytype y nuevas apuestas que intentan mejorar velocidad, experiencia de editor o precisión. Cada una trae su propia interpretación de casos borde, su forma de configurar exclusiones, su relación con plugins y su ritmo de mantenimiento.

Para una persona sola, elegir una herramienta puede ser una decisión razonable. Para un equipo con 20, 50 o 200 personas, la pregunta cambia. Ya no es cuál te gusta más, sino cuánto cuesta operar esta elección durante 12 o 24 meses.

Qué se rompe cuando hay demasiadas opciones

Cuando cada repositorio o subequipo adopta una herramienta distinta, aparecen problemas muy concretos. El primero es la consistencia: un archivo puede pasar en un servicio y fallar en otro por diferencias de configuración, versiones o plugins. El segundo es la curva de aprendizaje: cada herramienta tiene su propia forma de reportar errores y de corregirlos.

El tercero es el mantenimiento invisible. Una regla que parecía simple, como ignorar imports no usados o aceptar un TypedDict parcial, puede comportarse distinto entre herramientas. Eso obliga a revisar issues que no son bugs del producto, sino diferencias de interpretación. En un monorepo, esa fricción se multiplica.

El cuarto problema es el onboarding. Si tu equipo tiene que explicar “usamos mypy aquí, pyright allá y además un plugin para Django en este otro servicio”, ya perdiste parte del beneficio del tipado: la claridad. El objetivo era reducir incertidumbre, no crear una taxonomía de diagnósticos.

Cinco type-checkers: qué aporta cada uno

No todas las herramientas nacieron para lo mismo. Algunas priorizan compatibilidad con el ecosistema existente, otras velocidad, otras integración con editores. El problema no es que existan, sino que el mercado terminó con varias soluciones superpuestas para el mismo flujo de trabajo.

La siguiente tabla resume diferencias prácticas que sí importan cuando decides qué mantener en producción:

Ese cuadro no significa que una sea objetivamente mejor que otra. Significa que, si tu organización decide usar varias, también decide cargar con varias filosofías de diseño, varios sets de bugs y varias rutas de migración.

mypy y pyright: la comparación que más aparece

En la práctica, muchas conversaciones terminan en mypy vs pyright. No porque sean las únicas, sino porque son las más visibles en equipos de producto y en comunidades de desarrollo. mypy tiene historia, plugins y una base enorme de usuarios. pyright suele gustar por velocidad y por cómo se siente en el editor.

El problema aparece cuando el equipo no define una sola política. Si una parte del monorepo corre mypy y otra pyright, los errores no siempre coinciden. Algo que una herramienta marca como válido puede ser un error para la otra. Eso no solo confunde a quien programa, también complica CI, documentación y soporte interno.

Si quieres ver el comportamiento y las opciones oficiales, vale la pena revisar la documentación de ambos proyectos: https://mypy.readthedocs.io/ y https://microsoft.github.io/pyright/.

El costo real para equipos grandes

En equipos chicos, cambiar de herramienta puede ser una tarea de una tarde. En equipos grandes, una decisión así toca repos, pipelines, editor settings, plantillas de proyecto, formación interna y reglas de revisión. El costo no está solo en instalar un paquete, sino en sostenerlo.

Piensa en una organización con 40 repositorios. Si cada uno tiene una configuración distinta, ya no administras un type-checker; administras 40 variaciones de un mismo problema. Cada actualización de versión puede romper algo distinto, y cada equipo termina resolviendo el mismo incidente de forma separada.

Además, el tipado estático no vive aislado. Convive con formatters, linters, pre-commit hooks, tests, CI y, en muchos casos, con reglas de seguridad. Si sumas otra capa de validación sin una estrategia clara, aumentas el tiempo de feedback y también la fatiga del desarrollador.

Costos concretos que sí se sienten

Aquí tienes una lista de costos que suelen aparecer cuando el stack de tipado crece sin control:

1. Más tiempo de CI: cada job adicional suma minutos por pull request. En repos grandes, eso se traduce en horas al día.
2. Más entrenamiento: una persona nueva no aprende una herramienta, aprende dos o tres convenciones.
3. Más excepciones: cada caso especial requiere ignores, overrides o plugins.
4. Más mantenimiento de configuración: cambios menores en versiones pueden romper reglas o diagnósticos.
5. Más discusiones internas: el equipo invierte tiempo en decidir qué error es real y cuál es ruido.

No hace falta exagerar para ver el impacto. Si un pipeline tarda 8 minutos y agregas 3 minutos de análisis extra por cada cambio, en 20 PR al día ya estás absorbiendo más de una hora de espera adicional diaria. Eso se siente en productividad y también en paciencia.

El problema de la semántica distinta

Dos type-checkers pueden coincidir en el 90 por ciento de los casos y aun así generar fricción. El 10 por ciento restante suele concentrarse en los bordes: generics, TypedDict, Protocol, inferencia en funciones complejas, stubs de terceros o comportamiento con decorators.

En un equipo, esos bordes no son teoría. Son tickets reales. Alguien corrige el error para una herramienta y rompe el otro job. Otro desarrollador agrega un cast para silenciar el warning, pero el cast oculta un problema genuino. Así se crea una especie de deuda semántica: el código ya no solo debe compilar, también debe agradar a dos interpretaciones distintas.

Cómo decidir sin duplicar dolor

La decisión razonable no es “usa la herramienta más popular” ni “usa la más nueva”. La decisión razonable es elegir una fuente de verdad para el tipado y documentar por qué existe. Si tu equipo necesita velocidad en el editor, evalúa eso. Si necesita compatibilidad con un legado enorme, también. Pero evita el patrón de sumar herramientas sin eliminar las anteriores.

Un enfoque útil es tratar el type-checker como parte de la arquitectura del repo, no como un plugin más. Eso significa definir alcance, ownership y reglas de excepción. También significa aceptar que no todo proyecto necesita el mismo nivel de rigor desde el día uno.

Una guía práctica para equipos

Si estás evaluando herramientas, este orden ayuda bastante:

1. Define el objetivo: ¿quieres detectar bugs, mejorar autocompletado o estandarizar APIs internas?
2. Mide el costo de adopción: cuántos archivos tocarás, cuántos ignores existen y cuántos plugins dependes.
3. Prueba con una base de código real: no con un demo de 200 líneas, sino con un servicio que use generics, dataclasses y dependencias externas.
4. Fija una sola política por repo: evita mezclar herramientas salvo que haya una razón técnica fuerte.
5. Revisa el mantenimiento trimestralmente: versiones, tiempos de CI y cantidad de falsos positivos.

Si necesitas un punto de partida, usa la documentación oficial de cada proyecto y una muestra real de tu código. No tomes la decisión solo por benchmarks de internet, porque un benchmark sin tu contexto no paga tus incidentes de producción.

Qué nos dice esta discusión sobre Python

Python ganó por flexibilidad, comunidad y velocidad para construir. Pero esa misma flexibilidad hace que el ecosistema tolere muchas soluciones paralelas durante demasiado tiempo. En tipado eso se nota más que en otras áreas, porque el valor de la herramienta depende de que todos hablen el mismo idioma.

Cuando cinco type-checkers compiten por resolver el mismo dolor, el mercado no solo muestra innovación. También muestra que no hubo una estandarización suficiente para reducir fricción. Y eso afecta más a quienes operan software a escala que a quien solo prueba una librería en local.

La lección para equipos en LatAm es bastante simple: no copies la pila de tipado de otro equipo si no entiendes el costo de mantenerla. En muchas empresas de la región, el problema no es falta de herramientas, sino exceso de complejidad importada sin presupuesto para sostenerla. Si tu equipo está en Ecuador, México, Colombia o Argentina, la pregunta sigue siendo la misma: ¿cuántas horas al mes estás dispuesto a gastar en alinear diagnósticos que deberían ser uno solo?

Tabla resumen

Al final, la pregunta no es si cinco type-checkers son demasiados por capricho. La pregunta es si tu organización está dispuesta a pagar el costo de tener cinco respuestas distintas para el mismo problema. En la mayoría de los equipos, la respuesta honesta suele ser no.