Der JIT wurde aufgenommen – doch die Genehmigung blieb aus
Der experimentelle JIT-Compiler von Python kam in CPython 3.13 als Opt-in-Feature hinzu und baute auf Arbeiten auf, die Ende 2023 und Anfang 2024 begonnen hatten. Core-Entwickler Brandt Bucher führte zunächst den copy-and-patch JIT zusammen, der die Laufzeit-Performance steigern sollte.
Der JIT erhielt jedoch nie eine formelle, langfristige Genehmigung. Er wurde unter PEP 744 ausgeliefert, einem Informational PEP, der das Feature lediglich beschrieb, statt unter einem Standards Track PEP, der seinen Platz und die Verpflichtung zur fortlaufenden Wartung gefestigt hätte. Diese verfahrensmäßige Lücke ließ seine Zukunft von Anfang an ungewiss.
Dies war keine fehlerbedingte Rücknahme; der Code selbst funktionierte. Vielmehr erlaubt das Python-Projekt, experimentelle Features ohne dauerhafte Verpflichtung auszuliefern, und schafft so einen Raum für Innovation, der das Kernteam nicht automatisch zu unbefristetem Support verpflichtet. Die Entfernung des JIT beruht auf diesem fehlenden formellen Konsens, nicht auf einem technischen Mangel.
Der Python Steering Council stellte schließlich ein Ultimatum: einen Standards Track PEP erreichen, oder der JIT würde entfernt. Dies unterstrich, dass das Ausliefern experimentellen Codes eine Sache ist, die Community und Maintainer jedoch dazu zu bewegen, Ressourcen unbefristet zuzusagen, in der Open-Source-Entwicklung eine weit größere Herausforderung darstellt.
Der Council verlangte Belege, keine Versprechen
Der Steering Council von Python, wenig beeindruckt von der informellen Einführung des JIT, stellte im Juni 2026 ein Ultimatum: Innerhalb von sechs Monaten einen Standards-Track-Vorschlag einreichen und durchbringen, andernfalls würde der experimentelle JIT-Code aus dem main-Branch entfernt. Das war keine Empfehlung, sondern eine harte Frist für ein Feature, das die übliche Governance umgangen hatte.
Daraufhin reichten Savannah Savannah Ostrowski, Ken Jin und Brandt Bucher im Juli 2026 PEP 836 ein, treffend betitelt „JIT Go Brrr: The Path to a Supported JIT Compiler for CPython“. Die 10-Punkte-Kritik des Councils fiel prompt und unnachgiebig aus. Er kritisierte den PEP für mangelnde Beachtung der Sicherheit, bezeichnete sie als „vernachlässigten Bereich“, und wies die Prognosen zu Performance und Nutzerauswirkungen als „übermäßig optimistisch“ zurück.
Die vielleicht vernichtendste Ablehnung betraf die vorgeschlagene Kompatibilitätsprüfung, die für den Release Candidate von Python 3.17 im August 2028 vorgesehen war. Der Council hielt diesen Zeitplan für „viel, viel zu spät“ und unterstrich damit seine Forderung nach sofortigen, belastbaren Zusicherungen. Ohne eine überzeugende Roadmap sah die Zukunft des JIT trotz seines anfänglichen Versprechens zunehmend düster aus.
Einem vielversprechenden Vorschlag gingen die Leute aus
Das Ultimatum des Python Steering Council wog schwer, doch ein vielversprechender Vorschlag fand keinen Halt. Am 19. Oktober 2026 zog Savannah Savannah Ostrowski – Release Manager für Python 3.16 und 3.17 – PEP 836 offiziell zurück, den Vorschlag „JIT Go Brrr“, der den JIT auf den Standards-Track-Status heben sollte. Ihre Begründung: ein deutlicher Mangel an „persönlicher Kapazität, um die aktuelle Version weiterzuführen“.
Das war keine Erklärung, dass JITs wertlos seien; im Gegenteil. Savannah Ostrowski und ihr Team blieben vom Potenzial der Technologie überzeugt, die Performance von Python zu steigern. Der Rückzug spiegelte den enormen technischen und politischen Aufwand wider, der nötig gewesen wäre, um die strengen Anforderungen des Councils zu erfüllen. Dazu gehörten die Klärung von Sicherheitsbedenken und der Nachweis robusterer Performance-Gewinne als die moderaten Beschleunigungen von 4–12 % (geometrisches Mittel), die in eng gefassten Benchmarks beobachtet wurden.
Das Feedback des Councils war deutlich: Es bezeichnete Sicherheit als „vernachlässigten Bereich“ und hielt die vorgeschlagene Kompatibilitätsprüfung im August 2028 für Python 3.17 für „viel, viel zu spät“. Ohne die nötigen Ressourcen, diese Punkte umfassend anzugehen, konnte PEP 836 nicht weiterverfolgt werden. Hintergründe zur ursprünglichen, weniger formellen Einführung des JIT finden Sie in PEP 744 – JIT Compilation.
Die Folge steht nun so gut wie fest: Der experimentelle JIT-Code wird zu Beginn des Entwicklungszyklus von Python 3.16 aus dem Main-Branch von CPython entfernt. Pythons kurzes Intermezzo mit einem In-Tree-JIT scheint damit beendet – ein Opfer der Realität von Open Source, in der das Ausliefern von Code oft der einfachste Teil ist.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Der eigentliche Engpass ist die langfristige Verantwortung
Das Mergen von Code ist der Anfang der Open-Source-Entwicklung, nicht ihr Ende. Die bevorstehende Entfernung des JIT aus dem Main-Branch von CPython veranschaulicht eine wichtige Lehre: Verantwortung reicht über die ersten Commits hinaus. Maintainer tragen fortlaufend Verantwortung für Sicherheitsprüfungen, Kompatibilitätsrisiken, Speicherkosten und langfristigen Support – eine Last, die das JIT-Team trotz seines Glaubens an die Technologie nicht tragen konnte.
Dieses Ergebnis sollte nicht als Ende der Bemühungen um die Python-Performance missverstanden werden. Der JIT war ein experimentelles Opt-in-Feature. Ein Großteil der jüngsten Geschwindigkeitsgewinne von CPython, einschließlich der erheblichen Verbesserungen in Python 3.11 und 3.12, stammte vom specializing adaptive interpreter, einer eigenständigen und fortlaufenden Optimierungsstrategie.
Zudem bedeutet diese Entscheidung nicht das Ende der Python-JIT-Entwicklung insgesamt. Alternative Projekte wie PyPy, Numba und PyTorch Inductor nutzen weiterhin JIT-Kompilierung. Diese Lösungen, die andere Workloads und Ausführungsumgebungen adressieren, arbeiten außerhalb des Kernentwicklungspfads von CPython und zeigen, dass das JIT-Konzept für bestimmte Hochleistungsanwendungen in Python weiterhin wichtig ist.
Häufig gestellte Fragen
Warum entfernt CPython seinen experimentellen JIT?
Für den JIT lag kein genehmigter Standards-Track-PEP vor, es bestanden ungelöste Sicherheits- und Kompatibilitätsbedenken, und seine Maintainer konnten die erforderlichen Kapazitäten nicht aufbringen, um den Vorschlag weiterzuverfolgen.
Wurde der JIT wegen Fehlern entfernt?
Nein. Im Mittelpunkt der Entscheidung standen Governance, langfristige Wartung, Sicherheitsprüfung und die Frage, ob der erwartete Nutzen die Kosten rechtfertigte.
Was war der Unterschied zwischen PEP 744 und PEP 836?
PEP 744 dokumentierte den experimentellen JIT, war aber rein informativ. PEP 836 zielte auf die formelle Genehmigung eines unterstützten JIT ab, wurde jedoch von der Hauptautorin zurückgezogen.
Bedeutet das, dass Python nie einen JIT haben wird?
Nein. Die Entscheidung betrifft den JIT im Main-Branch von CPython; unabhängige Projekte und künftige Vorschläge können JIT-Kompilierung weiterhin verfolgen.