Annonce de la sortie de la bêta de ty
(astral.sh)- ty, un vérificateur de types Python et serveur de langage ultra-rapide écrit en Rust, est désormais disponible en version bêta
- Conçu comme une alternative à mypy, Pyright et Pylance, il offre des performances 10 à 60 fois supérieures
- Grâce à une architecture incrémentale, il ne recalcule que les parties nécessaires lors des modifications du code afin de maximiser la réactivité en temps réel
- En mettant l’accent sur la précision et l’utilisabilité, il prend en charge des fonctionnalités modernes du système de types comme les types d’intersection, le narrowing avancé et l’analyse d’atteignabilité
- Astral prévoit de faire de ty, aux côtés de Ruff et uv, un outil de développement central de l’écosystème Python
Présentation de ty
- ty est un vérificateur de types Python et serveur de langage développé par Astral et implémenté en Rust
- Il a été conçu comme une alternative bien plus rapide aux outils existants comme mypy, Pyright et Pylance
- Il est déjà utilisé dans les projets internes d’Astral, et son usage est désormais recommandé aux utilisateurs externes pendant la phase bêta
- Astral est une équipe qui conçoit des outils de développement hautes performances pour l’écosystème Python, connue pour uv (gestionnaire de paquets) et Ruff (linter et formateur)
Performances et architecture
- ty a été conçu autour d’une architecture centrée sur le serveur de langage et adopte un traitement incrémental qui ne relance que les calculs nécessaires lorsqu’un fichier est modifié
- Cela se traduit par des mises à jour en temps réel très rapides dans l’éditeur
- Même exécuté sans cache, il est 10 à 60 fois plus rapide que mypy et Pyright
- Exemple : lors de la modification d’un fichier majeur dans le dépôt PyTorch, le recalcul des diagnostics prend 4.7ms, soit 80 fois plus rapide que Pyright (386ms) et 500 fois plus rapide que Pyrefly (2.38 secondes)
- Même sur de très grands projets, l’écart de performance lors des mises à jour incrémentales atteint plusieurs dizaines de fois
Système de types et précision
- ty prend en charge les types d’intersection (intersection types), le narrowing avancé de types (advanced type narrowing) et l’analyse d’atteignabilité basée sur les types (reachability analysis)
- Ces fonctions permettent de fournir des retours de type précis tout en réduisant les faux positifs inutiles
- L’objectif n’est pas seulement d’améliorer la vitesse, mais de construire un vérificateur de types qui améliore à la fois la précision et l’expérience utilisateur
Système de diagnostic
- ty inclut un système de diagnostic avancé inspiré du système de messages d’erreur du compilateur Rust
- Un même diagnostic peut présenter le contexte de plusieurs fichiers afin de rendre plus claire l’origine du problème et la manière de le résoudre
- Exemple : lors d’une affectation incorrecte de clé de dictionnaire, il affiche à la fois l’emplacement de l’incompatibilité de type et celui de la déclaration
- La sortie des diagnostics constitue l’interface centrale de ty et a été conçue dans une structure facile à comprendre à la fois pour les humains et pour l’IA
Fonctionnalités du serveur de langage
- ty peut être utilisé dans VS Code, Cursor et tous les éditeurs compatibles avec le LSP (Language Server Protocol)
- Il prend en charge toutes les fonctionnalités modernes d’un serveur de langage, comme aller à la définition, renommage de symboles, autocomplétion, auto-import, coloration syntaxique sémantique et inlay hints
- Il peut être installé via l’extension VS Code, et la CLI peut aussi être installée avec la commande
uv tool install ty@latest
Feuille de route
- Après la bêta, les objectifs à court terme sont le renforcement de la stabilité et la correction de bugs, la finalisation de la spécification de typage Python, ainsi que la prise en charge de Pydantic et Django
- À plus long terme, Astral prévoit d’étendre ty comme moteur de fonctionnalités sémantiques de sa chaîne d’outils
- Sont notamment prévus : suppression de code mort, détection des dépendances inutilisées, analyse d’atteignabilité des vulnérabilités de sécurité (CVE) et linting sensible aux types
- Astral entend améliorer continuellement ty afin de faire de Python l’écosystème de programmation le plus productif
Remerciements
- Le développement de ty a impliqué des dizaines de contributeurs open source, et le projet est publié sous licence MIT
- Plusieurs personnes et équipes issues de Salsa, Elixir et de la communauté du typage Python ont apporté une collaboration technique et une source d’inspiration
- L’équipe centrale d’Astral a développé ty sur la base d’une compréhension approfondie de la théorie des types, de la sémantique du runtime Python et des schémas d’usage de l’écosystème
2 commentaires
Astral est plutôt fan de Python ou de Rust…
C’est très Astral, tout ça~
Réactions sur Hacker News
Ce serait bien d’ajouter Ty à ce tableau comparatif
En regardant les résultats de conformité du typage Python, je pense qu’il ne faut pas sous-estimer les performances de Pyright
J’ai brièvement testé Ty (LSP) dans Emacs, et ça fonctionne plutôt bien. En revanche, quand les signatures de méthodes s’affichent, les annotations de type de certains paramètres me paraissent un peu trop verbeuses
Malgré ça, je pense qu’à long terme j’utiliserai probablement Ty. Félicitations pour cette première bêta
C’est assez éloigné de ce que les utilisateurs réels jugent important. (J’ai contribué à créer cette spécification et ces tests au sein du Python Typing Council)
Cela dit, je suis un utilisateur satisfait de uv, donc dès que Ty sera suffisamment stable, je compte migrer
Astral construit d’excellents outils, donc j’espère qu’ils vont bien grandir sans monétisation agressive
Au final, on se retrouve parfois obligé de revenir aux outils historiques. Pour moi, une vérification de types précise est plus importante que la vitesse
Merci à l’équipe d’Astral. Nous utilisons beaucoup Pydantic, donc savoir qu’un support de premier ordre est prévu pour la version finale de Ty est très encourageant
Pour l’instant, nous faisons tourner Pyright et Mypy en parallèle, et comme ils détectent des erreurs différentes, cela donne une impression de redondance
D’après ce tableau, Pyright serait un superset, mais mon expérience concrète a été différente
C’était une analyse d’il y a 2 ans, donc la situation a peut-être changé. Je me demande s’il existe des cas d’unification sur Pyright seul dans de grosses bases de code
Il y avait beaucoup de cas où mypy inférait de façon plus souple et plus juste, et Pyright produisait tellement de faux positifs que je l’ai parfois désactivé
Pyright s’est sans doute beaucoup amélioré depuis, mais BasedPyright a au contraire été contre-productif pour moi
Dans la communauté, on sent une forte tendance à rabaisser mypy et à encenser Pyright, mais mon expérience est un peu différente
Ils se concentrent surtout sur la sémantique des annotations, donc ce n’est pas un bon critère pour choisir un vérificateur de types
(Moi aussi, j’ai participé à la création de cette spécification et de ces tests au sein du Python Typing Council)
Le titre aurait sans doute été plus approprié avec « annonce de la sortie bêta de Ty »
Je préférais Pyrefly à Pyright, mais un bug récent m’a forcé à rester bloqué sur une ancienne version, ce qui est pénible
J’ai essayé d’installer Ty, mais j’ai eu une erreur de compatibilité de version avec Cursor
Je ne comprends toujours pas pourquoi il existe autant de vérificateurs de types pour un seul langage
Les auteurs de bibliothèques doivent-ils tester avec tous les vérificateurs ? Les développeurs doivent-ils se limiter aux bibliothèques qui prennent en charge un vérificateur donné ?
Aux frontières des packages, des types explicites sont nécessaires, mais dans le code interne il y a beaucoup d’ambiguïté
Chez Astral, la performance du traitement incrémental est notamment un objectif de conception majeur
Si nécessaire, on peut aussi fournir directement des type stubs pour garantir la compatibilité
J’aime bien le fait que Ty adopte la position selon laquelle « il n’est pas nécessaire d’ajouter des annotations pour satisfaire le vérificateur de types »
Les vérificateurs précédents étaient agaçants avec des avertissements mineurs, alors que Ty détecte bien les vraies erreurs logiques
Je découvre seulement aujourd’hui que Ty fait aussi office de serveur de langage (LSP)
Autrement dit, il peut remplacer à la fois mypy et Pyright dans Neovim ou VSCode
Je me demande ce qu’il en est du support de Django. Django contient beaucoup de code magique, donc c’est difficile à gérer pour les vérificateurs de types
Si vous utilisez Django, mieux vaut garder mypy ou Pyright pour le moment
Même si Ty n’était pas rapide, je pense qu’il vaudrait déjà le coup rien que pour le support des types d’intersection (A & B)
C’est une fonctionnalité absente du système de types Python standard, donc c’est appréciable
Je me demande s’il existe un équivalent de uv pour Ruby. J’utilise uv ou bun pour Python et TypeScript, mais Ruby donne l’impression d’être à la traîne