¿Se espera que ahora ejecutes cinco comprobadores de tipos de Python?

Ecosistema fragmentado de tipado en Python

• Varios comprobadores estáticos de tipos (mypy, pyright, pyrefly/ty, etc.) crean incompatibilidades; los autores de bibliotecas a veces ejecutan varios para evitar errores de tipos visibles para los usuarios.
• Algunos ven esto como evidencia de que el tipado se añadió de forma deficiente y debería haber formado parte del lenguaje/intérprete desde el principio.
• Otros sostienen que ejecutar muchos comprobadores es descriptivo, no prescriptivo: un reflejo de la fragmentación actual, no necesariamente una recomendación.
• Hay informes de que cada comprobador detecta distintas clases de errores (p. ej., sobrecargas frente a problemas con None), lo que motiva el uso dual a pesar de la molestia.

Valor y límites del tipado gradual

• Comentarios a favor del tipado: detecta errores reales, especialmente en bases de código grandes o complejas; ayuda a IDEs, LSP y documentación; es especialmente valioso para bibliotecas/APIs que otros consumen.
• Críticas: las anotaciones suelen ser verbosas, no se infieren y se sienten como “comentarios verificados”; las características dinámicas se vuelven más difíciles de usar; las especificaciones de tipos (p. ej., el narrowing) están mal definidas; algunos ven poco beneficio frente a las pruebas.
• Algunos consideran el tipado parcial de Python como “lo peor de ambos mundos”: sigues pagando los costes del tiempo de ejecución dinámico y no puedes confiar por completo en los tipos en tiempo de ejecución.

Lenguajes dinámicos frente a lenguajes tipados estáticamente

• Un bando: si quieres tipado estricto, pásate a Rust/Go/C#/TypeScript, que ofrecen mejor rendimiento, mejores herramientas y sistemas de tipos más limpios.
• Otro bando: la migración suele ser imposible (código legacy, stacks de ML/datos, bibliotecas cliente), así que mejorar el tipado de Python sigue mereciendo la pena.
• Varios defienden los lenguajes dinámicos como productivos y expresivos; los errores por falta de tipos se consideran manejables con pruebas y buena disciplina, especialmente en frameworks web.

ML, ecosistema y herramientas

• Python sigue muy arraigado en ML/datos: NumPy/Pandas/bibliotecas de ML y su disponibilidad preinstalada lo mantienen dominante.
• Algunos sostienen que la codificación asistida por LLM erosiona las ventajas de Python: los lenguajes estáticos con compiladores potentes dan mejor retroalimentación para humanos y agentes.
• Las quejas sobre herramientas incluyen empaquetado, la ergonomía de los virtualenv y la creciente pila de linters/formateadores/comprobadores de tipos; otros dicen que herramientas como uv + ty/ruff lo resuelven en gran medida para ellos.

Sobrecarga de operadores y __eq__

• Debate sobre resultados de __eq__ que no son bool (arrays, expresiones de consulta, DSL).
• Algunos lo ven como algo potente y legible (p. ej., filtros de dataframes, ORM); otros lo consideran un “footgun” que socava la claridad y las expectativas en torno a la igualdad.