PyPy 8.0 bringt Python-3.12-Unterstützung – die eigentliche Bewährungsprobe liegt aber im Erweiterungs-Ökosystem

PyPy 8.0 ist aus einem Grund bemerkenswert, der sich leicht hinter der Versionsnummer versteckt. Das Projekt veröffentlicht nicht bloß einen weiteren schnelleren Python-Interpreter. Es versucht, einen der dauerhaften Nachteile von PyPy zu verringern: die Lücke zwischen einer kompatiblen Python-Laufzeit und der sehr viel größeren Welt von Paketen, die auf CPythons C-API angewiesen sind.

Die am 19. September 2026 veröffentlichte Version bringt einen Python-3.12-Interpreter in Beta-Qualität, liefert weiterhin Varianten für Python 3.11 und Python 2.7 aus und hebt die Linux-Basis auf glibc 2.28 an. Noch wichtiger ist die Aussage des PyPy-Teams, dass das neue Python-3.12-Objektmodell nun die nötigen Bausteine enthält, um cp312-abi3-Wheels zu verwenden, die für CPythons Limited API gebaut wurden. Die verbleibende Arbeit liegt nicht allein in PyPy: Importmechanismus, Installer und Build-Systeme für Pakete müssen sich ebenfalls darauf verständigen, dass diese Wheels gültige Kandidaten sind.

Damit ist PyPy 8.0 eine interessante Version für Experimente und gezielte Tests in der Produktion. Eine allgemeine Aufforderung, CPython zu ersetzen, ist sie nicht. Die praktischere Frage lautet: Läuft der Abhängigkeitsbestand deiner Anwendung unter PyPy 8.0, ohne auf Quellcode-Builds, nicht unterstützte native Erweiterungen oder Laufzeitannahmen zurückzufallen, die nur unter CPython gelten?

Was sich in PyPy 8.0 geändert hat

PyPy beschreibt Version 8.0.0 als Hauptversion mit drei Interpreter-Linien: PyPy2.7, PyPy3.11 und PyPy3.12. Die Python-3.12-Implementierung ist ausdrücklich als Beta gekennzeichnet. Nutzer sollten sie daher als Plattform für Kompatibilitätstests behandeln und nicht automatisch als Ersatz für eine ausgereifte CPython-Installation. Die Python-3.11-Linie bleibt verfügbar; sofern keine Sicherheitsprobleme auftreten, soll dies nach Angaben des Projekts jedoch die letzte Version mit Python-3.11-Unterstützung sein.

Die offizielle Release-Notiz nennt zwei infrastrukturelle Gründe für den Wechsel der Hauptversionsnummer. Erstens verwenden die Linux-Buildbots nun manylinux-2.28-Images auf Basis von AlmaLinux 8 und glibc 2.28. Dabei ersetzt GCC 14 die ältere GCC-5-Toolchain. Die daraus entstehenden kompilierten Tarballs benötigen glibc 2.28 oder neuer. Für viele aktuelle Distributionen ist das eine vernünftige Basis, aber weiterhin eine Einschränkung beim Deployment: ältere Enterprise-Images, Altgeräte und sorgfältig eingefrorene Container-Basen müssen geprüft werden, statt ihre Kompatibilität vorauszusetzen.

Zweitens hat PyPy die Darstellung seiner internen Objektstruktur gegenüber C-Erweiterungen verändert. Frühere Versionen stellten eine PyPy-spezifische Erweiterung der PyObject-Struktur so bereit, dass sie sich vom Layout in CPython unterschied. In Version 8.0 wird dieses PyPy-spezifische Feld in einem Präfix vor dem an C-Erweiterungsmodule übergebenen Zeiger verborgen. Das erklärte Ziel ist, PyPy die Nutzung von cp312-abi3-Wheels zu ermöglichen, die für CPython 3.12 und spätere Versionen erstellt wurden – vorausgesetzt, diese Wheels bleiben tatsächlich innerhalb der Limited API.

