Pyrefly – ein neuer Type Checker und ein neues IDE-Erlebnis für Python

• Pyrefly von Meta ist ein in Rust entwickelter Open-Source-Python-Type-Checker sowie eine IDE-Erweiterung
• Er unterstützt ultraschnelle Analyseleistung und IDE-Integration und wurde entwickelt, um die Grenzen von Pyre zu überwinden
• Automatische Typinferenz, Unterstützung für große Codebasen und eine Open-Source-Philosophie gehören zu den Grundprinzipien
• Durch Zusammenarbeit und Beiträge aus der Python-Community soll das Typsystem im gesamten Ökosystem verbessert werden
• Derzeit ist eine Alpha-Version verfügbar, und um Feedback und Beiträge aus der Community wird aktiv gebeten

---

Einführung

• Pyrefly ist ein von Meta in Rust entwickelter Open-Source-statischer Type Checker für Python sowie ein IDE-Erweiterungsprojekt
• Es unterstützt die frühzeitige Erkennung von Fehlern, indem es die Konsistenz von Typen vor der Codeausführung überprüft
• Durch die Integration in die IDE und die Nutzung per CLI bietet es einen flexiblen Workflow
• Ziel ist es, durch die Zusammenarbeit mit der Open-Source-Community zur Weiterentwicklung des Python-Typsystems und verschiedener Bibliotheken beizutragen

Hintergrund der Entwicklung von Pyrefly

• 2017 entwickelte Meta für die umfangreiche Python-Codebasis von Instagram einen neuen Type Checker, aus dem später Pyre wurde
• Pyre orientierte sich an robusten Designs wie Hack und Flow und wurde aus Performance-Gründen in OCaml entwickelt
• Mit der Zeit stiegen die Anforderungen an die Weiterentwicklung des Typsystems und an die IDE-Anbindung, wodurch Grenzen sichtbar wurden
• Auch Community-Tools wie Pyright wurden verwendet, erfüllten jedoch Anforderungen wie die Navigation in großen Codebasen oder den Export von Typen nur eingeschränkt, weshalb die Entwicklung von Pyrefly begonnen wurde

Die wichtigsten Prinzipien von Pyrefly

• 1. Performance

  • Entwickler benötigen direkt nach dem Schreiben von Code bei jedem Tastendruck eine schnelle Typprüfung
  • Pyrefly ist als hochperformante Rust-Implementierung ausgelegt, die selbst extrem große Codebasen mit 1,8 Millionen Zeilen pro Sekunde prüfen kann

• 2. IDE-zentriertes Design

  • Die Abstraktionsarchitektur wurde von Anfang an so entworfen, dass IDE und CLI dieselbe Sicht beibehalten können
  • Bei Pyre wurde dies nachträglich ergänzt, bei Pyrefly wird Konsistenz bereits in der Entwurfsphase betont

• 3. Inferenz

  • Auch in Python-Code ohne Annotationen oder explizit angegebene Typen wird automatische Typinferenz unterstützt
  • Die IDE zeigt Typen von Rückgabewerten und lokalen Variablen an, und für besseres Coding können per Doppelklick inferierte Typen automatisch eingefügt werden

• 4. Open Source

  • Pyrefly wird unter der MIT-Lizenz auf GitHub veröffentlicht, Community-PRs und Issue-Meldungen sind willkommen
  • Es soll eng mit dem Python-Ökosystem und wichtigen Meta-Bibliotheken wie PyTorch verbunden sein und über einen Discord-Kanal einen aktiven Austausch fördern

Die Zukunft von Pyrefly

• Gemeinsam mit der Community arbeitet das Projekt daran, die Python-Sprache und die Developer Experience zu verbessern
• Seit den Anfängen von Pyre wurden Code-Offenlegung und Beiträge zu PEPs gepflegt; auch mit Pyrefly soll der Nutzen von Typen für verschiedene Entwickler, Bibliotheken und Einsteiger maximiert werden
• Auf Grundlage der Erfahrungen und Erfolge beim Einsatz von Typen in dynamischen Sprachen will Meta weitere Erkenntnisse teilen und die Typqualität im Ökosystem verbessern
• Pyrefly befindet sich derzeit zwar noch in der Alpha-Phase, wird aber mit dem Ziel eines offiziellen Launches in diesem Sommer kontinuierlich durch Bugfixes und neue Funktionen weiterentwickelt
• Feedback aus der Community ist sehr wichtig, und nach der Nutzung von Pyrefly wird ausdrücklich um Issue-Reports und Verbesserungsvorschläge gebeten

