CPythons JIT soll nach dem Rückzug von PEP 836 entfernt werden

Der experimentelle Just-in-time-Compiler (JIT) in CPython, dem Standard-Interpreter von Python, wird voraussichtlich aus dem Main-Branch des Projekts entfernt. Seine Autoren zogen am 19. Oktober 2026 PEP 836 zurück, den Vorschlag, der den JIT zu einer offiziellen Funktion machen sollte. LWN.net berichtete am 26. Oktober, dass der Code wahrscheinlich „ziemlich bald“ entfernt wird, idealerweise früh im Zyklus von Python 3.16. Damit endet vorerst der Versuch, Standard-Python mit einem in den Interpreter eingebauten Compiler schneller zu machen.

Ein JIT übersetzt häufig ausgeführten Python-Code in Maschinencode, während das Programm läuft. Die offiziellen Windows- und macOS-Builds von Python 3.15 enthalten einen als Experiment, standardmäßig ausgeschaltet.

Wie es so weit kam

Auslöser war eine Ankündigung des Python Steering Council vom 5. Juni 2026, des Gremiums, das die Sprache steuert. Darin forderte er einen formalen Vorschlag, einen sogenannten Standards Track PEP (Python Enhancement Proposal), der begründet, warum der JIT ein unterstützter Teil von CPython sein soll.

Der Council legte feste Bedingungen fest:

Regel	Detail
Neue JIT-Arbeit	Keine neuen Funktionen, Optimierungen oder Performance-Arbeit auf main, bis ein PEP angenommen ist
Weiterhin erlaubt	Fehlerbehebungen und Sicherheitskorrekturen
Frist	Sechs Monate, um einen PEP einzureichen und darüber zu entscheiden
Wenn kein PEP angenommen wird	„Der JIT-Code muss aus dem Main-Branch entfernt werden“
Python 3.15	Der Council war „mit dem Status quo für 3.15 einverstanden“

Der Council sagte, er glaube nicht, dass das JIT-Team den Prozess umgangen habe. Er räumte ein, dass er selbst beim Prozess nicht streng genug gewesen sei.

Was PEP 836 vorschlug

Savannah Ostrowski, Ken Jin und Brandt Bucher schrieben PEP 836 mit dem Titel „JIT Go Brrr“, ausgerichtet auf Python 3.16. Der PEP verlangte nicht, den JIT sofort für unterstützt zu erklären. Er schlug einen zeitlich begrenzten Weg mit messbaren Zielen vor.

• Mit GIL: Der JIT-Build soll im ersten Jahr mindestens 5 % schneller sein als der normale Interpreter. Das GIL, das Global Interpreter Lock, ist die Sperre, die immer nur einen Thread gleichzeitig Python-Code ausführen lässt.
• Free-threaded: mindestens 20 % schneller als der Free-threaded-Interpreter bis zur ersten Beta von Python 3.17.
• Designänderung: weg vom Aufzeichnen von Traces häufig ausgeführten Codes, hin zum Kompilieren ganzer Methoden.

Laut LWN antwortete der Council am 21. September. Er sagte, der PEP beantworte seine Fragen, auch wenn manche Antworten weniger überzeugend seien. Er wollte trotzdem mehr zu Sicherheit, Plattformunterstützung und für Nutzer sichtbarem Verhalten. Eine für den ersten Release Candidate von 3.17 geplante Kompatibilitätsprüfung nannte er „viel, viel zu spät“.

Laut InfoWorld sagte der Council außerdem, dem PEP fehlten Details zu langfristigem Support, Performance-Tests und Debugging-Werkzeugen. Die Geschwindigkeitsziele nannte er zu optimistisch.

Warum die Autoren zurückzogen

„Wir haben nicht das Gefühl, die persönlichen Kapazitäten zu haben, um die aktuelle Version weiterzuführen“, schrieb Ostrowski, wie InfoWorld zitiert. „Der Steering Council legt bei einem Vorschlag dieses Umfangs zu Recht hohe Maßstäbe an“, fügte sie hinzu. Das Team glaube weiterhin an „die technische Richtung, die im PEP skizziert ist“, sagte sie.

LWN weist darauf hin, dass Ostrowski Release Managerin für Python 3.16 und 3.17 ist. Im Beitrag zum Rückzug hieß es, der Referenzcode werde veröffentlicht und im PEP verlinkt.

Die Gewinne waren real, aber bescheiden. PEP 836 nennt für Python 3.15 einen Geschwindigkeitszuwachs von 4 bis 12 % im geometrischen Mittel auf den wichtigsten Plattformen. Laut InfoWorld halfen die Gewinne vor allem bestimmten Arten von Programmen, etwa lang laufenden engen Schleifen.

Was das für Entwickler bedeutet

Die meisten Python-Nutzer haben den JIT nie eingeschaltet, daher ist alltäglicher Code nicht betroffen. Einige Gruppen sollten trotzdem handeln.

• Python 3.15 bleibt unverändert. Der Council hat den Status quo für 3.15 akzeptiert. Wenn Sie heute PYTHON_JIT=1 setzen, funktioniert das in diesem Release weiter.
• Planen Sie nicht mit einem JIT in 3.16. Die Entfernung wird früh im Zyklus von 3.16 erwartet. Betrachten Sie jeden Geschwindigkeitsgewinn, den Sie unter 3.15 gemessen haben, als vorübergehend.
• Einfachere Builds in Sicht. JIT-Builds brauchen beim Bauen LLVM, ein Compiler-Toolkit. Teams, die Python aus dem Quellcode bauen, können diesen Schritt später wahrscheinlich weglassen.
• Suchen Sie anderswo nach Geschwindigkeit. Der Council selbst nannte separate JIT-Projekte wie CinderX, Numba und PyTorch. Profilieren Sie zuerst Ihren Code und wählen Sie dann das Werkzeug, das zum Hot Path passt.
• Forks könnten weitermachen. Brett Cannon sagte laut LWN, dass ein Stopp der Arbeit in main die Arbeit anderswo nicht stoppt. Ein wiederbelebter JIT müsste dieselbe hohe Hürde nehmen, um zurückzukommen.

Python 3.15.0 erschien am 9. Oktober mit einem schnelleren JIT als einer der wichtigsten Neuerungen. Weniger als drei Wochen später hat genau dieser JIT keinen Weg mehr, offiziell zu werden.