Python Language Summit 2026 debattiert Rust und einen neuen GC

Die Python Software Foundation hat am 30. September ihre Berichte vom Python Language Summit 2026 veröffentlicht. Auf dem Summit streiten die Kernentwickler von Python über die Zukunft der Sprache, bevor daraus ein formaler Vorschlag wird. Einer der konkretesten Pläne kam vom Team Rust for CPython: Rust schrittweise in CPython bringen, den wichtigsten Python-Interpreter.

Die Zusammenfassung der PSF berichtet, dass sich 47 Kernentwickler und Gäste am 14. Juli 2026 in Krakau in Polen trafen, auf der EuroPython 2026. Sie hörten 10 lange Vorträge und 5 Lightning Talks. Es war der erste Summit in Europa seit Florenz im Jahr 2011. "Künftig wird der Python Language Summit jährlich zwischen PyCon US und EuroPython wechseln", schreibt die PSF. Seth Larson hat die Berichte verfasst, und LWN wies am selben Tag darauf hin.

Rust wird vom Experiment zum Plan

David Hewitt sprach für das Team Rust for CPython. Es wird von Kirill Podoprigora und Emma Smith geleitet und hat etwa 60 Entwickler. Das Team will Rust nach und nach in CPython einführen, beginnend mit kleinen, abgeschlossenen Modulen.

Der erste Kandidat ist zlib, das Kompressionsmodul, aufgebaut auf der Bibliothek zlib-rs. Der Bericht bei Python Insider zitiert das Team, zlib-rs sei "auf vielen Plattformen schneller als zlib und zlib-ng". Das Argument für Rust ist Sicherheit. Die Zahl der Issues mit dem CPython-Label type-crash stieg von 82 im Jahr 2021 auf voraussichtlich 353 im Jahr 2026.

Die Phasen des Plans reichen über Python 3.16 im Oktober 2027, 3.17 im Oktober 2028 und 3.18 im Jahr 2029 oder später. Die Rust-Unterstützung auf verschiedenen Plattformen sei "immer weniger ein Problem", sagt das Team. Hewitt war auch beim Endzustand deutlich: "Es wäre unaufrichtig zu sagen, dass Rust für immer optional bleibt." CPython bleibt "für eine beträchtliche Zeit ein zweisprachiges Projekt".

Ein neuer Plan für die Garbage Collection

Mark Shannon sagte, die Garbage Collection, also das Finden und Freigeben ungenutzten Speichers, beanspruche etwa 11,67 % der Laufzeit von Python. Er schlug eine Mischung aus zwei Ansätzen vor. Ein generationeller Collector prüft neue Objekte am häufigsten, weil "die meisten Objekte jung sterben". Ein inkrementeller Collector erledigt seine Arbeit in kleinen Stücken statt in einem langen Stopp.

Der Grund sind die Pausenzeiten. Shannon bezifferte inkrementelle Pausen auf "einige zehn Millisekunden", gegenüber etwa 3 Sekunden beim generationellen Ansatz. In seinem Entwurf startet die junge Generation mit 20 MB. In einem Punkt war der Raum uneins: ob Python Einstellungen im Stil von Java anbieten soll, um den Collector abzustimmen.

Nach dem Free-Threading: ein sichereres Nebenläufigkeitsmodell

Free-Threading ist der neue Build von Python, der Threads wirklich parallel ausführen kann. Tobias Wrigstad, Fridtjof Stoldt und Donghee Na fragten, was danach kommt. Sie schlugen Behavior-Oriented Concurrency vor, ein Modell, in dem Aufgaben vor dem Start angeben, welche Daten sie brauchen.

Jedes gemeinsam genutzte Datum liegt in einem "cown", kurz für concurrent owner, den immer nur eine Aufgabe gleichzeitig nutzen kann. Ein Dekorator @when nennt die cowns, die eine Aufgabe braucht. Laut den Vortragenden verhindert dieses Design Deadlocks und Data Races. Ein Proof of Concept, bocpy, läuft bereits auf stabilem Python und nutzt Subinterpreter. Der Summit legte sich auf keinen Ansatz fest und sprach sich für mehr Forschung aus.

Typisierung, ein std-Namespace und schnellerer Start

Vortrag	Vortragender	Die Idee
PEP 827, Typmanipulation	Michael J. Sullivan	Typen, die andere Typen berechnen, etwa ORM-Typen für Anlegen und Ändern aus einem Modell ableiten
Namespaces	Pablo Galindo Salgado	Ein oberster Namespace std, damit import std.json immer die Standardbibliothek meint
Speicher-Snapshots	Hood Chatham	Einen gestarteten Interpreter speichern und wiederherstellen, was "Hello, world" in Pyodide von 1,406 s auf 0,353 s senkt
macOS-Unterstützung	Ned Deily	macOS in PEP 11, die Richtlinie zur Plattformunterstützung, aufnehmen und einen Installer mit 25 Jahren technischer Schulden modernisieren

Sullivan betonte, dass "Nutzer solche Typen nicht schreiben sollen oder nur sehr selten". Galindo Salgado versprach, dass das alte import json weiter funktioniert: "Wir können die Welt nicht kaputtmachen, das wäre schlecht." Das Hauptrisiko bei Snapshots ist die Sicherheit. Ein Hash-Seed, der bei jedem Lauf zufällig sein soll, würde eingefroren und geteilt.

Was das für Entwickler bedeutet

Hier ist noch nichts entschieden. Der Summit ist eine Diskussion, und jede Änderung braucht noch ein PEP, das formale Vorschlagsverfahren von Python. Lesen Sie die Berichte als Karte dafür, wohin die nächsten Versionen steuern.

Wenn Sie CPython aus dem Quellcode bauen, prüfen Sie jetzt die Rust-Frage. Das betrifft Linux-Distributionen, Embedded-Boards und ungewöhnliche Plattformen. Hewitts eigene Worte sagen, dass Rust nicht für immer optional bleibt. Stellen Sie sicher, dass es für jede Plattform, die Sie ausliefern, eine Rust-Toolchain gibt, bevor das zlib-Modul es wichtig macht.

Benennen Sie lokale Dateien nicht mehr nach Modulen der Standardbibliothek. Eine Datei namens json.py oder random.py in Ihrem Projekt kann schon heute das echte Modul verdecken. Der std-Namespace soll dieses Problem lösen, aber gute Namen lösen es sofort.

Wenn Ihr Dienst unter langen Pausen der Garbage Collection leidet, verfolgen Sie Shannons Arbeit. Bauen Sie aber noch keine Abstimmung darauf auf, denn der Summit war sich uneins, ob es überhaupt Einstellungen geben soll.

Bibliotheksautoren sollten PEP 827 lesen. ORM- und Framework-Maintainer sind die Zielgruppe. Anwendungsentwickler profitieren meist, ohne solche Typen selbst zu schreiben.

Probieren Sie bocpy aus, wenn Sie nebenläufiges Python schreiben. Es läuft auf dem heutigen Python, und Rückmeldungen jetzt beeinflussen, was das Kernteam baut.