Anuncio del lanzamiento beta de ty

• ty, un verificador de tipos y servidor de lenguaje ultrarrápido para Python escrito en Rust, fue publicado en versión beta
• Fue diseñado como alternativa a mypy, Pyright y Pylance, y ofrece un rendimiento 10 a 60 veces más rápido
• Gracias a una arquitectura incremental, al modificar código solo recalcula las partes necesarias para maximizar la velocidad de respuesta en tiempo real
• Con énfasis en la precisión y la usabilidad, soporta funciones modernas del sistema de tipos como tipos de intersección, reducción avanzada de tipos y análisis de alcanzabilidad
• Astral planea desarrollar ty, junto con Ruff y uv, como una herramienta central del ecosistema de Python

---

Resumen de ty

• ty es un verificador de tipos y servidor de lenguaje para Python desarrollado por Astral e implementado en Rust
  • Fue diseñado como una alternativa mucho más rápida que mypy, Pyright y Pylance
  • Ya se usa internamente en varios proyectos de Astral y, en esta etapa beta, también se recomienda a usuarios externos
• Astral es un equipo que crea herramientas de desarrollo de alto rendimiento para el ecosistema de Python, conocido por uv (gestor de paquetes) y Ruff (linter y formateador)

Rendimiento y arquitectura

• ty fue diseñado con una estructura centrada en el servidor de lenguaje y adopta un procesamiento incremental que vuelve a ejecutar solo las operaciones necesarias al modificar archivos
  • Gracias a esto, la velocidad de actualización en tiempo real dentro del editor es muy alta
• Incluso ejecutándose sin caché, es 10 a 60 veces más rápido que mypy y Pyright
  • Ejemplo: al modificar archivos clave del repositorio de PyTorch, la velocidad de recálculo de diagnósticos es de 4.7 ms, 80 veces más rápida que Pyright (386 ms) y 500 veces más rápida que Pyrefly (2.38 segundos)
• Incluso en proyectos grandes, la diferencia de rendimiento durante las actualizaciones incrementales llega a ser de varias decenas de veces

Sistema de tipos y precisión

• ty soporta tipos de intersección (intersection types), reducción avanzada de tipos (advanced type narrowing) y análisis de alcanzabilidad basado en tipos (reachability analysis), entre otros
  • Estas funciones permiten ofrecer retroalimentación de tipos precisa y reducir falsos positivos innecesarios
• El objetivo no es solo mejorar la velocidad, sino construir un verificador de tipos que mejore tanto la precisión como la experiencia de uso

Sistema de diagnósticos

• ty incluye un sistema avanzado de diagnósticos inspirado en el sistema de mensajes de error del compilador de Rust
  • En un solo mensaje de diagnóstico presenta en conjunto el contexto de varios archivos para mostrar con claridad la causa del problema y cómo resolverlo
  • Ejemplo: al asignar incorrectamente una clave de diccionario, muestra tanto la ubicación de la incompatibilidad de tipos como la ubicación de la declaración
• La salida de diagnósticos es una interfaz central de ty y fue diseñada con una estructura fácil de entender tanto para personas como para IA

Funciones del servidor de lenguaje

• ty puede usarse en cualquier editor compatible con LSP (Language Server Protocol), como VS Code y Cursor
  • Soporta todas las funciones modernas de servidor de lenguaje, como ir a definición, renombrar símbolos, autocompletado, autoimportación, resaltado semántico de sintaxis e inlay hints
• Puede instalarse mediante la extensión de VS Code, y también como CLI con el comando uv tool install ty@latest

Planes a futuro

• Después de la beta, los objetivos de corto plazo son mejorar la estabilidad y corregir errores, completar la especificación de tipos de Python y dar soporte a Pydantic y Django
• A largo plazo, se planea ampliar ty como el motor de funciones semánticas de la cadena de herramientas de Astral
  • Se contemplan funciones como eliminación de código muerto, detección de dependencias no usadas, análisis de alcanzabilidad de vulnerabilidades de seguridad (CVE) y linting con reconocimiento de tipos
• Astral busca mejorar continuamente ty para convertir a Python en el ecosistema de programación más productivo

Agradecimientos

• En el desarrollo de ty participaron decenas de contribuidores de código abierto, y se publica bajo licencia MIT
• Diversas personas y equipos de Salsa, Elixir y la comunidad de typing de Python aportaron colaboración técnica e inspiración
• El equipo principal de Astral desarrolló ty con base en una comprensión profunda de la teoría de tipos, la semántica del runtime de Python y los patrones de uso del ecosistema

[iolothebard]

Astral, ¿es más fan de Python o de Rust…?
Muy Astral, qué se diga~

[GN⁺]

Opiniones de Hacker News

• Estaría bien que agregaran Ty a esta tabla comparativa
  Viendo la tabla de resultados de conformidad de tipado de Python, creo que no hay que subestimar el rendimiento de Pyright
  Probé Ty (LSP) un rato en Emacs y funciona bastante bien. Eso sí, me molesta un poco que, cuando muestra las firmas de métodos, las anotaciones de tipo de algunos parámetros se ven demasiado verbosas
  Aun así, creo que a largo plazo probablemente termine usando Ty. Felicidades por el primer lanzamiento beta

  • La conformidad con la especificación también importa, pero no recomendaría elegir un verificador de tipos basándose en eso
    Está bastante alejado de lo que realmente valoran los usuarios. (Yo trabajé en la especificación y las pruebas dentro del Python Typing Council)
  • Nosotros también vamos a añadirnos pronto a esa tabla. Nos tomará algo de tiempo alcanzar el nivel de conformance de Pyright, pero esa es la meta antes del lanzamiento oficial
  • Pyright también es excelente, pero BasedPyright es una versión aún más mejorada
    Aun así, soy un usuario satisfecho de uv, así que pienso cambiarme a Ty cuando sea lo suficientemente estable
  • Este PR sigue en estado WIP, pero me motivó a volver a hacer contribuciones OSS
  • Pyright es bueno, pero la velocidad es lenta. Como la capacidad de respuesta del LSP influye mucho en la UX, tengo curiosidad por ver cuánto mejoró Ty

