Los tipos en Python tienen un problema de expectativas

Artículo original ↗ Discusión en Hacker News ↗

Los hints de tipos de Python están bajo escrutinio por crear un “desajuste de expectativas”: parecen un sistema de tipos integrado, pero no ofrecen garantías a menos que añadas herramientas externas como mypy o pyright y las conectes a tu editor, CI o pipeline de despliegue. Los comentaristas debaten si Python debería ofrecer enforcement más estricto y opcional, similar a TypeScript o Rust, comparten estrategias prácticas y puntos de dolor al tipar gradualmente codebases heredadas grandes, y señalan bibliotecas como Pydantic o comprobaciones en tiempo de ejecución al estilo Sorbet como soluciones parciales. Las opiniones divergen sobre el valor general del tipado estático en un lenguaje dinámico: algunos citan mejor tooling, seguridad en refactors y detección temprana de bugs, mientras que otros argumentan que añade verbosidad sin evidencia clara de menos defectos.

Desajuste de expectativas: hints de tipos vs. enforcement

  • Muchos ven un desajuste: los hints de tipos están en la biblioteca estándar y en la sintaxis, pero CPython los ignora en tiempo de ejecución y no se ejecuta ningún checker por defecto.
  • Algunos sostienen que Python nunca iba a incluir un verificador de tipos completo; las herramientas externas (mypy, pyright) son la solución práctica, análoga a los compiladores de TypeScript.
  • Otros querrían un modo “estricto” o de envoltura que ejecute un verificador de tipos antes de la ejecución, especialmente para despliegues (por ejemplo, fallar rápido al arrancar en Kubernetes en lugar de en tiempo de ejecución).

Versionado, errores y herramientas

  • La sintaxis más nueva de typing (por ejemplo, dict[int, int]) en versiones antiguas de Python produce errores de tiempo de ejecución confusos (“type object is not subscriptable”).
  • from __future__ import annotations no resuelve esto por completo; hay errores en casos límite y comportamientos oscuros.
  • Los IDEs (VS Code, PyCharm) suelen usar los hints de tipos para autocompletado, aunque la cobertura es incompleta y a menudo depende de paquetes stub.

Adopción gradual en codebases heredadas

  • Adoptar typing en codebases grandes y sin tipado se describe como doloroso:
    • Ejecutar mypy en todo el repositorio genera una avalancha inmanejable de errores, así que las comprobaciones de CI a menudo se ignoran.
    • Los enfoques de “seed file” (listar manualmente archivos para comprobar tipos) añaden fricción y cambios constantes en CI.
  • Estrategias sugeridas: usar la configuración por módulo de mypy, desactivar al principio el seguimiento de imports, tipar primero los módulos hoja y endurecer la estricticidad con el tiempo.
  • Los hooks de mypy en pre-commit se ven como demasiado lentos y disruptivos; se prefiere solo CI.

Expresividad y uso en tiempo de ejecución

  • Python puede modelar comportamientos complejos: uniones, overloads, TypeVars y tipos recursivos, pero a menudo con patrones verbosos (@overload, grandes conjuntos de stubs) y límites prácticos.
  • Algunos usan anotaciones en tiempo de ejecución (por ejemplo, Pydantic, cargadores personalizados de JSON/dataclass, bibliotecas de typing estricto), pero esto es más lento y no es oficialmente el objetivo de diseño.

Debate typing vs. productividad

  • Un bando afirma que el tipado estático en Python añade boilerplate, alarga el desarrollo y puede aumentar los bugs por funcionalidad; sostienen que la mayoría de los bugs son de comportamiento y requieren tests de todos modos, y que el typing de Python no es lo bastante fuerte para enormes monolitos.
  • Otros lo discuten enérgicamente, citando grandes codebases de Python tipado donde las anotaciones mejoraron la comprensión, el soporte del IDE, los refactors y detectaron bugs reales antes.
  • Las afirmaciones empíricas sobre tasas de bugs y efectividad del typing están en disputa; el hilo no presenta un consenso claro ni evidencia definitiva.

Documentación vs. anotaciones inline

  • Algunos prefieren docstrings ricos (o hints basados en comentarios) en lugar de sintaxis de tipos inline por legibilidad, queriendo “código puro” con los tipos como metadatos secundarios.
  • Otros sostienen que la mejor práctica es usar ambos: hints inline para las herramientas y para una comprensión rápida, además de docstrings para semántica de más alto nivel.