Ankündigung der Beta-Veröffentlichung von ty

 (astral.sh)
7 Punkte von GN⁺ 2025-12-17 | 2 Kommentare | Auf WhatsApp teilen
  • ty, ein in Rust geschriebener ultraschneller Python-Type-Checker und Language Server, wurde als Beta-Version veröffentlicht
  • Er wurde als Alternative zu mypy, Pyright und Pylance entwickelt und bietet eine 10- bis 60-fach höhere Leistung
  • Durch eine inkrementelle Architektur werden bei Code-Änderungen nur die erforderlichen Teile neu berechnet, um die Reaktionsgeschwindigkeit in Echtzeit zu maximieren
  • Mit Fokus auf Genauigkeit und Benutzerfreundlichkeit unterstützt ty moderne Features des Type-Systems wie Intersection Types, fortgeschrittenes Type Narrowing und Reachability Analysis
  • Astral plant, ty gemeinsam mit Ruff und uv zu einem zentralen Entwicklungswerkzeug des Python-Ökosystems auszubauen

Überblick über ty

  • ty ist ein von Astral entwickelter Python-Type-Checker und Language Server, implementiert in Rust
    • Er wurde als deutlich schnellere Alternative zu mypy, Pyright und Pylance konzipiert
    • Er wird bereits in Astrals internen Projekten umfassend eingesetzt und wird in der Beta-Phase auch externen Nutzern empfohlen
  • Astral ist ein Team, das hochperformante Entwicklungswerkzeuge für das Python-Ökosystem entwickelt, und ist bekannt für uv (Paketmanager) und Ruff (Linter und Formatter)

Leistung und Architektur

  • ty wurde mit einer Language-Server-zentrierten Struktur entworfen und verwendet einen inkrementellen Verarbeitungsansatz, bei dem bei Dateiänderungen nur notwendige Berechnungen erneut ausgeführt werden
    • Dadurch sind Echtzeit-Updates im Editor sehr schnell
  • Selbst bei Ausführung ohne Cache ist ty 10- bis 60-mal schneller als mypy und Pyright
    • Beispiel: Bei der Änderung zentraler Dateien im PyTorch-Repository beträgt die Zeit zur Neuberechnung der Diagnosen 4,7 ms und ist damit 80-mal schneller als Pyright (386 ms) und 500-mal schneller als Pyrefly (2,38 Sekunden)
  • Auch in großen Projekten beträgt der Leistungsunterschied bei inkrementellen Updates oft ein Vielfaches von mehreren Dutzend

Type-System und Genauigkeit

  • ty unterstützt Intersection Types, fortgeschrittenes Type Narrowing und typbasierte Reachability Analysis
    • Damit liefert es präzises Type-Feedback und reduziert unnötige False Positives
  • Das Ziel ist nicht nur mehr Geschwindigkeit, sondern der Aufbau eines Type-Checkers, der sowohl Genauigkeit als auch User Experience verbessert

Diagnosesystem

  • ty enthält ein fortschrittliches Diagnosesystem, das von den Fehlermeldungssystemen des Rust-Compilers inspiriert ist
    • In einer einzelnen Diagnosemeldung wird der Kontext aus mehreren Dateien gemeinsam dargestellt, sodass Ursache und Lösungsweg eines Problems klarer werden
    • Beispiel: Bei einer falschen Zuweisung eines Dictionary-Schlüssels werden sowohl die Stelle des Type-Mismatchs als auch der Deklarationsort angezeigt
  • Die Diagnoseausgabe ist die zentrale Schnittstelle von ty und wurde so gestaltet, dass sie für Menschen und KI gleichermaßen leicht verständlich ist

Language-Server-Funktionen

  • ty kann in allen Editoren verwendet werden, die LSP (Language Server Protocol) unterstützen, etwa VS Code und Cursor
    • Es unterstützt moderne Language-Server-Funktionen wie Go to Definition, Rename Symbol, Autovervollständigung, Auto-Import, semantisches Syntax-Highlighting und Inlay Hints
  • Die Installation ist über eine VS-Code-Erweiterung möglich; die CLI kann mit dem Befehl uv tool install ty@latest installiert werden

