Am 25. August hat Fenris Creations, das frühere CCP, den größten Umbau an EVEs Innenleben seit Jahren angekündigt und das Erfolgskriterium gleich mitgeliefert: Man soll nichts davon merken. Für die erste Stufe stimmt das sogar. Nur war die erste Stufe der Teil, bei dem ohnehin nichts passieren konnte.
Der Devblog verkauft den Wechsel von Stackless Python 2.7 auf Python 3 als Modernisierung, hübsch verpackt unter dem Label „EVE Evolved“, der mehrteiligen Devblog-Reihe unter dem Dach von „EVE Forever“. Die Zahlen im selben Text erzählen etwas anderes. EVE hatte keine Wahl. Und der Teil der Arbeit, bei dem du als Spieler tatsächlich etwas merken könntest, hat kein Datum.
Sechzehn Jahre auf derselben Version, und der Notausgang ist zugewachsen
EVE startete 2003 auf Stackless Python. 2007 kam der Sprung auf Stackless 2.5, 2010 auf Stackless 2.7. Danach: nichts. Sechzehn Jahre dieselbe Sprachversion, und am 1. Januar 2020 beerdigte Python selbst den Support für Version 2.
Das klingt nach Trägheit, war aber keine. Stackless ist keine gewöhnliche Python-Variante, sondern eine, die die Codeausführung vom C-Stack entkoppelt und damit sehr viele leichte Tasklets auf einem Node verwaltet. Genau das lässt einen einzelnen Server tausende Piloten gleichzeitig bedienen, und CCP hat an diesem Sonderpfad nicht bloß teilgenommen, sondern kräftig mitgebaut. Der Devblog nennt das Unternehmen einen der bedeutendsten Beitragenden des Projekts.
Der Sonderweg ist inzwischen tot. Das öffentliche Stackless-Projekt auf GitHub wurde am 13. Februar 2025 archiviert, Entwicklung eingestellt, letzte referenzierte Version ein frühes Alpha von Python 3.9. Und die interne Fork der Carbon-Engine, mit der EVE und EVE Frontier laufen, kam laut Frontiers eigenem Devblog nie über Python 3.8 hinaus. Am Ende stand die Wahl zwischen der ewigen Pflege einer eigenen Fork und dem Umstieg auf normales Python 3.
Das ist die ehrlichere Lesart der Ankündigung, und sie macht die Entscheidung besser, nicht schlechter. Erzwungene Züge sind auch Züge. Nur erklärt sie das Timing: Hier modernisiert niemand aus Lust an der Sache, hier läuft ein Unterbau aus, den zuletzt nur noch das eigene Haus gepflegt hat.
Was Stage 1 tatsächlich war
Die Codebasis umfasst 2,4 Millionen Zeilen Python in rund 20.000 Dateien. Ein automatisierter Scan mit echten Interpretern beider Versionen ergab: 95,9 Prozent der Dateien kompilieren bereits unter Python 2.7 und Python 3.
Übrig blieben rund 3.300 Zeilen, die Python 3 hart ablehnt. Etwa 1.500 alte print-Statements. Rund 800 Zahlenliterale im Format 123L. Rund 600 veraltete Exception-Klauseln. Und 50 Stellen mit dem historischen Ungleich-Operator `<>`, was für sich genommen ein hübsches archäologisches Fundstück ist.
Diese 3.300 Zeilen sind Mechanik, kein Denken. Fenris hat sie mit Python-Future umgeschrieben, einem Werkzeug auf Basis derselben 2to3-Mechanik, die Python selbst mitliefert. Ende Juli lief das auf Singularity, am 25. August ging es auf Tranquility. Der Code läuft weiter unter Python 2.7, ist aber jetzt in einem Zustand, den beide Versionen verdauen. Parallel wird das Mission-Agenten-Backend vorbereitet, ebenfalls ohne sichtbaren Effekt.
Dass du seit gut einer Woche nichts gemerkt hast, ist also kein Beleg für irgendwas. Es war der Teil, bei dem 95,9 Prozent der Dateien von vornherein sauber waren.
Die 20.000 Zeilen, die kompilieren und trotzdem falsch rechnen
Jetzt der interessante Teil. Der Devblog nennt eine zweite Zahl, die man nicht mit der Dateizahl verwechseln darf: rund 20.000 Codezeilen kompilieren unter Python 2 und Python 3 fehlerfrei und verhalten sich trotzdem unterschiedlich.
Das Beispiel steht im Devblog selbst. In Python 2 ergibt 1 / 2 den Wert 0. In Python 3 ergibt es 0,5. Kein Fehler, keine Warnung, kein Absturz. Nur ein anderes Ergebnis.
In einem Spiel, in dem solche Zahlen Schaden, ISK oder Koordinaten sein können, ist das die Sorte Änderung, die niemand im Log sieht und jeder im Killboard. Deshalb geht jede dieser rund 20.000 Stellen durch eine menschliche Entscheidung statt durch ein Skript. Genau hier könnte ein Spieler etwas merken, und zwar an exakt den Stellen, an denen man es nicht will.
Für diese zweite Stufe nennt der Devblog kein Datum. Kein Quartal, kein Update-Fenster, keine Andeutung. Das ist kein Vorwurf, im Gegenteil: Ein Termin für 20.000 handgeprüfte Entscheidungen wäre ein Versprechen, das man nur brechen kann. Aber es hat eine Konsequenz für den Leser. Die Entwarnung, die im Devblog steht, gilt für Stage 1. Sie gilt nicht für die Migration.
Frontier zeigt, dass der Weg trägt
Als Beleg, dass das Ziel erreichbar ist, verweist Fenris auf EVE Frontier. Das ist der stärkste Punkt der ganzen Ankündigung, und er ist mehr als PR.
Frontier läuft mit derselben Carbon-Engine auf Python 3.12. Rund 4 Millionen Zeilen Python plus etwa eine Million Zeilen C++ für Client und Server wurden dort über zwölf Minor-Versionen gehoben, sechzehn Jahre Sprachentwicklung in einem Rutsch. Statt auf asyncio umzubauen, ersetzte das Team die Stackless-Scheduling-Logik durch Greenlets mit einem selbstgebauten Scheduler, der Tasklet- und Kanalverhalten so genau wie möglich nachbildet. Der liegt seit der Carbon-Öffnung am 1. Juli unter MIT-Lizenz öffentlich auf GitHub. Wer will, kann nachlesen, wie das Herzstück tickt.
Das Ergebnis ist messbar und geht in die richtige Richtung: 10 bis 30 Prozent mehr Leistung auf den komplizierten Pfaden, etwa bei vielen gleichzeitigen Logins oder beim Waffenfeuer. Wer schon einmal in einer Fleet auf das Laden eines Grids gewartet hat, weiß, wo das ankommen würde.
Der Haken steht nicht im Devblog, ist aber offensichtlich. Frontier ist ein junges Projekt ohne 23 Jahre gewachsene Spielerdaten im Rücken und ohne die Erwartung, an 23,75 von 24 Stunden erreichbar zu sein. Der technische Weg ist bewiesen. Der Weg unter Volllast, mit echten Wallets und echter Sov, ist es nicht.
Was du heute tun kannst, ist genau eine Sache
Und diesmal ist der banale Rat wirklich der richtige: weiterspielen, und wenn etwas komisch aussieht, einen Bugreport schreiben. Nicht im Forum ranten, nicht im Corp-Chat rätseln. Ein Report mit Zeitpunkt und System.
Der Grund steht oben. Die Fehlerklasse, um die es geht, macht keinen Krach. Sie produziert eine Zahl, die knapp danebenliegt, und die fällt nur jemandem auf, der weiß, wie das Ergebnis normalerweise aussieht. Ein Ratter, der seine Anomalien seit Monaten fliegt, erkennt einen falschen Tick schneller als jedes Monitoring.
Eine Auskunft fehlt allerdings, und sie fehlt auffällig. Zu ESI und zu Drittanbieter-Tools sagt der Devblog nichts. Kein Satz, keine Fußnote, kein Verweis. Der separate ESI-Artikel stellt ebenfalls keinen Bezug her; er handelt von Swagger 2.0 auf OpenAPI 3.1 und hat mit Python-Versionen nichts zu tun. Für jedes Werkzeug, das gegen öffentliche ESI-Endpunkte läuft, bleibt damit offen, ob sich in Stage 2 an Datentypen oder Rundungen etwas verschiebt. Das gilt auch für Warzone Companion, das bei mir rein clientseitig gegen diese Endpunkte läuft, aus Gründen, die zum Tool gehören und nicht hierher. Die Antwort ist überall dieselbe: Dazu liegt nichts vor. Das ist ein Befund, kein Anlass zum Spekulieren. Wer Werkzeuge für Sov, Logistik oder Recruitment betreibt, hat schlicht keine Auskunft und sollte das wissen, statt sich in Sicherheit zu wiegen.
Bleibt das Urteil über die Ankündigung selbst. Die Entscheidung ist richtig, sie kommt sechzehn Jahre nach dem letzten Versionswechsel und sechs Jahre nach dem Ende von Python 2, und sie ist ungewöhnlich offen kommuniziert: Ein Studio, das freiwillig hinschreibt, wie viele Zeilen es noch von Hand prüfen muss, hat den schwierigen Teil verstanden. Der Devblog, den man wirklich lesen muss, ist trotzdem der nächste. Der mit dem Datum für Stage 2.