• Astral está creando herramientas excelentes, así que ojalá crezca bien sin una monetización destructiva

  • El primer producto comercial de Astral es pyx. Ojalá tenga éxito y puedan seguir creando herramientas open source geniales
  • Creo que el trabajo que han hecho hasta ahora ha sido prácticamente un servicio público para la comunidad de Python
  • La dirección que llevan se siente parecida a bun
  • Aun así, me decepciona que digan que reemplazan completamente herramientas existentes cuando en realidad no implementan todas las funciones
    Al final hay casos en los que uno tiene que volver a las herramientas anteriores. Para mí, la verificación de tipos precisa importa más que la velocidad

• Gracias al equipo de Astral. Nosotros usamos mucho Pydantic, así que me entusiasma saber que el soporte de primera clase está previsto para el lanzamiento oficial de Ty
  Por ahora ejecutamos Pyright y Mypy juntos, pero como detectan errores distintos, se siente redundante
  Según esta tabla, Pyright sería un superset, pero mi experiencia real fue diferente
  Era un análisis de hace 2 años, así que tal vez ahora sea distinto. Me pregunto si hay casos de código base grande que se hayan unificado usando solo Pyright

  • Yo también, como usuario temprano de mypy, comparé cuando Pyright se agregó a VS Code
    Hubo muchos casos en los que mypy infería de forma más flexible y precisa, y Pyright tenía muchos false positives, al punto de que llegué a desactivarlo
    Puede que Pyright haya mejorado mucho últimamente, pero BasedPyright más bien me resultó contraproducente
    En la comunidad hay un ambiente fuerte de menospreciar mypy y alabar Pyright, pero mi experiencia fue algo distinta
  • De nuevo, las pruebas de conformidad con la especificación no reflejan la experiencia real de los usuarios
    Se centran principalmente en la semántica de las anotaciones, así que no son adecuadas como criterio para elegir un verificador de tipos
    (Yo también participé en la creación de esa especificación y esas pruebas dentro del Python Typing Council)

• Creo que el título “Anuncio del lanzamiento beta de Ty” habría sido más apropiado
  Yo prefería Pyrefly sobre Pyright, pero hace poco tuve que fijarlo a una versión anterior por un bug y fue incómodo
  Intenté instalar Ty, pero me apareció un error de compatibilidad con la versión de Cursor

  • Si tienes algún mensaje de error adicional, por favor registra un issue. Llevo varias semanas usando bien la extensión de Ty en Cursor, así que me cuesta reproducirlo
  • (Soy el mantenedor de Pyrefly) También estaría bien que dejaras ese crash como issue en el repositorio de Pyrefly

• Todavía no entiendo por qué sigue habiendo tantos verificadores de tipos para un mismo lenguaje
  ¿Los creadores de librerías tienen que probar con todos los verificadores? ¿Los desarrolladores solo deberían usar librerías que soporten cierto verificador?

  • Python es un lenguaje de duck typing + anotaciones de tipo opcionales, así que inevitablemente pueden surgir implementaciones diversas
  • Parte de eso se debe a diferencias en el alcance de la inferencia del lado del llamador o en las políticas que exigen tipos explícitos
    En los límites entre paquetes se necesitan tipos explícitos, pero dentro del código interno hay mucha ambigüedad
    Astral, en particular, está tomando el rendimiento del procesamiento incremental como un objetivo principal de diseño
  • En la práctica, la mayoría prueba principalmente con mypy. Pyright está ampliando cada vez más su influencia gracias a la extensión predeterminada de VS Code
    Si hace falta, también se puede asegurar compatibilidad proporcionando directamente type stubs

• Me gusta que Ty adopte la postura de que “no hace falta agregar anotaciones para satisfacer al verificador de tipos”
  Los verificadores anteriores molestaban con advertencias triviales, pero Ty detecta bien los errores lógicos reales

• Hoy me enteré por primera vez de que Ty también funciona como servidor de lenguaje (LSP)
  Es decir, puede reemplazar tanto a mypy como a Pyright en Neovim o VSCode

• Me pregunto qué tal es el soporte para Django. Django tiene mucho código mágico, así que es difícil de manejar para los verificadores de tipos

  • Ty todavía no soporta Django y tampoco tiene sistema de plugins
    Si usas Django, por ahora conviene seguir con mypy o Pyright

• Aunque Ty no fuera rápido, creo que solo con el soporte para tipos de intersección (A & B) ya valdría la pena usarlo
  Me alegra ver una función que falta en el sistema de tipos estándar de Python

• Me pregunto si Ruby tiene algo como uv. En Python o TypeScript uso uv o bun, pero Ruby se siente algo rezagado

  • Existe una nueva herramienta de gestión para Ruby llamada Rv. Tal vez esa podría ser la alternativa