EVE Online beginnt Umzug von 2,4 Millionen Zeilen Python 2 auf Python 3

CCP Games hat am 25. August 2026 begonnen, EVE Online von Python 2 auf Python 3 zu migrieren. Das steht in einem Entwicklerbeitrag auf der Website des Spiels. Für alle, die alten Code pflegen, ist der Maßstab und die Methode interessant: 2,4 Millionen Zeilen in rund 20.000 Dateien, umgezogen während das Spiel online bleibt.

EVE läuft seit 2010 auf Stackless Python 2.7. Stackless Python ist eine abgewandelte Python-Version für sehr hohe Parallelität. CCPs Beitrag schreibt den „leichtgewichtigen ‚Tasklets'" zu, dass „ein einzelner Server-Knoten Tausende Piloten gleichzeitig jonglieren" kann. Tasklets sind winzige Arbeitseinheiten, die ein Programm günstig anhalten und fortsetzen kann. So kann eine Maschine viele Spieler verfolgen, ohne je einen Thread pro Spieler.

Was schon behoben ist und was nicht

Die Zahlen in CCPs Beitrag sind der nützliche Teil. Das Unternehmen sagt, 95,9 % der Codebasis ließen sich bereits unter Python 2 und Python 3 parsen. Parsen heißt, dass der Interpreter die Datei überhaupt lesen kann, bevor eine Zeile läuft.

Damit bleiben zwei getrennte Probleme. Rund 3.300 Zeilen scheitern unter Python 3 noch am Parsen und müssen umgeschrieben werden. Eine größere Menge, etwa 20.000 Zeilen, parst einwandfrei, verhält sich zwischen den Versionen aber anders. Die zweite Gruppe ist die schwierigere, denn nichts stürzt ab und zeigt Ihnen die Stelle.

CCP geht in Etappen vor. Etappe eins läuft jetzt und hält das Spiel auf Python 2.7, während Code so umgeschrieben wird, dass er unter beiden gültig ist. Etappe zwei steht noch aus und behandelt die Zeilen, die sich anders verhalten. Laut dem Beitrag nutzen manche Etappen Werkzeuge, die die Python-Community schon gebaut hat, etwa Futurize. Andere zielen auf Eigenheiten, die nur EVE hat.

Warum Stackless Python eine Sackgasse ist

Bleiben war keine echte Option. Das Stackless-Projekt wurde im Februar 2025 auf den Nur-Lese-Status archiviert. Das berichtet The Nosy Gamer in einer Zusammenfassung von CCPs Fanfest-Vortrag 2025. Ein archiviertes Projekt liefert keine weiteren Releases, also bewegt sich auch nichts mehr, was darauf aufbaut.

Derselbe Bericht behandelt eine Migration, die CCP auf seiner Engine-Ebene bereits abgeschlossen hat. Man sollte sie von der Nachricht dieser Woche trennen. CARBON ist die Engine, die CCPs Spiele gemeinsam nutzen. Sie ging im November 2023 von Stackless Python 2.7 auf Stackless Python 3.8.1. Danach wechselte sie auf das reguläre Python 3.12, das im Juni 2024 zuerst in EVE Frontier ausgeliefert wurde. The Nosy Gamer berichtet, CCP habe im Schnitt 20 % mehr Engine-Leistung gemessen. Der Bericht nennt auch einen zweiten, leiseren Vorteil. Python 3.12 bringt tracemalloc mit, ein eingebautes Werkzeug zur Speicherverfolgung, und es fand Lecks besser als CCPs eigene Werkzeuge. The Nosy Gamer nennt zudem einen nüchternen Personalgrund für den Umzug: neue Programmierer, die zu CCP kommen, haben keine Erfahrung mit Python 2.7.

Wann	Was umgezogen ist
2007	EVE wechselt auf Stackless Python 2.5
2010	EVE wechselt auf Stackless Python 2.7
Nov. 2023	CARBON-Engine erreicht Stackless Python 3.8.1
Juni 2024	CARBON erreicht Python 3.12, ausgeliefert in EVE Frontier
Feb. 2025	Stackless Python archiviert, nur lesbar
Juli 2026	EVEs Migration auf Singularity getestet, dem Testserver
25. Aug. 2026	Etappe eins geht auf Tranquility live, dem Live-Server

Was Spieler jetzt davon haben

Nichts, und CCP sagt das direkt. Auf die Frage, was sich kurzfristig für Spieler ändert, antwortet der Beitrag: „Kurzfristig nichts, und das ist so gewollt." Der versprochene Gewinn kommt später und steht in klaren Worten da: schnellere Bugfixes, bessere Werkzeuge, Raum für neue Features und über die Zeit ein schnelleres Spiel.

Was das für Entwickler bedeutet

Die Zahl 95,9 % ist die, die man übernehmen sollte. CCP verfolgt nicht „Prozent migriert". Es verfolgt den Prozentsatz, der unter beiden Versionen gleichzeitig parst, und das ist eine Messung, die Sie heute in Ihrer Continuous Integration laufen lassen können. Kompilieren Sie jede Datei unter dem Ziel-Interpreter, zählen Sie die Fehler, und Sie haben ein Burn-down-Diagramm statt einer vagen Schätzung. Das macht aus einer beängstigenden Migration eine zählbare.

Beachten Sie, welchen Topf CCP als die echte Arbeit behandelt. Die 3.300 nicht parsbaren Zeilen sind laut und endlich. Die 20.000 Zeilen, die sich lediglich anders verhalten, sind das Risiko. Denn Integer-Division, Reihenfolge in Dictionaries und Unterschiede zwischen String und Bytes liefern falsche Ergebnisse statt Fehler. Wenn Sie einen ähnlichen Umzug planen, investieren Sie in Tests, die Werte prüfen, nicht in Tests, die nur prüfen, dass nichts geworfen wurde.

Die Doppellauf-Strategie ist der Teil, den die meisten Teams überspringen und nicht überspringen sollten. Code in beiden Versionen gültig zu machen, bevor der Interpreter wechselt, heißt: jede Änderung geht über den normalen Release-Weg, auf der alten Laufzeit, ohne großen Umschalttag. Auf dem Papier ist das langsamer und in der Praxis viel sicherer, besonders für einen Dienst, der nicht ausfallen darf.

Behandeln Sie zuletzt die Gesundheit Ihrer Laufzeit-Upstreams als echte Abhängigkeit. CCPs Einschränkung war nicht Python 2, sondern Stackless, ein Fork, der jetzt archiviert ist. Ein Fork, der heute ein Problem elegant löst, wird morgen zur Obergrenze Ihrer Plattform. Prüfen Sie also, was Ihre kritischen Forks zuletzt ausgeliefert haben.