Pyrefly - un nuevo verificador de tipos y experiencia de IDE para Python

• Pyrefly de Meta es un verificador de tipos para Python de código abierto y una extensión para IDE desarrollada en Rust
• Ofrece análisis ultrarrápido e integración con IDE, y fue creado para superar las limitaciones de Pyre
• Adopta como principios la inferencia automática de tipos, el soporte para bases de código grandes y la filosofía de código abierto
• Busca mejorar el sistema de tipos en todo el ecosistema mediante colaboración y aportes con la comunidad de Python
• Actualmente se lanzó en versión alfa y están solicitando activamente comentarios y contribuciones de la comunidad

---

Introducción

• Pyrefly es un proyecto de código abierto de Meta: un verificador estático de tipos para Python y una extensión para IDE, desarrollado en Rust
• Ayuda a detectar errores de forma anticipada al verificar la consistencia de tipos antes de ejecutar el código
• Puede usarse tanto con integración en IDE como desde CLI, lo que ofrece un flujo de trabajo flexible
• Su objetivo es contribuir al avance del sistema de tipos de Python y de distintas bibliotecas mediante la colaboración con la comunidad de código abierto

Contexto del desarrollo de Pyrefly

• En 2017, Meta desarrolló un nuevo verificador de tipos, que luego sería Pyre, para la gran base de código en Python de Instagram
• Pyre tomó como referencia diseños sólidos como Hack y Flow, y fue desarrollado en OCaml por razones de rendimiento
• Con el tiempo surgieron limitaciones a medida que crecían las necesidades de evolución del sistema de tipos y de integración con IDE
• También usaron herramientas de la comunidad como Pyright, pero como no cubrían del todo requisitos como la exploración de código a gran escala o la exportación de tipos, intentaron desarrollar Pyrefly

Principios principales de Pyrefly

• 1. Rendimiento

  • Los desarrolladores necesitan una verificación de tipos rápida en cada pulsación de tecla justo después de escribir código
  • Pyrefly está construido en Rust con una arquitectura de alto rendimiento capaz de analizar 1.8 millones de líneas por segundo incluso en bases de código enormes

• 2. Diseño centrado en el IDE

  • Desde el inicio se diseñaron las abstracciones para que IDE y CLI mantengan la misma visión
  • En Pyre esto se añadió después, pero en Pyrefly la consistencia se enfatiza desde la fase de diseño

• 3. Inferencia

  • Incluso en código Python sin anotaciones ni tipos explícitos, ofrece inferencia automática de tipos
  • Muestra en el IDE los tipos de valores de retorno y variables locales, y para ayudar a escribir mejor código, permite insertar automáticamente el tipo inferido al hacer doble clic

• 4. Código abierto

  • Pyrefly está publicado en GitHub bajo licencia MIT, y reciben con gusto PR e informes de issues de la comunidad
  • Busca una comunicación activa a través de un canal de Discord, en vínculo con el ecosistema de Python y bibliotecas clave de Meta como PyTorch

El futuro de Pyrefly

• Está avanzando con el objetivo de mejorar el lenguaje Python y la experiencia de los desarrolladores junto con la comunidad
• Desde los inicios del desarrollo de Pyre se mantuvo la apertura del código y la contribución a PEP, y con Pyrefly planean maximizar las ventajas del uso de tipos para desarrolladores, bibliotecas y principiantes
• Meta planea compartir diversas experiencias basadas en su uso de tipos en lenguajes dinámicos y en sus resultados, para impulsar una mejora en la calidad de los tipos dentro del ecosistema
• Actualmente Pyrefly está en versión alfa, pero siguen trabajando en corrección de errores y nuevas funciones con el objetivo de un lanzamiento oficial este verano
• Los comentarios de la comunidad son muy importantes, y piden activamente reportes de issues y solicitudes de mejora tras usar Pyrefly

Guía sobre el uso de la versión alfa de Pyrefly y la comunidad

• El proceso de desarrollo de Pyrefly y sus detalles técnicos se presentaron en Meta Tech Podcast y en charlas como PyCon US
• También comparten más novedades a través de distintos canales como sitios relacionados con Meta Open Source, YouTube, Facebook, Threads, X y LinkedIn

[GN⁺]

Opiniones en Hacker News

• Se forma una ligera preocupación en nombre del "Python Language Tooling Team" de Meta; como uv es tan popular, da la sensación de que ty podría ganar en este espacio. Si sale mal, podría darse una situación como Atom o Flow, donde un equipo interno termina siendo desplazado por open source externo y desde arriba empiece a surgir el ambiente de "¿de verdad necesitamos este equipo? Mejor pasémoslo a open source". Parece ser algo a lo que la gerencia (¿Aaron Pollack?) debería prestar atención.
  • Kevin saluda y menciona que trabajó antes en Flow y que ahora forma parte del equipo de Pyrefly. Explica que esta vez tomaron un enfoque distinto al de Flow y dejaron claro que open source y la construcción de comunidad son prioridades. Comparte que recientemente hubo bastante volatilidad relacionada con la inversión en infraestructura de las empresas, pero que cree que este es el punto de partida correcto del camino, y agradece el apoyo.
  • Opinión de que Meta valora mucho mantener el control sobre los proyectos open source de herramientas de desarrollo. Cuenta la anécdota de que en el pasado el mantenedor de git señaló el uso de monorepo y rechazó mejoras upstream, lo que llevó a migrar a mercurial; del lado de mercurial sí aceptaron con gusto las contribuciones. Explica que, como las herramientas internas cambian tan rápido, tiene sentido ser dueño de los propios proyectos.
  • Comentario de que lo que más le gusta de lo que salió de Facebook es JSX (probablemente lo único que considera realmente bueno).