Auch die RPython-Codegenerierung wurde aktualisiert. PyPy verwendet nun berechnete Sprünge und aggressiveres Inlining im erzeugten Interpreter-Code. Das Team räumt offen ein, dass der Geschwindigkeitsgewinn geringer ausgefallen ist als erhofft. Dieses Detail ist wichtig: Der Wert dieser Version lässt sich nicht auf eine Benchmark-Schlagzeile reduzieren. Die folgenreichere Arbeit betrifft Paketierung, Kompatibilität und den Wartungsaufwand für einen weiteren Interpreter.

PyPy hat außerdem sein internes HPy-Backend entfernt. Laut Release-Notiz war der handle-basierte Ansatz des HPy-Projekts ein nützlicher Prototyp, erhielt aber nicht genügend Unterstützung, um zu einem neuen Standard zu werden. Der HPy-Code bleibt im PyPy-Quellbaum und kann über eine Build-Option aktiviert werden; er gehört jedoch nicht mehr zur Standardrichtung des Projekts. Für Autoren von Erweiterungen bedeutet das, dass der unmittelbare Kompatibilitätsweg weiterhin über die bestehende C-API-Grenze, CFFI oder interpreterspezifische Build-Logik führt – nicht über einen umfassenden HPy-Wechsel, der die bisherigen Abwägungen beseitigt.

Warum cp312-abi3 wichtig ist

Python-Pakete werden nicht alle auf dieselbe Weise verteilt. Ein reines Python-Paket kann oft ein py3-none-any-Wheel verwenden und unter CPython, PyPy oder einer anderen Python-3-Implementierung laufen. Bei einem Paket mit kompiliertem C-, C++- oder Rust-Code sieht es anders aus. Sein Wheel kann an einen bestimmten Interpreter, eine ABI, ein Betriebssystem und eine Prozessorarchitektur gebunden sein. Der Dateiname kodiert diese Kompatibilitätsaussagen.

Der Python Packaging User Guide beschreibt abi3 als Tag für Erweiterungen, die gegen CPythons stabile ABI gebaut wurden. Die Stable ABI ist eine eingeschränkte Teilmenge der C-API, die über mehrere Python-3-Versionen hinweg nutzbar bleiben soll. Im typischen Fall kann ein Paket für jede Kombination aus Betriebssystem und Architektur ein cp39-abi3-Wheel verteilen, statt für jede CPython-Minor-Version eine eigene Erweiterung zu bauen.

Dieser Vorteil erstreckt sich nicht automatisch auf PyPy. Ein mit cp312-abi3 gekennzeichnetes Wheel macht eine Aussage über CPythons Stable ABI. PyPy muss eine kompatible Implementierung der relevanten Schnittstelle bereitstellen, und die Paketierungswerkzeuge müssen das Wheel bei der Auflösung von Abhängigkeiten berücksichtigen. Die PyPy-Version 8.0 erklärt, dass C-Header und exportierte Funktionen nun an die CPython Limited API für Python 3.12 angeglichen sind. Gleichzeitig nennt das Projekt zwei wichtige noch fehlende Teile: Der Importmechanismus muss gemeinsam genutzte abi3.so-Objekte als für PyPy gültig akzeptieren, und Werkzeuge wie pip und uv müssen diese Wheels als Kandidaten erkennen.

Genau darin liegt der Kern dieser Version. Eine Änderung auf Laufzeitebene kann technisch korrekt sein und den Nutzern dennoch wenig bringen, wenn Paketindex, Installer, Build-Backend und Erweiterungsprojekt dieselbe Interpretation noch nicht übernommen haben. Die Kompatibilitätskette sieht ungefähr so aus:

PyPy-C-Header und Loader
        ↓
Erweiterungsprojekt baut innerhalb der Limited API
        ↓
Wheel-Metadaten deklarieren eine kompatible ABI
        ↓
Installer berücksichtigt das Wheel für PyPy
        ↓
Anwendung besteht Laufzeit- und Verhaltenstests