Hinweise zur Nutzung der Pyrefly-Alpha und zur Community

• Der Entwicklungsprozess von Pyrefly und technische Details wurden im Meta Tech Podcast sowie in Vorträgen auf der PyCon US vorgestellt
• Weitere Informationen werden über verschiedene Kanäle wie die Meta-Open-Source-Websites, YouTube, Facebook, Threads, X und LinkedIn bereitgestellt

[GN⁺]

Hacker-News-Kommentare

• Im Namen von Metas „Python Language Tooling Team“ entwickelt sich bei mir ein leicht mulmiges Gefühl; uv ist so populär, dass ich ahne, dass ty in diesem Bereich gewinnen könnte. Im schlimmsten Fall könnte eine Situation wie bei Atom oder Flow entstehen, in der ein internes Team gegenüber externem Open Source zurückfällt und von oben die Stimmung aufkommt: „Brauchen wir dieses Team wirklich noch? Lasst es zu Open Source wechseln.“ Ich denke, das ist etwas, worauf das Management (Aaron Pollack?) achten sollte.
  • Kevin, nette Begrüßung, mit dem Hinweis, dass er früher an Flow gearbeitet hat und jetzt im Pyrefly-Team aktiv ist. Er erklärt, dass man dieses Mal einen anderen Ansatz gewählt habe als bei Flow und Open Source sowie den Aufbau einer Community ausdrücklich priorisiere. Im Zusammenhang mit den jüngsten Schwankungen bei Infrastrukturinvestitionen in Unternehmen teilt er die Einschätzung, dass man sich derzeit am richtigen Ausgangspunkt für die Reise befinde, und sendet aufmunternde Worte.
  • Die Meinung, dass Meta großen Wert auf die Kontrolle über Open-Source-Projekte legt, insbesondere bei Entwickler-Tools. Früher habe ein Git-Maintainer bei der Nutzung eines Monorepos Probleme angesprochen und Verbesserungen Upstream abgelehnt, woraufhin ein Wechsel zu Mercurial erfolgt sei; auf der Mercurial-Seite habe man Beiträge dagegen gern angenommen. Da sich interne Tools sehr schnell veränderten, sei es vernünftig, eigene Projekte selbst zu besitzen.
  • Von den Dingen, die aus Facebook kamen, gefällt mir JSX am besten (wahrscheinlich das Einzige, das ich wirklich gut finde).
• Vorstellung als jemand, der im Pyrefly-Team bei Meta arbeitet, mit dem Hinweis, dass das FAQ viele Fragen abdeckt, samt Referenzlink. Zusätzlich ein freundliches Angebot, weitere Fragen zu beantworten, und ein Dank für das Interesse.
• Die Beobachtung, dass es inzwischen drei in Rust geschriebene Python-Type-Checker gibt (Microsoft, Facebook, Astral), während das bestehende mypy weiterhin existiert.
  • Korrektur, dass Microsofts Type-Checker Pyright auf TypeScript basiert; dennoch die persönliche Erfahrung, dass er schneller als mypy ist.
  • Die Frage, ob es sich bei allen um statische Type-Checker handelt, mit der Anmerkung, dass es nichts für die Laufzeit gibt.
• Der Hinweis, dass dies zwar die offizielle Ankündigung sei, Pyrefly aber schon vor einigen Wochen diskutiert wurde. Derzeit befinde sich das Projekt in der Alpha-Phase; das Team konzentriere sich auf Bugfixes und Feature-Entwicklung und habe offiziell das Ziel ausgegeben, bis zum Sommer das Alpha-Label loszuwerden.
• Der hier geschriebene Rust-Code sei sehr leicht verständlich, aber zugleich wird Sorge geäußert, dass in letzter Zeit immer mehr Python-Tools in Rust geschrieben werden, verbunden mit der Befürchtung eines weiteren „N-Sprachen-Problems“. Dazu die Hoffnung, dass Mojo hier vielleicht etwas beitragen kann.
  • Erklärung, dass es im Python-Ökosystem ein natürlicher Verlauf sei, Python dort einzusetzen, wo Python ausreicht, und für Bereiche mit hohem Performance-Bedarf Sprachen wie Rust oder C zu verwenden. Am Ende sei also N=3 (Python, Rust, C); allerdings die Hoffnung, dass C langfristig in der Anwendungsprogrammierung langsam verschwinden sollte. Realistisch werde das aber sehr lange dauern, und womöglich werde eher Python selbst zum Legacy-System.