• Presentación de alguien que dice trabajar en el equipo de Pyrefly de Meta; comenta que muchas preguntas están cubiertas en el FAQ y deja un enlace de referencia. También se muestra amable diciendo que puede responder preguntas adicionales y agradece el interés.
• Observación de que últimamente han aparecido tres type checkers de Python escritos en Rust (Microsoft, Facebook, Astral), mientras mypy sigue existiendo.
  • Corrección de que el type checker de Microsoft, Pyright, está basado en Typescript; aun así comparte la experiencia personal de que sigue siendo más rápido que mypy.
  • Pregunta de si todos son type checkers estáticos, con la mención de que no hay ninguno para runtime.
• Aunque este es el anuncio oficial, se comenta que Pyrefly ya había sido discutido hace unas semanas. Actualmente se está lanzando en fase alfa, y se cita la postura oficial del equipo: están enfocados en corregir bugs y desarrollar funciones, con la meta de quitarle la etiqueta alfa en verano.
• El código Rust escrito aquí es muy fácil de entender, pero se expresa preocupación por que últimamente las herramientas de Python se sigan escribiendo en Rust, junto con el temor de caer en otro problema de N lenguajes. Se espera que Mojo pueda aportar algo aquí.
  • Se explica que en el ecosistema Python es natural usar Python donde Python alcanza, y usar lenguajes como Rust o C donde se necesita alto rendimiento. Al final N=3 (Python, Rust y C), aunque se desea que C desaparezca gradualmente del programming de aplicaciones a largo plazo. Aun así, parece que en la práctica tomará mucho tiempo; incluso Python podría volverse legacy antes.
• Da gusto ver que se explican formas de integrarlo con Vim/Neovim, y se comparte un enlace relacionado.
• Se cuestiona por qué el hecho de estar escrito en Rust se menciona como una gran ventaja. La mayoría no ejecuta un type checker en sistemas embebidos o servicios mission-critical, así que se siente parecido a decir "escrito en Erlang". Si no es código donde el rendimiento sea crucial, escribirlo en Python permitiría más participación y expansión de la comunidad; se pregunta por qué tanta insistencia en Rust.
  • Se comparte experiencia usando Rust: como usuario, aporta velocidad y seguridad; desde la perspectiva del desarrollador, facilita contribuir. También se considera que parte del atractivo de Astral es precisamente llevar este tipo de herramientas basadas en Rust a Python. Aunque conoce mejor Python que Rust, siente que es más fácil contribuir a proyectos en Rust. Opina que portar herramientas de calidad de Rust a Python es el objetivo general.
  • Se considera que el LSP (Language Server Protocol) sí es código donde el rendimiento importa mucho, porque afecta directamente la capacidad de respuesta del IDE. Rust es muy eficiente tanto en CPU como en memoria. Si estuviera escrito en OCaml, Reason, Haskell, etc., probablemente también tendría suficiente velocidad y eficiencia, pero el grupo de contribuidores sería muy limitado.
  • Satisface que al buscar "[descripción de herramienta] rust" se pueda encontrar software de buen rendimiento con facilidad. Comparte la experiencia de que alrededor del 95% de las herramientas que usa están escritas en Rust y que está satisfecho con la mayoría.
  • Se usa Rust casi como una abreviatura de "notablemente rápido", y se enfatiza que el open source en Rust sigue siendo revisable.
  • Se explica que los type checkers escritos en Python se quedan cortos en rendimiento. Por ejemplo, se argumenta que linters hechos en Python como Pylint revisan una línea de código a la vez y tardan más de 30 segundos, por lo que sí es un área sensible al rendimiento.
• Curiosidad sobre la transición de Pyre a Pyrefly y la reescritura total en Rust; se pregunta cuáles fueron los beneficios o motivaciones concretas para pasar de un lenguaje menos conocido a un Rust más trendy.
  • Se responde que esa pregunta se aborda en el FAQ, y que cuando acumulen más experiencia les gustaría hablar del tema en un post largo del blog. También comparten un enlace.
• Opinión de que parece un proyecto que intenta resolver demasiadas cosas al mismo tiempo.
• Comentario de que perdió el interés al ver VS Code; no entiende por qué la gente considera que VS Code es adecuado como IDE para Python, cuando existe un IDE "de verdad" como PyCharm, así que no ve razón para usar VS Code.
  • Se responde que pyrefly no está atado solo a vscode, y se pide un poco más de consideración hacia que distintas personas tienen distintas preferencias. pycharm tampoco es objetivamente mejor. La persona comenta que le resulta cómodo el desarrollo remoto en vscode, y que no le gustaría ir a internet a decir que pycharm le parece malo.