Ein Bruch an irgendeiner Stelle schickt den Nutzer zurück zu einem Quellcode-Build, einem PyPy-spezifischen Wheel, einem reinen Python-Fallback oder einer inkompatiblen Binärdatei. PyPy 8.0 bringt den ersten Teil dieser Kette voran. Die übrigen Teile müssen weiterhin geprüft werden.

Der Kompatibilitätsvorbehalt bleibt erheblich

Der größte Fehler wäre, aus der Aussage Unterstützung für CPython-3.12-abi3-Wheels die Aussage Unterstützung für alle verbreiteten Python-Pakete zu machen. Viele Pakete verwenden die Limited API nicht. Sie greifen möglicherweise auf CPython-Implementierungsdetails zu, verlassen sich auf Referenzzählungsverhalten, setzen ein bestimmtes Objektlayout voraus oder liefern generierten Code aus, der ausschließlich gegen CPython getestet wurde. Ein Wheel kann mit einem scheinbar portablen Tag versehen sein, während der enthaltene Code weiterhin Annahmen macht, die PyPy nicht exakt nachbilden kann.

PyPy stellt seit Langem eine Kompatibilitätsschicht namens cpyext bereit, die große Teile von CPythons C-API emuliert. Dadurch wird eine umfangreiche Menge an Erweiterungscode möglich, aber Emulation hat ihren Preis. PyPy verwendet einen Tracing-Garbage-Collector und nicht CPythons Implementierung mit Referenzzählung. Referenzzähler, die über die Kompatibilitätsschicht beobachtet werden, repräsentieren nicht zwangsläufig denselben Zustand, den eine C-Erweiterung unter CPython sehen würde. Code, der Referenzzähler als Signal für Lebensdauer verwendet, heikle Freigabelogik ausführt oder auf CPython-spezifische interne Objekte zugreift, verdient besondere Aufmerksamkeit.

Die Cython-Dokumentation weist auf einen verwandten Punkt hin: Cython kann erzeugten Code für PyPy anpassen, doch bei der emulierten C-API bleiben sichtbare Unterschiede. Autoren von Erweiterungen sollten sich nach Möglichkeit auf die von Cython erzeugte Behandlung verlassen, statt ohne klaren Grund direkt auf Verhalten der Low-Level-C-API zu setzen. Das ist kein spezieller Vorwurf gegen PyPy. Es erinnert daran, dass eine stabile Sprachoberfläche und eine stabile Oberfläche für native Erweiterungen zwei unterschiedliche technische Probleme sind.

CFFI bleibt eine wichtige Alternative für Projekte, die mehrere Python-Implementierungen unterstützen müssen. Das PyPy-Team bittet Bibliotheksmaintainer ausdrücklich, bei C-Erweiterungen eine CFFI-Variante in Betracht zu ziehen, die unter PyPy gute Leistung erbringt. CFFI macht nicht jede native Abhängigkeit automatisch portabel, kann aber einige Annahmen vermeiden, die eine CPython-Erweiterung unter einem anderen Interpreter schwierig machen.

Auch Autoren von Rust-Erweiterungen stehen vor einer ähnlichen Entscheidung. PyO3 unterstützt Builds für PyPy und bietet Konfigurationen zur Erkennung der PyPy-Implementierung. Dokumentation und Quellcode-Kommentare behandeln die Stable ABI jedoch weiterhin als CPython-orientierten Weg. Ein Rust-Projekt, das CPython und PyPy unterstützen möchte, sollte diese Ziele daher ausdrücklich bauen und testen. Es sollte PyPy-Kompatibilität nicht allein daraus ableiten, dass der CPython-Build abi3 verwendet.

Wer PyPy 8.0 jetzt ausprobieren sollte

Am besten geeignet sind Anwendungen mit langen Python-Schleifen, erheblicher Berechnung in reinem Python oder Diensten, die nach einer Aufwärmphase vom Tracing-JIT in PyPy profitieren können. Der mögliche Gewinn ist plausibler, wenn die Anwendung viel Zeit im Python-Code verbringt und weniger Zeit in nativen Bibliotheken wartet, die ihre eigentliche Arbeit ohnehin außerhalb des Interpreters erledigen.

