Python y el exceso de type-checkers

Si trabajas con Python en serio, seguro ya viste esta escena: alguien abre un pull request, el código pasa pytest, pero falla en el type-checker. Luego aparece otra herramienta con una opinión distinta. Después alguien pregunta cuál de las dos manda. Y ahí empieza el costo real: tiempo de equipo, discusiones de configuración y una sensación de que el tipado en Python ya no es una sola decisión, sino una pila de decisiones que se pisan entre sí.

La discusión no es si el tipado está bien o mal. Eso ya se resolvió en muchos equipos. El punto ahora es otro: cuando el ecosistema se fragmenta en varios type-checkers con reglas parecidas pero no idénticas, ¿qué ganas y qué pierdes? La respuesta importa si mantienes servicios grandes, si haces monorepos, si trabajas con librerías públicas o si tu equipo ya usa tipos para bloquear bugs antes de producción.

Qué está pasando con los type-checkers de Python

Durante años, el mapa era bastante simple. mypy fue la referencia de facto para muchas empresas, pyright ganó terreno por velocidad y buena experiencia en editores, y pyre apareció como opción seria en entornos grandes. Ahora el panorama se amplió todavía más: nuevas propuestas, enfoques distintos y una conversación cada vez más abierta sobre qué significa realmente “compatible con Python typing”.

La fuente de este post, el artículo de Pyrefly sobre “too many type checkers”, plantea una pregunta incómoda pero útil: ¿de verdad esperas correr cinco type-checkers distintos sobre el mismo código? La respuesta práctica suele ser no. Pero la existencia de varias herramientas no es un problema por sí sola. El problema aparece cuando cada una empuja una interpretación distinta del mismo sistema de tipos.

Eso se nota en cosas concretas: inferencia de tipos en funciones genéricas, tratamiento de TypedDict, Protocol, Literal, TypeVarTuple, ParamSpec o incluso en cómo se comportan con imports circulares y patrones dinámicos comunes en Python. Si tu base de código depende de esas piezas, no te sirve una herramienta que sea “casi compatible”. Te sirve una que puedas sostener durante meses sin sorpresas.

No todos los type-checkers apuntan al mismo objetivo

Aquí conviene separar dos preguntas. La primera es técnica: ¿qué tan bien entiende la herramienta el lenguaje y sus patrones reales? La segunda es operativa: ¿qué tan fácil es integrarla en tu flujo de trabajo? A veces una herramienta gana en precisión, pero pierde en velocidad. O al revés: es rapidísima, pero deja pasar casos que tu equipo sí quiere bloquear.

Python no ayuda a simplificar esta pelea porque su ecosistema mezcla código dinámico, tipado gradual y librerías que no siempre están anotadas. Eso hace que el type-checker no sea un verificador neutral, sino una opinión sobre cómo debería leerse tu código. Si usas una herramienta para CI y otra para el editor, puedes terminar con dos verdades distintas.

Y eso no es un detalle menor. En equipos distribuidos, donde una persona trabaja desde Quito, otra desde Bogotá y otra desde Ciudad de México, cualquier diferencia de comportamiento se convierte en tickets, mensajes y tiempo perdido. El costo no está solo en la CPU; está en la coordinación.

La fragmentación sí tiene ventajas, pero no gratis

No todo en esta fragmentación es malo. Tener varias implementaciones empuja competencia, obliga a mejorar performance y evita que un solo proyecto defina el estándar por inercia. En una comunidad tan grande como Python, eso puede ser sano. Si una herramienta se queda corta, otra puede cubrir un caso de uso mejor.

Además, los equipos no tienen las mismas necesidades. Una startup con 40k líneas de código no necesita la misma configuración que una plataforma con 2 millones de líneas, varios paquetes internos y APIs públicas. Para el primer caso, la velocidad de adopción puede pesar más. Para el segundo, la precisión y la estabilidad de reglas importan muchísimo más.

El problema aparece cuando la fragmentación se filtra hacia la experiencia diaria. Si tu equipo tiene que aprender diferencias sutiles entre herramientas, la ganancia de tener opciones se transforma en una carga de mantenimiento. Y si cada nueva versión cambia el comportamiento de validación, los PR empiezan a verse como loterías.

Qué gana un equipo con más de una opción

Un ecosistema con varios type-checkers puede darte:

1. Mejor rendimiento en proyectos grandes.
2. Integración más cómoda con IDEs y LSP.
3. Diferentes niveles de estrictez según el momento del proyecto.
4. Capacidad de migrar si una herramienta se estanca.
5. Más presión para que el estándar de tipado evolucione.

Pero cada una de esas ventajas tiene una contraparte. Más rendimiento puede implicar menos cobertura de casos raros. Más comodidad en editor no siempre significa mejor CI. Y una migración posible no significa una migración barata.

La pregunta correcta no es “cuál es la mejor herramienta”. La pregunta útil es “cuál es la combinación de reglas, velocidad y estabilidad que mi equipo puede sostener sin fricción innecesaria”.

Costo real: interoperabilidad y mantenimiento

Cuando un equipo dice que usa tipado, muchas veces piensa en detectar errores. Pero el costo real está en mantener la coherencia entre herramientas, versiones y configuraciones. Si una parte del flujo usa mypy, otra usa pyright y una tercera depende del editor de cada dev, el sistema completo deja de ser unificado.

Eso se traduce en trabajo extra. Tienes que decidir qué herramienta es la fuente de verdad. Tienes que documentar excepciones. Tienes que revisar si un warning es un bug real o una diferencia de interpretación. Y tienes que hacerlo cada vez que actualizas dependencias o cambias una pieza de infraestructura.

