Beachten Sie, dass PyPy nicht aktiv weiterentwickelt wird

• In das uv-Repo wurde eine Änderung gemergt, die in der Dokumentation ausdrücklich darauf hinweist, dass PyPy nicht aktiv weiterentwickelt wird
• Der Vorschlagsersteller verwies auf ein Issue im numpy-Projekt als Beleg dafür, dass PyPy schrittweise ausgegrenzt wird
• In der Dokumentation wurde der Warnhinweis ergänzt: „PyPy wird nicht mehr aktiv weiterentwickelt und unterstützt nur noch Python 3.11“
• Danach widersprachen in der Community PyPy-Entwickler mit dem Hinweis, dass „die Wartung fortgesetzt wird, es aber wegen Personalmangels schwierig ist, den CPython-Versionen zu folgen“
• Das Projekt passte die Formulierung später von „unmaintained“ zu „not actively developed“ an, um die Lage genauer widerzuspiegeln

---

Überblick über den Pull Request

• konstin erstellte einen PR, um in der Dokumentation des uv-Projekts einen Warnhinweis zu PyPy hinzuzufügen
  • Als Grund wurde genannt, dass „PyPy nicht mehr aktiv weiterentwickelt wird und auch bei numpy schrittweise ausgeschlossen wird“
  • Es gebe zwar keine offizielle Erklärung, aber das zugehörige numpy-Issue sei laut Beschreibung von einem PyPy-Entwickler eingebracht worden
• In der Dokumentation (docs/concepts/python-versions.md) wurde folgender Inhalt ergänzt
  • „PyPy wird nicht mehr aktiv weiterentwickelt und unterstützt nur noch Python 3.11“
• Der PR bestand aus vier Commits und wurde am 22. Januar 2026 in den main-Branch gemergt

Diskussion in der Community

• Einige Mitwirkende wiesen darauf hin, dass der Warnhinweis doppelt erscheine; später wurde er so angepasst, dass er nur noch einmal angezeigt wird
• Nach dem Merge reagierten die PyPy-Community und externe Entwickler in GitHub-Kommentaren
  • stuaxo zitierte Aussagen von PyPy-Entwicklern und argumentierte, dass „PyPy weiter gewartet wird und gegenüber CPython lediglich langsamer ist“
  • Foxboron fragte: „Wurde vor dem Merge Kontakt zu den PyPy-Maintainern aufgenommen?“
  • vitorsr zitierte die Aussage des PyPy-Kernentwicklers mattip, man brauche „Mitwirkende oder finanzielle Unterstützung“
• HaoZeke bezeichnete den Merge ohne vorherige Diskussion als unangemessen und forderte die Rücknahme des PR

Reaktion des Projekts

• charliermarsh erklärte, der PR-Titel sei von „unmaintained“ auf „not actively developed“ geändert worden
• zanieb erläuterte, dass ein PyPy-Kernentwickler im numpy-Issue selbst gesagt habe, PyPy werde „nicht aktiv weiterentwickelt“; eine böswillige Absicht habe es nicht gegeben
• mattip (PyPy-Kernentwickler) sagte, die aktuelle Formulierung bilde die Situation fair ab, und stimmte der Beibehaltung des Wortlauts zu
  • Er merkte jedoch an, dass der PR zurückgenommen werden könnte, falls PyPy auf Python 3.11.15 aktualisiert wird

Auswirkungen nach dem Merge

• Die Änderung wurde in die Veröffentlichung von uv 0.9.27 aufgenommen und als Dokumentations-Update ausgeliefert
• Homebrew und verschiedene Automatisierungs-Bots verweisen auf den betreffenden PR, wodurch der PyPy-Warnhinweis in die offizielle Dokumentation aufgenommen wurde

[GN⁺]

Hacker-News-Kommentare

• Ich bin PyPy-Core-Entwickler. Wer helfen möchte, sei es finanziell oder mit Code-Beiträgen, kann sich gern die Kontaktmöglichkeiten ansehen
  • Es wäre gut, wenn auf der Website ein Spendenbereich gut sichtbar wäre. Auch gestaffelte Sponsoring-Stufen wie beim Ladybird-Browser wären vielleicht sinnvoll. Ich wollte selbst einen kleinen Betrag spenden, aber es war schwer herauszufinden, wo das geht
  • Habe gerade gespendet. Vielen Dank an das gesamte PyPy-Team. Ich nutze PyPy oft in meiner App, und bei rechenintensiven Aufgaben ist es normalerweise mehr als 5-mal schneller als CPython. Was in CPython 5 Minuten dauert, ist in PyPy in wenigen Sekunden erledigt
  • Ich hätte noch einen weiteren Vorschlag. Ich weiß, dass PyPy bei CPU-bound-Workloads schnell ist, aber es könnte vielleicht auch bei I/O-bound-Workloads bessere Leistung zeigen. Es wäre gut, eine Benchmark-Seite zu haben, die etwa den HTTP-Request-Durchsatz mit asyncio und CPython vergleicht. Auch ein automatisiertes Tool, mit dem man die PyPy-Performance direkt im Web messen kann, wäre interessant
  • Auf der Website steht groß, dass es nicht mehr aktiv gepflegt werde