Auch für Maintainer reiner Python-Bibliotheken ist PyPy eine sinnvolle Testplattform. Wenn ein Paket eine breite Kompatibilität mit Python-Implementierungen verspricht, kann PyPy 8.0 im CI Annahmen sichtbar machen, die bei CPython-Tests verborgen bleiben. Das gilt besonders für Bibliotheken, die indirekt mit Objektlebenszeiten umgehen, stark auf dynamischen Dispatch setzen oder alternative Interpreter ausdrücklich unterstützen wollen.

Die Version ist außerdem für Maintainer von Erweiterungen relevant. Ein Projekt, das bereits Cython, CFFI oder PyO3 verwendet, kann mit PyPy 8.0 prüfen, ob seine Abstraktionsgrenze tatsächlich portabel ist. Die neue Arbeit an cp312-abi3 bietet ein konkretes Ziel für die Zusammenarbeit zwischen PyPy, Erweiterungsautoren und Paketierungswerkzeugen. Aus der allgemeinen Bitte, PyPy besser zu unterstützen, wird eine prüfbare Reihe von Fragen: Kompiliert die Erweiterung? Lässt sich das Wheel installieren? Importiert es? Verhält es sich unter Garbage Collection und JIT-Ausführung korrekt?

Teams, die Python-Dienste betreiben, sollten selektiver vorgehen. Ein Dienst mit überschaubarem Abhängigkeitsbaum, starken Integrationstests und einer überwiegend in Python ausgeführten Arbeitslast ist ein plausibler Pilot. Ein Data-Science-Stack mit mehreren großen Binärabhängigkeiten, nativen Datenbanktreibern, eigenen Cython-Modulen und herstellerspezifischen Wheels ist als erstes Ziel deutlich riskanter. Auch dieser Stack kann später funktionieren, aber der erwartete Nutzen muss die Pflege eines weiteren Interpreterpfads rechtfertigen.

Der wenig überzeugende Grund für einen Versuch mit PyPy 8.0 ist die größere Versionsnummer gegenüber der CPython-Version. PyPys Nummerierung ist die eigene Veröffentlichungsfolge des Projekts; sie bedeutet nicht, dass die Laufzeit Python 8 implementiert. Die relevanten Sprachversionen dieser Veröffentlichung sind Python 3.12 als Beta sowie Python 3.11 und Python 2.7.

Ein praktischer Evaluationsplan

Ein sinnvoller Test beginnt mit einer Bestandsaufnahme, nicht mit einem Benchmark. Erfasse das vollständige Lockfile und ordne jede Abhängigkeit einer Kategorie zu: reines Python, C-Erweiterung, Rust-Erweiterung, externe gemeinsam genutzte Bibliothek oder Paket mit einem bekannten interpreterspezifischen Pfad. Das Ergebnis zeigt, wo die eigentliche Arbeit liegt. Eine Liste der direkten Anforderungen reicht nicht, denn das problematische Paket kann mehrere Ebenen tiefer im Abhängigkeitsgraphen liegen.

Richte danach eine getrennte Umgebung für PyPy 8.0 ein und installiere mit dem normalen Resolver des Projekts. Installiere nicht vorab eine Sammlung von CPython-Wheels und nimm dann an, die Umgebung sei repräsentativ. Halte fest, welche Pakete aus Wheels installiert werden, welche aus dem Quellcode gebaut werden und welche abgelehnt werden. Eine erfolgreiche Installation ist ein hilfreicher Hinweis, aber noch kein Kompatibilitätsurteil.

Die Testsuite sollte anschließend mindestens in vier Modi laufen: sauberer Start, kurzer Funktionstest, lang laufende Arbeitslast sowie Neustart- oder Upgrade-Pfad. Der Langzeittest ist wichtig, weil PyPys JIT Zeit zum Aufwärmen braucht und weil sich das Verhalten der Garbage Collection in einem kleinen Unit-Test-Lauf möglicherweise nicht zeigt. Miss Startzeit, Durchsatz im eingeschwungenen Zustand, Speicherwachstum, Tail-Latenz und den Zeitpunkt, ab dem der Dienst tatsächlich nutzbar ist. Eine schnellere innere Schleife macht ein Deployment nicht automatisch besser, wenn Start- oder Speicherkosten die Arbeitslast dominieren.