La interoperabilidad también importa hacia afuera. Si publicas una librería, quieres que el mayor número posible de consumidores pueda entender tus tipos. Pero eso no siempre significa que debas hacer tu código compatible con todas las herramientas del mercado. A veces basta con seguir el estándar de typing de Python y probar con la herramienta principal que usa tu audiencia.

Tabla comparativa rápida de decisiones prácticas

La tabla no pretende decirte qué usar, sino dónde se rompe el modelo. Si tu equipo no puede responder quién decide sobre un error de tipos, el problema no es la herramienta. Es la gobernanza.

Cómo decidir sin convertirlo en religión

La forma más sana de abordar este tema es bajar la discusión a criterios verificables. No necesitas una guerra de opiniones; necesitas un checklist que puedas aplicar en tu contexto. Si eliges por moda, vas a pagar después. Si eliges por compatibilidad percibida, también.

Empieza por tres preguntas:

• ¿Qué tan grande es tu base de código hoy?
• ¿Tu equipo usa el type-checker solo en CI o también en el editor?
• ¿Qué porcentaje del código depende de patrones dinámicos difíciles de anotar?

Si respondes eso, ya tienes el 70% de la decisión. El resto es prueba corta con datos reales. Corre la herramienta sobre un módulo representativo, mide el tiempo, cuenta los falsos positivos y revisa cuántas anotaciones faltan para que el resultado sea útil.

Un proceso práctico de evaluación

1. Elige 2 o 3 módulos reales, no ejemplos inventados.
2. Corre el type-checker sobre esos módulos con la configuración más cercana a producción.
3. Cuenta errores reales, falsos positivos y avisos que requieran cambios de arquitectura.
4. Mide cuánto tarda el análisis completo y cuánto tarda en el editor.
5. Define si el equipo acepta ese nivel de fricción durante 3 meses.
6. Documenta la decisión en el repo para que nadie la rediscuta cada sprint.

Ese último punto parece burocrático, pero ahorra tiempo. En equipos latinoamericanos, donde muchas veces conviven contratistas, staff interno y personas en distintos husos horarios, una decisión escrita vale más que una conversación de Slack perdida.

Qué haríamos nosotros en un equipo con tipado en serio

Si nosotros tuviéramos que operar un producto Python con tipado fuerte, evitaríamos la tentación de correr todo al mismo tiempo “por si acaso”. Eso suena prudente, pero suele ser caro. Mejor definiríamos una herramienta principal para CI y editor, y usaríamos una segunda solo en momentos puntuales: migraciones, auditorías o validación cruzada cuando cambia una versión importante.

También separaríamos el problema por capas. No es lo mismo tipar código de aplicación que tipar una librería reusable. No es lo mismo un módulo de infraestructura con dependencias opacas que un paquete de lógica de negocio bien delimitado. Si intentas imponer el mismo nivel de rigor en todo, terminas con demasiados # type: ignore o con un equipo que deja de confiar en el sistema.

Y hay otro punto que muchas veces se subestima: la documentación interna. No basta con decir “usamos tipado”. Tienes que explicar qué herramienta manda, qué reglas son obligatorias, cómo se aprueban excepciones y cuándo se permite ignorar un error. Sin eso, el type-checking se vuelve una costumbre individual, no una práctica de ingeniería.

Señales de que ya tienes demasiadas reglas

Hay síntomas muy claros de que el ecosistema se te está yendo de las manos:

• Dos personas corrigen el mismo archivo por errores distintos según la herramienta.
• Los ignores crecen más rápido que el código nuevo.
• El editor marca algo que CI no marca, o al revés.
• Nadie sabe si una advertencia viene del estándar, de un plugin o de una versión específica.
• Cada actualización de dependencia obliga a una tarde de “arreglar tipos”.

Si reconoces dos o más de esas señales, no necesitas más herramientas. Necesitas menos ambigüedad.

Qué cambia para el futuro del ecosistema

La fragmentación no va a desaparecer, y tampoco debería desaparecer por decreto. Python necesita experimentación. Necesita competencia. Necesita herramientas que empujen límites distintos. Pero también necesita que el costo de usar tipos no suba más rápido que el beneficio que te da bloquear bugs.

La conversación útil no es “¿cuál type-checker gana?”. Es “¿qué nivel de interoperabilidad le pedimos al ecosistema para que el tipado siga siendo práctico?”. Si la respuesta se fragmenta demasiado, los equipos pequeños sufrirán más. Si se simplifica demasiado, se frena la innovación.

En la práctica, lo que más valor tiene hoy es una combinación de tres cosas: una herramienta principal sólida, reglas claras de compatibilidad con el estándar de typing y una cultura de mantenimiento que no convierta cada warning en debate filosófico. Ahí está el equilibrio.

Para seguir el contexto técnico de la discusión, vale la pena revisar la documentación oficial de typing en Python y las páginas de los proyectos más usados. Puedes empezar por la documentación de typing en Python, la guía de mypy y la documentación de pyright:

• https://docs.python.org/3/library/typing.html
• https://mypy.readthedocs.io/
• https://microsoft.github.io/pyright/

Si trabajas en una empresa de LatAm, esta discusión también toca algo más terrenal: el costo de estandarizar. No siempre tienes el lujo de dedicar semanas a refactorizar tipos. Por eso conviene elegir una estrategia que reduzca fricción desde el día uno, no una que prometa cobertura perfecta pero te obligue a mantener cinco configuraciones distintas.

Tabla resumen