• PyPy ist kein eingestelltes Projekt. Bugfixes und JIT-Verbesserungen gehen weiter. Die verbliebenen Kernentwickler schaffen es nur nicht, mit dem schnellen Wandel von CPython Schritt zu halten. Für die Unterstützung neuer Versionen braucht es neue Mitwirkende. Immerhin wird an Version 3.12 bereits von einem neuen Contributor gearbeitet
  • CPython ist inzwischen fast zu einem kommerzialisierten Projekt geworden. Einige Entwickler schließen andere aus, und Projekte mit Unternehmensfinanzierung verschwinden oft nach fünf Jahren wieder. Die klugen Leute sind alle weg. unicodeobject.c zum 150. Mal umzuschreiben ist ja noch das eine, aber beim Rest kommt man kaum noch hinterher
  • Die in die Dokumentation übernommene Formulierung ist knapper als der PR-Titel — dort steht: „nicht mehr aktiv entwickelt“
• PyPy ist wirklich eine erstaunliche Leistung. Während Microsofts Faster-CPython-Team in vier Jahren nur auf den Faktor 1,5 gekommen ist, ist PyPy seit Jahrzehnten mehr als 5-mal schneller. Allerdings scheint das Hauptziel von PyPy eher bei Forschungsprojekten zu liegen (Meta-Tracing, STM usw.), und das CPython-Team interessiert sich kaum für andere Implementierungen, weshalb PyPy weniger Aufmerksamkeit bekommt
  • Der Erfolg des Python-Ökosystems beruht auf C-Erweiterungsbibliotheken wie SciPy, pandas und TensorFlow. CPython bot eine C-API, mit der solche Bibliotheken leicht beschleunigt werden konnten. PyPys CFFI war für große Projekte nicht attraktiv genug, und HPy kam zu spät, als PyPys Momentum bereits verschwunden war
  • Das Faster-Python-Projekt hätte sich vielleicht weiterentwickeln können, wurde aber gestoppt, als Microsoft letztes Jahr wegen des AI-Booms große Teile seiner Sprach-Teams entlassen hat
  • Wir nutzen PyPy seit über 10 Jahren in Produktion in zentralen Systemkomponenten
  • In Benchmarks ist PyPy hervorragend, aber in echter Entwicklung im großen Maßstab gibt es zu viele Kompatibilitätsprobleme. Die meisten Leute sind bei Performance-Tests beeindruckt, scheitern aber mit realen Apps. Der GC ist lazy, sodass Ressourcen wie File Descriptors nicht rechtzeitig freigegeben werden und es leicht zu Ressourcenerschöpfung kommt. Das Problem ist, dass solche wichtigen Unterschiede nicht dokumentiert sind
• Für alle, die bei den Namen durcheinanderkommen: PyPI ist der Python Package Index und PyPy ist eine „schnelle und kompatible alternative Python-Implementierung“. Die aktuelle 3.12-Version verzögert sich allerdings wegen Entwicklermangels (zugehörige Diskussion)
  • Danke für die Erklärung. Vor allem im uv-Repository-Issue wurden PyPi und PyPy durcheinandergeworfen, was verwirrend war
  • Das erinnert an die Beziehung zwischen Cython und CPython
  • mypy ist ein „statischer Type-Checker für Python“. Auch PyPys RPython arbeitet mit statischen Typen, deshalb habe ich die beiden früher oft verwechselt. Vor Kurzem habe ich auch mypyc entdeckt, und jetzt fühlt es sich an, als wäre die gedankliche Verbindung komplett
  • Das Naming ist wirklich furchtbar
• Interessant, dass aus „als Freiwilligenprojekt nicht mehr aktiv entwickelt“ dann „eingestellt“ geworden ist
  • Zur Einordnung: PyPy hatte seit letztem Oktober jeden Monat 2 bis 4 Commits, und das letzte Release war im Juli 2025 (Commit-Historie, Tag-Liste)
  • Ich habe Respekt vor den PyPy-Contributors, aber die Einschätzung „eingestellt“ wirkt als Beschreibung ziemlich fair
• Es wäre wirklich schade, wenn PyPy verschwinden würde. Ich hoffe, dass seine nützlichen Forschungsergebnisse im Lauf der Zeit nach CPython übernommen wurden
  • Die in reinem Python geschriebene REPL, die in PyPy begann, wurde in CPython weiter verfeinert, und auch die Lehren aus HPy fließen langsam in CPython ein. Außerdem hat PyPy viele subtile Bugs in der CPython-Standardbibliothek ans Licht gebracht und damit zu deren Behebung beigetragen
  • Der Ansatz ist aber völlig anders, deshalb wurden die meisten Techniken wohl nicht direkt nach CPython portiert
• Ich habe zuerst PyPi gelesen und dachte einen Moment lang, mir bleibt das Herz stehen
• Vielleicht wäre es inzwischen besser, Zeit und Geld in RustPython zu investieren (offizielle Website, GitHub)
  • Aber RustPython ist langsamer als CPython, daher frage ich mich, warum man es überhaupt nutzen sollte
• Entwicklung wird am Ende eben doch von Geld angetrieben. Warum gibt es noch kein System, mit dem man an alle Entwickler entlang eines Dependency-Trees spenden kann? Wenn sich solche Probleme aufstauen, wird Wartung am Ende wohl immer schwieriger
• Vielen Dank an das PyPy-Team für all die Arbeit. Ich werde auch nach einer Möglichkeit suchen zu helfen