Pyrefly - un nouveau vérificateur de types et une nouvelle expérience IDE pour Python

• Pyrefly de Meta est un vérificateur de types Python open source ainsi qu’une extension pour IDE, développé en Rust
• Il prend en charge une analyse ultra-rapide et l’intégration IDE, et a été conçu pour dépasser les limites de Pyre
• Il repose sur l’inférence automatique des types, la prise en charge des grandes bases de code et une philosophie open source comme principe fondamental
• Son objectif est d’améliorer le système de types dans l’ensemble de l’écosystème grâce à la collaboration et aux contributions de la communauté Python
• Une version alpha est actuellement disponible, et les retours ainsi que les contributions de la communauté sont activement sollicités

---

Présentation

• Pyrefly est un vérificateur de types statique pour Python développé en Rust par Meta, ainsi qu’un projet open source d’extension IDE
• Il aide à détecter les erreurs en amont en vérifiant la cohérence des types avant l’exécution du code
• Il peut être utilisé à la fois via l’intégration IDE et en CLI, offrant ainsi un workflow flexible
• L’objectif est de contribuer à l’évolution du système de types de Python et de diverses bibliothèques via la collaboration avec la communauté open source

Contexte du développement de Pyrefly

• En 2017, Meta a développé un nouveau vérificateur de types, devenu ensuite Pyre, pour la vaste base de code Python d’Instagram
• Pyre s’inspirait d’une conception robuste, notamment de Hack et Flow, et a été développé en OCaml pour des raisons de performance
• Avec le temps, des limites sont apparues à mesure que les besoins en évolution du système de types et en intégration IDE grandissaient
• Meta a également utilisé des outils de la communauté comme Pyright, mais face à des exigences comme l’exploration de code à grande échelle et l’export de types, ces outils avaient leurs limites, ce qui a conduit au développement de Pyrefly

Principes clés de Pyrefly

• 1. Performance

  • Les développeurs ont besoin d’une vérification de types rapide à chaque frappe juste après avoir écrit du code
  • Pyrefly adopte une architecture Rust haute performance capable d’analyser 1,8 million de lignes par seconde, même sur des bases de code extrêmement volumineuses

• 2. Conception centrée sur l’IDE

  • Les abstractions ont été conçues dès le départ pour que l’IDE et la CLI partagent la même vision du code
  • Dans Pyre, cela relevait d’ajustements a posteriori, alors que Pyrefly met l’accent sur la cohérence dès la phase de conception

• 3. Inférence

  • Même pour du code Python sans annotations ni types explicitement déclarés, Pyrefly prend en charge l’inférence automatique des types
  • Il affiche dans l’IDE le type des valeurs de retour et des variables locales, et peut insérer automatiquement le type inféré par double-clic pour faciliter l’écriture d’un meilleur code

• 4. Open source

  • Pyrefly est publié sur GitHub sous licence MIT, et les PR de la communauté comme les signalements d’issues sont les bienvenus
  • Il vise une communication active via un canal Discord, en lien avec l’écosystème Python et les principales bibliothèques de Meta comme PyTorch

L’avenir de Pyrefly

• Le projet avance avec la communauté avec pour objectif d’améliorer le langage Python et l’expérience développeur
• Depuis les débuts de Pyre, Meta a maintenu l’ouverture du code source et sa contribution aux PEP ; avec Pyrefly, l’entreprise prévoit aussi de maximiser les bénéfices de l’usage des types pour divers développeurs, bibliothèques et débutants
• En s’appuyant sur son expérience et ses résultats dans l’usage des types dans les langages dynamiques, Meta prévoit de partager largement son savoir-faire et de faire progresser la qualité du typage dans l’écosystème
• Pyrefly est actuellement en version alpha, mais vise un lancement officiel cet été, avec des correctifs de bugs et ajouts de fonctionnalités en continu
• Les retours de la communauté sont essentiels, et Meta encourage activement les utilisateurs de Pyrefly à signaler des issues et demander des améliorations

Utilisation de la version alpha de Pyrefly et informations sur la communauté

• Le processus de développement de Pyrefly et ses détails techniques ont été présentés dans le Meta Tech Podcast ainsi que lors d’interventions à PyCon US
• Des informations supplémentaires sont diffusées via différents canaux, notamment les sites liés à Meta Open Source, YouTube, Facebook, Threads, X et LinkedIn

[GN⁺]

Commentaires sur Hacker News

• Une certaine inquiétude exprimée au nom de la « Python Language Tooling Team » de Meta : avec l’énorme popularité de uv, il y a le pressentiment que ty pourrait l’emporter dans ce domaine ; en cas d’échec, on pourrait voir se former en interne une ambiance du type « cette équipe est-elle vraiment nécessaire ? Passons à l’open source », comme cela s’était produit avec Atom ou Flow ; c’est probablement un point auquel le management (Aaron Pollack ?) devrait prêter attention
  • Kevin salue tout le monde et mentionne avoir travaillé autrefois sur Flow ; il est maintenant dans l’équipe Pyrefly ; cette fois, l’approche est différente de celle de Flow, avec une priorité clairement donnée à l’open source et à la construction d’une communauté ; il partage aussi l’idée que, malgré la forte volatilité récente autour des investissements d’infrastructure dans les entreprises, ils pensent être aujourd’hui au bon point de départ pour ce parcours, et remercie pour les encouragements
  • Avis selon lequel Meta accorde une grande importance au contrôle de ses projets open source, en particulier pour les outils de développement ; anecdote sur le passage à mercurial après qu’un mainteneur de git avait critiqué l’usage du monorepo et refusé les améliorations en amont, alors que mercurial acceptait volontiers les contributions ; comme les outils internes évoluent très vite, posséder son propre projet paraît logique
  • Parmi ce qui est sorti de Facebook, JSX est ce qui plaît le plus (et peut-être la seule chose jugée vraiment bien)