Native Grenzen verdienen eigene Tests. Prüfe Serialisierung, Datenbanktreiber, Bild- oder Audioverarbeitung, Kryptografie, Kompression, numerische Kerne und jeden Code, der Python-Objekte durch C oder Rust reicht. Führe Tests aus, die Allokation und Sammlung erzwingen, statt nur erfolgreiche Standardaufrufe zu prüfen. Verwendet die Anwendung Callbacks, Finalizer, Buffer-Protokolle oder Thread-Koordination, müssen diese Pfade ausdrücklich enthalten sein. Hier werden Unterschiede zwischen Interpretern besonders häufig zu Betriebsproblemen statt zu bloßen Installationswarnungen.

Behalte CPython als Vergleichsbasis. Ziel ist nicht der Nachweis, dass PyPy jeden Benchmark gewinnt. Verglichen werden sollte das gesamte Ergebnis der technischen Arbeit: Build-Zuverlässigkeit, Verhalten beim Kaltstart, Speicher, Durchsatz, Beobachtbarkeit, Debugging, Verfügbarkeit von Wheels und die Zeit, die zwei gesunde Interpreterpfade dauerhaft benötigen. Bei einer Batch-Arbeitslast, die stundenlang läuft, kann eine Aufwärmkosten kaum ins Gewicht fallen. Bei einem Kommandozeilenprogramm, das hunderte Male pro Minute gestartet wird, kann derselbe Kostenpunkt den Vorteil aufzehren.

Linux-Nutzer sollten die glibc-Grenze prüfen

Der Wechsel auf glibc 2.28 ist leicht zu übersehen, weil er als Build-Infrastruktur beschrieben wird. Er gehört jedoch auch zum Vertrag für die Verteilung der Laufzeit. Die PyPy-Downloadseite erklärt, dass die aktuellen Linux-Binärdateien mit manylinux 2.28 und späteren Varianten kompatibel sind und glibc 2.28 oder neuer benötigen. Nutzer aktueller Ubuntu-, Debian-, Fedora- und vergleichbarer Systeme werden darin wahrscheinlich keine Überraschung sehen. Wer ältere Distributionen oder minimale Images unterstützt, sollte die Voraussetzung direkt prüfen.

Ein Container-Build ist der einfachste Ort, um das Problem zu finden. Teste exakt das Basis-Image aus der Produktion und nicht ein neueres Image vom Entwicklerrechner. Prüfe die Anforderungen der gemeinsam genutzten Bibliotheken des Interpreters und führe die Smoke-Tests der Anwendung in diesem Image aus. Wenn das Deployment auf einer Mischung von Maschinen läuft, muss der älteste unterstützte Knoten getestet werden. Eine PyPy-Binärdatei, die auf dem Build-Host startet, aber nicht auf dem ältesten Produktionshost, ist kein gelungenes Upgrade.

Das Projekt weist außerdem darauf hin, dass seine Linux-Binärdateien OpenSSL enthalten, aber keinen Zertifikatsspeicher. Die Download-Dokumentation empfiehlt, den Zertifikatsspeicher der Plattform zu verwenden oder SSL_CERT_FILE zu konfigurieren, etwa über das Paket certifi. Das ist nicht ausschließlich ein PyPy-Thema, aber genau die Art von Betriebsdetail, die verloren gehen kann, wenn ein Interpreter als selbstständiges Archiv heruntergeladen wird. HTTPS-Tests sollten Teil der ersten Validierung sein, besonders bei Werkzeugen, die Paketindizes, APIs oder interne Dienste kontaktieren.

Herunterladen, prüfen und isoliert experimentieren