• Die Freude darüber, dass eine Anleitung zur Integration in Vim/Neovim vorhanden ist, samt relevantem Link.
• Die Frage, warum es als großer Vorteil dargestellt wird, dass es in Rust geschrieben ist. Die meisten Menschen ließen Type-Checker schließlich nicht auf Embedded-Systemen oder mission-kritischen Services laufen; es fühle sich ähnlich an wie „in Erlang geschrieben“. Dinge, bei denen Performance nicht entscheidend sei, ließen sich besser in Python schreiben, weil dadurch mehr Beteiligung und Erweiterung aus der Community möglich werde. Daher die Frage, warum diese Fixierung auf Rust besteht.
  • Geteilte Erfahrung mit Rust: Aus Nutzersicht seien Geschwindigkeit und Sicherheit Vorteile, aus Entwicklersicht die leichte Möglichkeit zur Mitarbeit. Gerade das sei auch der Reiz von Astral: Rust-basierte Tools in die Python-Welt zu bringen. Obwohl man Python besser kenne als Rust, empfinde man Beiträge zu Rust-Projekten als einfacher. Die Übertragung der Qualität von Rust-Tools auf Python sei das übergeordnete Ziel.
  • Die Ansicht, dass LSP (Language Server Protocol) sehr performance-kritischer Code sei, weil es sich direkt auf die Reaktionsfähigkeit einer IDE auswirke. Rust sei sowohl bei CPU als auch Speicher sehr effizient. Würde es stattdessen in OCaml, Reason, Haskell usw. geschrieben, wären Geschwindigkeit und Effizienz wohl ebenfalls ausreichend, aber der Pool an Mitwirkenden wäre stark begrenzt.
  • Die Zufriedenheit darüber, dass sich mit der Suche nach „[Toolbeschreibung] rust“ leicht performante Software finden lässt. Etwa 95 % der genutzten Tools seien in Rust geschrieben, und mit den meisten sei man zufrieden.
  • Rust werde wie eine Abkürzung im Sinne von „spürbar schnell“ verwendet, verbunden mit dem Hinweis, dass Open-Source-Rust weiterhin überprüfbar bleibt.
  • Die Erklärung, dass in Python geschriebene Type-Checker zu wenig Performance hätten; etwa ein in Python gebauter Linter wie Pylint, der pro Codezeile einzelne Checks ausführe und deshalb mehr als 30 Sekunden benötige. Daraus folgt die Behauptung, dass es sich sehr wohl um einen performance-kritischen Bereich handelt.
• Neugier auf den Übergang von Pyre zu Pyrefly und auf die vollständige Neuschreibung in Rust, insbesondere auf konkrete Vorteile oder Beweggründe für den Wechsel von einer weniger bekannten Sprache zu dem trendigen Rust.
  • Der Hinweis, dass diese Frage im FAQ behandelt wird, zusammen mit der Aussage, dass man mit mehr Erfahrung dazu vielleicht auch einmal einen längeren Blogpost schreiben möchte, samt Link.
• Die Meinung, dass das Projekt den Eindruck macht, zu viele Dinge auf einmal lösen zu wollen.
• Die Aussage, man habe beim Anblick von VS Code das Interesse verloren und verstehe nicht, warum Leute VS Code für eine geeignete Python-IDE hielten, wo es doch mit PyCharm eine „echte“ IDE gebe und damit keinen Grund für VS Code.
  • Der Hinweis, dass pyrefly nicht nur an vscode gebunden ist, verbunden mit der Bitte, etwas mehr Rücksicht auf unterschiedliche Präferenzen verschiedener Menschen zu nehmen. pycharm sei ebenfalls nicht absolut besser. Man selbst finde die Remote-Entwicklung in vscode praktisch und würde umgekehrt auch nicht ins Internet schreiben wollen, dass pycharm schlecht sei.