• Présentation d’une personne disant travailler dans l’équipe Pyrefly chez Meta ; beaucoup de questions sont couvertes dans la FAQ, avec un lien fourni pour référence ; elle indique aussi pouvoir répondre à d’autres questions et remercie pour l’intérêt porté au projet
• Observation qu’on voit désormais trois type checkers Python écrits en Rust apparaître en même temps (Microsoft, Facebook, Astral), alors que mypy existe toujours
  • Correction : le type checker de Microsoft, Pyright, est basé sur Typescript ; malgré cela, selon l’expérience personnelle partagée, il reste plus rapide que mypy
  • Question de savoir s’il s’agit uniquement de type checkers statiques, avec la remarque qu’il n’y a rien pour le runtime
• Information selon laquelle il s’agit de l’annonce officielle, mais que Pyrefly avait déjà été évoqué il y a quelques semaines ; citation de la position officielle de l’équipe : le projet est actuellement publié au stade alpha, avec un focus sur les corrections de bugs et le développement de fonctionnalités, et l’objectif est de sortir de l’étiquette alpha d’ici l’été
• Le code Rust montré ici est très facile à comprendre, mais inquiétude face au fait que les outils Python soient de plus en plus souvent écrits en Rust, avec la crainte de retomber dans un autre problème des N langages ; espoir que Mojo puisse apporter quelque chose sur ce point
  • Explication que, dans l’écosystème Python, il est naturel d’utiliser Python là où Python suffit, et des langages comme Rust ou C là où de hautes performances sont nécessaires ; au final, N=3 (Python, Rust, C), même si l’on souhaiterait que C disparaisse progressivement à long terme du développement applicatif ; dans les faits, cela prendra probablement très longtemps, et Python lui-même pourrait devenir legacy avant cela
• Satisfaction de voir qu’un guide d’intégration pour Vim/Neovim est proposé, avec un lien associé
• Interrogation sur le fait que l’implémentation en Rust soit présentée comme un si grand avantage : la plupart des gens ne font pas tourner un type checker sur des systèmes embarqués ou des services critiques ; cela donne presque la même impression que « écrit en Erlang » ; pour tout code où la performance n’est pas cruciale, l’écrire en Python permettrait davantage de participation et d’extension par la communauté ; questionnement sur cette fixation sur Rust
  • Retour d’expérience avec Rust : du point de vue utilisateur, vitesse et sécurité sont des avantages ; du point de vue développeur, les contributions sont facilitées ; l’attrait d’Astral tiendrait justement au fait d’apporter à Python ce type d’outils basés sur Rust ; bien que connaissant mieux Python que Rust, cette personne trouve plus facile de contribuer à des projets Rust ; avis selon lequel porter dans Python des outils de qualité Rust est l’objectif général
  • Le LSP (Language Server Protocol) est considéré comme un domaine où la performance compte énormément, car cela influence directement la réactivité de l’IDE ; Rust est très efficace à la fois en CPU et en mémoire ; si c’était écrit en OCaml, Reason, Haskell ou d’autres langages du genre, on obtiendrait sans doute aussi une bonne vitesse et efficacité, mais avec un vivier de contributeurs beaucoup plus limité
  • Satisfaction à l’idée qu’une recherche du type « [description d’outil] rust » permette de trouver facilement des logiciels performants ; environ 95 % des outils utilisés par cette personne sont écrits en Rust, et la plupart donnent satisfaction
  • Rust est utilisé presque comme une abréviation signifiant « visiblement rapide », tout en rappelant qu’un projet open source en Rust reste parfaitement révisable
  • Explication qu’un type checker écrit en Python manque de performances ; exemple donné avec des linters Python comme Pylint, qui peuvent prendre plus de 30 secondes en effectuant des vérifications ligne par ligne, ce qui montrerait bien que c’est un domaine où la performance compte
• Curiosité sur la transition de Pyre vers Pyrefly et sur la réécriture complète en Rust : quels avantages concrets ou quelles motivations ont conduit à passer d’un langage moins connu à Rust, plus tendance ?
  • Réponse indiquant que cette question est traitée dans la FAQ ; avec davantage de recul, l’équipe aimerait aussi en parler dans un long billet de blog ; un lien est fourni
• Avis selon lequel le projet donne l’impression de vouloir résoudre trop de choses à la fois
• Perte d’intérêt en voyant VS Code ; incompréhension face à l’idée que certains considèrent VS Code comme un IDE adapté à Python, alors qu’un « vrai IDE » comme PyCharm existe déjà
  • pyrefly n’est pas limité à vscode ; demande de faire un peu plus de place au fait que différentes personnes ont différentes préférences ; pycharm n’est pas non plus objectivement meilleur en tout ; cette personne trouve le développement distant de vscode pratique et n’a pas envie d’aller poster sur Internet que pycharm est mauvais