PyPy stellt vorkompilierte Archive für mehrere Plattformen bereit, darunter Linux x86-64, Linux ARM64, Windows 64 Bit sowie macOS auf Apple-Silicon- und Intel-Hardware. Das Projekt veröffentlicht Prüfsummen für die Archive von Version 8.0.0. Behandle diese Prüfsummen als Teil der Installation: Lade aus den offiziellen Projektseiten herunter, prüfe das Archiv und notiere den genauen Interpreter-Build in den Unterlagen des Experiments.

Ersetze während der Evaluierung nicht den systemweiten Befehl python. Verwende eine eigene virtuelle Umgebung oder einen expliziten Interpreterpfad, lasse die bestehende CPython-Umgebung intakt und mache die Auswahl im CI sichtbar. Ein kleiner Wrapper oder ein Matrix-Eintrag lässt sich leichter entfernen als eine systemweite Interpreteränderung, die unbemerkt Skripte, Build-Jobs oder Service-Units verändert.

Das Projekt erklärt, dass ein Build von PyPy aus dem Quellcode zeitaufwendig ist und erhebliche Rechenressourcen benötigt. Die meisten Nutzer sollten deshalb mit den offiziellen Binärdateien beginnen. Quellcode-Builds sind für Distributionspaketierer, PyPy-Contributors oder Teams mit einer kontrollierten Toolchain sinnvoll. Für eine normale Anwendungsevaluierung sind sie nicht der kürzeste Weg.

Was die Version für Paketierungswerkzeuge bedeutet

PyPy 8.0 macht ein Koordinationsproblem sichtbar, das das Python-Ökosystem über Jahre vor sich hergeschoben hat. Unterstützung für einen Interpreter wird oft so behandelt, als sei sie eine Eigenschaft der Laufzeit allein. Tatsächlich ist die Auswahl eines Wheels das Ergebnis einer Abstimmung zwischen Paketmetadaten, Installer-Tags, Build-Backends, Richtlinien des Index und der Implementierung, die die Binärdatei am Ende lädt. Die Formulierung des PyPy-Teams macht klar, dass im Importmechanismus und in Werkzeugen wie pip und uv noch Arbeit aussteht.

Das gibt Paketmaintainern eine konkrete Möglichkeit, beizutragen. Ein Maintainer kann die Erweiterung des Projekts gegen PyPy 3.12 testen, prüfen, ob sie wirklich nur die Limited API verwendet, einen PyPy-CI-Job ergänzen, bei passender Grundlage ein kompatibles Wheel veröffentlichen und Fehler mit einem minimalen Reproduktionsbeispiel melden. Wer lediglich schreibt, PyPy sei kaputt, liefert wenig verwertbare Information. Ein Bericht wie das cp312-abi3-Wheel lässt sich installieren, scheitert aber beim Freigeben eines Buffers nach der Sammlung gibt dem Ökosystem einen Ansatzpunkt.

Das ist auch eine Aufforderung zu präzisen Paketmetadaten. Eine reine Python-Distribution sollte den weitesten zutreffenden Tag verwenden. Eine kompilierte Erweiterung sollte nur die ABI und Plattformen deklarieren, die tatsächlich getestet wurden. Ein Projekt, das zwar mit einer Stable ABI baut, aber weiterhin private CPython-Symbole importiert, hat die Portabilität seines Dateinamens nicht erreicht. Die Arbeit rund um PyPy 8.0 wird nur dann dauerhaft nützlich, wenn Paketangaben genauer werden und nicht lediglich optimistischer.

Alternativen und Ergänzungen

CPython bleibt die Standardwahl für die breiteste Paketkompatibilität, das berechenbarste Verhalten nativer Erweiterungen und die größte Auswahl herstellerunterstützter Wheels. Für viele Anwendungen ist das die richtige Entscheidung. PyPy zu wählen ist keine moralische Aussage über Vielfalt bei Python-Implementierungen, sondern eine Entscheidung über Arbeitslast und Wartung.