Ausblick

  • Kurzfristige Ziele nach der Beta sind mehr Stabilität und Bugfixes, die Vervollständigung der Python-Type-Spezifikation sowie Unterstützung für Pydantic und Django
  • Langfristig soll ty zur Engine für semantische Funktionen in Astrals Toolchain ausgebaut werden
    • Geplant sind Features wie Entfernung toten Codes, Erkennung ungenutzter Abhängigkeiten, Reachability Analysis für Sicherheitslücken (CVEs) und typbewusstes Linting
  • Astral will ty kontinuierlich verbessern, mit dem Ziel, Python zum produktivsten Programmierökosystem zu machen

Danksagung

  • An der Entwicklung von ty waren Dutzende Open-Source-Mitwirkende beteiligt; das Projekt wird unter der MIT-Lizenz veröffentlicht
  • Mehrere Personen und Teams aus den Communities rund um Salsa, Elixir und Python Typing lieferten technische Zusammenarbeit und Inspiration
  • Das Kernteam von Astral entwickelte ty auf Grundlage eines tiefen Verständnisses von Typentheorie, der Semantik der Python-Runtime und Nutzungsmustern im Ökosystem

Verwandte Beiträge

2 Kommentare

 
iolothebard 2025-12-19

Astral steht wohl eher auf Python oder auf Rust…
Ganz schön astralisch~
 