Wenn das Ziel darin besteht, Reibung bei Abhängigkeiten zu reduzieren und zugleich eine vertraute Laufzeit zu behalten, kann eine Verbesserung der C-Grenze des Pakets sinnvoller sein als ein Interpreterwechsel. CFFI, eine klar definierte Limited API, generierte Bindings und weniger implementierungsspezifische Annahmen können die Portabilität zwischen CPython, PyPy und künftigen Laufzeiten verbessern. Bei Rust-Erweiterungen sind explizite PyPy-Builds und bedingte Kompilierung möglicherweise zuverlässiger, als zu erwarten, dass ein CPython-orientiertes Artefakt überall funktioniert.

Wenn das Ziel maximale Geschwindigkeit ist, muss die tatsächliche Anwendung gegen die verfügbaren Optionen getestet werden. PyPys JIT kann bei langen, Python-lastigen Arbeitslasten helfen, aber native Bibliotheken, I/O, Serialisierung, Startzeit und Speicher können dominieren. Eine sorgfältig optimierte CPython-Installation, ein anderer Algorithmus, eine kompilierte Erweiterung oder eine Änderung der Prozessarchitektur kann mehr bringen. Entscheidend ist der Vergleich des gesamten Programms und nicht einer synthetischen Schleife.

Das Fazit

PyPy 8.0 ist eine wichtige Open-Source-Veröffentlichung, weil sie eine reale Einstiegshürde angeht. Die Python-3.12-Beta-Unterstützung bringt das Projekt näher an das aktuelle Sprachökosystem. Die Umstellung auf glibc 2.28 gibt den Linux-Binärdateien eine moderne Distributionsbasis. Das neue Objektmodell und die geplante Unterstützung für cp312-abi3 könnten die Zahl der Pakete verringern, die eigene PyPy-Builds benötigen.

Der Vorbehalt ist genauso wichtig: Kompatibilität ist erst vollständig, wenn Installer die Wheels auswählen, der Loader sie akzeptiert und Anwendungen reale Arbeitslasten überstehen. Die bekannten Probleme rund um CPython-spezifische C-Erweiterungen, Annahmen über Referenzzählung, Binärabhängigkeiten und lückenhafte Testabdeckung bleiben bestehen. PyPy 8.0 verbessert die Ausgangslage; es lässt den Abhängigkeitsgraphen nicht verschwinden.

Für Entwickler lautet die praktische Empfehlung, PyPy 8.0 zunächst mit einer begrenzten Arbeitslast, einem festen Lockfile und einem CPython-Vergleich zu testen. Füge den Interpreter zum CI hinzu, wenn deine Bibliothek Unterstützung für alternative Implementierungen verspricht. Prüfe die glibc-Basis, verifiziere die Prüfsummen des Archivs, teste HTTPS-Zertifikate und untersuche jede native Abhängigkeit. Behandle Python 3.12 als Beta und cp312-abi3-Kompatibilität als ein Ökosystemprojekt, das noch läuft.

Das reicht aus, um die Version ernsthaft auszuprobieren. Das stärkste Argument für PyPy war nie, dass jedes Python-Programm wechseln sollte. Es lautet vielmehr, dass das Python-Ökosystem mehr als eine ernstzunehmende Implementierung haben sollte und dass die Wahl einer solchen Implementierung möglich sein muss, ohne gewöhnliche Paketierung in ein eigenes Engineering-Projekt zu verwandeln. PyPy 8.0 bringt dieses Ziel voran. Der nächste Schritt liegt jedoch ebenso bei Bibliotheksmaintainern und Paketierungswerkzeugen wie beim Interpreterteam.

Quellen

Die Einordnung stützt sich auf die PyPy-Release-Notiz zu Version 8.0.0, die PyPy-Dokumentation zu Download, Installation und Prüfsummen, das PyPy-Repository, die Spezifikationen des Python Packaging User Guide zu Plattform-Kompatibilitätstags und binären Erweiterungen, die Cython-Dokumentation zur PyPy-Portierung, die PyO3-Anleitung zu Build und Distribution sowie die öffentliche Diskussion zur Veröffentlichung.