GN⁺ 2025-12-17
Hacker-News-Kommentare

  • Es wäre gut, wenn Ty zu dieser Vergleichstabelle hinzugefügt würde
    Wenn man sich die Ergebnistabelle zur Python-Typing-Konformität ansieht, sollte man die Leistung von Pyright nicht unterschätzen
    Ich habe Ty (LSP) kurz in Emacs ausprobiert, und es funktioniert ziemlich gut. Etwas störend finde ich nur, dass bei der Anzeige von Methodensignaturen die Typannotationen mancher Parameter zu wortreich wirken
    Trotzdem halte ich es für wahrscheinlich, dass ich langfristig Ty nutzen werde. Glückwunsch zum ersten Beta-Release

    • Spezifikationskonformität ist wichtig, aber ich würde nicht empfehlen, einen Type Checker danach auszuwählen
      Das hat wenig mit dem zu tun, was für reale Nutzer wichtig ist. (Ich habe im Python Typing Council selbst an Spezifikation und Tests mitgearbeitet)
    • Wir werden bald ebenfalls in diese Tabelle aufgenommen. Es wird zwar etwas dauern, bis wir das Conformance-Niveau von Pyright erreichen, aber das ist unser Ziel vor dem offiziellen Release
    • Pyright ist auch großartig, aber BasedPyright ist eine weiter verbesserte Version davon
      Ich bin allerdings ein zufriedener Nutzer von uv und plane zu wechseln, sobald Ty stabil genug ist
    • Dieser PR ist noch WIP, hat mich aber motiviert, wieder mit OSS-Beiträgen anzufangen
    • Pyright ist gut, aber bei der Geschwindigkeit langsam. Da die Reaktionszeit des LSP großen Einfluss auf die UX hat, bin ich gespannt, wie stark Ty das verbessert hat

  • Astral baut hervorragende Tools, daher hoffe ich, dass das Unternehmen ohne disruptive Monetarisierung gut wächst

    • Das erste kommerzielle Produkt von Astral ist pyx. Hoffentlich wird es erfolgreich, damit sie weiter großartige Open-Source-Tools bauen können
    • Ich finde, ihre bisherige Arbeit kommt einem öffentlichen Dienst für die Python-Community gleich
    • Die Richtung wirkt ein bisschen ähnlich wie bei bun
    • Schade ist nur, dass sie behaupten, bestehende Tools vollständig zu ersetzen, in der Praxis aber nicht alle Funktionen implementiert haben
      Am Ende muss man in manchen Fällen doch zu den bestehenden Tools zurückkehren. Für mich ist korrekte Typprüfung wichtiger als Geschwindigkeit

  • Vielen Dank an das Astral-Team. Wir nutzen Pydantic intensiv, deshalb freue ich mich darauf, dass für den offiziellen Ty-Release erstklassige Unterstützung vorgesehen ist
    Aktuell lassen wir Pyright und Mypy gemeinsam laufen, was sich doppelt anfühlt, weil beide unterschiedliche Fehler finden
    Laut dieser Tabelle soll Pyright ein Superset sein, aber meine praktische Erfahrung war anders
    Die Analyse ist zwei Jahre alt, also könnte es inzwischen anders sein. Ich würde gern wissen, ob es Beispiele für die Konsolidierung auf nur Pyright in großen Codebasen gibt

    • Auch ich habe als früher mypy-Nutzer verglichen, als Pyright in VS Code hinzugefügt wurde
      In vielen Fällen hat mypy flexibler und präziser inferiert, und Pyright hatte so viele False Positives, dass ich es zeitweise deaktiviert habe
      Inzwischen hat sich Pyright vermutlich stark verbessert, aber BasedPyright war für mich eher unproduktiv
      In der Community ist die Tendenz stark, mypy abzuwerten und Pyright zu feiern, aber das deckt sich nicht ganz mit meiner Erfahrung
    • Noch einmal: Spezifikationskonformitätstests spiegeln die tatsächliche Nutzererfahrung nicht wider
      Sie konzentrieren sich vor allem auf die Semantik von Annotationen und sind daher ungeeignet als Kriterium zur Auswahl eines Type Checkers
      (Ich habe diese Spezifikation und die Tests ebenfalls im Python Typing Council mitentwickelt)

  • Der Titel „Ankündigung des Ty-Beta-Releases“ wäre passender gewesen
    Ich habe Pyrefly gegenüber Pyright bevorzugt, musste es wegen eines aktuellen Bugs aber auf eine ältere Version festnageln, was lästig war
    Als ich Ty installieren wollte, bekam ich einen Kompatibilitätsfehler mit der Cursor-Version

    • Falls es noch weitere Fehlermeldungen gibt, bitte ein Issue melden. Ich nutze die Ty-Erweiterung in Cursor seit einigen Wochen problemlos, daher kann ich das schwer reproduzieren
    • (Ich bin der Pyrefly-Maintainer.) Es wäre gut, wenn du auch diesen Crash als Issue im Pyrefly-Repository melden könntest

  • Ich verstehe immer noch nicht, warum es für eine einzige Sprache so viele Type Checker gibt
    Müssen Bibliotheksautoren gegen alle Checker testen? Müssen Entwickler nur Bibliotheken verwenden, die einen bestimmten Checker unterstützen?

    • Python ist eine Sprache mit Duck Typing + optionalen Typannotationen, daher sind verschiedene Implementierungen kaum zu vermeiden
    • Ein Teil der Unterschiede entsteht dadurch, dass Reichweite der Call-Site-Inferenz und Richtlinien für explizit erforderliche Typen variieren
      An Paketgrenzen braucht man explizite Typen, im internen Code gibt es jedoch viel Mehrdeutigkeit
      Astral setzt insbesondere die Performance bei inkrementeller Verarbeitung als wichtiges Designziel
    • In der Praxis wird meist nach dem Maßstab von mypy getestet. Pyright baut seinen Einfluss dank der Standard-Erweiterung in VS Code zunehmend aus
      Falls nötig, kann man auch selbst Type Stubs bereitstellen, um Kompatibilität sicherzustellen

  • Mir gefällt, dass Ty die Haltung einnimmt, dass man nicht extra Annotationen hinzufügen muss, nur um einen Type Checker zufriedenzustellen
    Frühere Checker waren mit trivialen Warnungen lästig, aber Ty findet echte logische Fehler gut

  • Ich habe heute zum ersten Mal erfahren, dass Ty auch als Sprachserver (LSP) dient
    Das heißt, es kann in Neovim oder VSCode sowohl mypy als auch Pyright ersetzen

  • Ich frage mich, wie es mit der Django-Unterstützung aussieht. Django hat viel Magic Code, den Type Checker nur schwer behandeln können

    • Ty unterstützt Django noch nicht und hat auch kein Plugin-System
      Wenn du Django nutzt, ist es vorerst besser, bei mypy oder Pyright zu bleiben

  • Selbst wenn Ty nicht schnell wäre, fände ich es allein wegen der Unterstützung für Schnittmengen-Typen (A & B) brauchbar
    Es ist schön, diese im Standard-Typsystem von Python fehlende Funktion zu sehen

  • Ich frage mich, ob es für Ruby etwas wie uv gibt. Für Python oder TypeScript nutze ich uv oder bun, aber Ruby wirkt da etwas zurück

    • Es gibt das neue Ruby-Verwaltungstool Rv. Das könnte eine Alternative dafür sein