EVE Online commence à migrer 2,4 millions de lignes de Python 2 vers Python 3

CCP Games a commencé le 25 août 2026 à migrer EVE Online de Python 2 vers Python 3, selon une publication destinée aux développeurs sur le site du jeu. Pour quiconque maintient du vieux code, l'intérêt tient à l'échelle et à la méthode : 2,4 millions de lignes réparties sur environ 20 000 fichiers, déplacées pendant que le jeu reste en ligne.

EVE tourne sur Stackless Python 2.7 depuis 2010. Stackless Python est une version modifiée de Python conçue pour une très forte concurrence. La publication de CCP attribue à ses « tasklets légers » le fait qu'« un seul nœud serveur jongle avec des milliers de pilotes à la fois ». Les tasklets sont de minuscules unités de travail qu'un programme peut suspendre et reprendre à bas coût. Une machine peut ainsi suivre de nombreux joueurs sans un fil d'exécution par joueur.

Ce qui est déjà corrigé, et ce qui ne l'est pas

Les chiffres de la publication de CCP sont la partie utile. L'entreprise indique que 95,9 % de la base de code s'analyse déjà sous Python 2 et sous Python 3. Analyser signifie que l'interpréteur peut lire le fichier, avant d'en exécuter une seule ligne.

Restent deux problèmes distincts. Environ 3 300 lignes échouent encore à l'analyse sous Python 3 et doivent être réécrites. Un ensemble plus large, environ 20 000 lignes, s'analyse sans souci mais se comporte différemment entre les deux versions. Le second groupe est le plus difficile, car rien ne plante pour vous dire où il se trouve.

CCP procède par étapes. L'étape un, en cours, maintient le jeu sur Python 2.7 tout en réécrivant le code pour qu'il soit valide sous les deux. L'étape deux, encore à venir, traite les lignes qui se comportent différemment. Selon la publication, certaines étapes emploient des outils déjà construits par la communauté Python, comme Futurize, tandis que d'autres visent des fonctionnalités propres à EVE.

Pourquoi Stackless Python est une impasse

Rester en place n'était pas vraiment une option. Le projet Stackless a été archivé en lecture seule en février 2025, selon un compte rendu de la conférence Fanfest 2025 de CCP publié par The Nosy Gamer. Un projet archivé ne livre plus aucune version, donc tout ce qui repose dessus cesse d'avancer aussi.

Ce même compte rendu couvre une migration que CCP a déjà terminée sur sa couche moteur, qu'il vaut la peine de distinguer de l'actualité de cette semaine. CARBON est le moteur partagé par les jeux de CCP. Il est passé de Stackless Python 2.7 à Stackless Python 3.8.1 en novembre 2023. Il est ensuite passé au Python 3.12 standard, livré d'abord dans EVE Frontier en juin 2024. The Nosy Gamer rapporte que CCP a mesuré une amélioration moyenne de 20 % des performances du moteur. Le compte rendu cite aussi un second bénéfice, plus discret. Python 3.12 embarque tracemalloc, un outil intégré de suivi mémoire, et il a trouvé les fuites mieux que l'outillage interne de CCP. The Nosy Gamer avance également une raison de personnel toute simple : les nouveaux programmeurs qui arrivent chez CCP n'ont pas d'expérience de Python 2.7.

Quand	Ce qui a bougé
2007	EVE passe à Stackless Python 2.5
2010	EVE passe à Stackless Python 2.7
Nov. 2023	Le moteur CARBON atteint Stackless Python 3.8.1
Juin 2024	CARBON atteint Python 3.12, livré dans EVE Frontier
Févr. 2025	Stackless Python archivé, en lecture seule
Juill. 2026	Migration d'EVE testée sur Singularity, le serveur de test
25 août 2026	L'étape un passe en production sur Tranquility

Ce que les joueurs y gagnent maintenant

Rien, et CCP le dit directement. Interrogée sur ce qui change à court terme pour les joueurs, la publication répond : « À court terme, rien, et c'est voulu. » Le gain promis vient plus tard, et il est énoncé simplement : des correctifs plus rapides, de meilleurs outils, de la place pour de nouvelles fonctionnalités, et un jeu plus rapide avec le temps.

Ce que cela signifie pour les développeurs

Le chiffre de 95,9 % est celui à emprunter. CCP ne suit pas un « pourcentage migré ». Elle suit le pourcentage qui s'analyse sous les deux versions à la fois, et c'est une mesure que vous pouvez lancer dès aujourd'hui en intégration continue. Compilez chaque fichier sous l'interpréteur cible, comptez les échecs, et vous obtenez une courbe de progression au lieu d'une estimation vague. Cela transforme une migration effrayante en migration dénombrable.

Notez quel lot CCP considère comme le vrai travail. Les 3 300 lignes inanalysables sont bruyantes et finies. Les 20 000 lignes qui se comportent seulement différemment sont le risque. La division entière, l'ordre des dictionnaires et les différences entre chaînes et octets produisent de mauvaises réponses plutôt que des erreurs. Si vous préparez une migration semblable, investissez dans des tests qui vérifient des valeurs, pas dans des tests qui vérifient seulement que rien n'a été levé.

La stratégie du double fonctionnement est la partie que la plupart des équipes sautent et ne devraient pas sauter. Rendre le code valide dans les deux versions avant de changer d'interpréteur signifie que chaque modification passe par le processus de livraison habituel, sur l'ancienne exécution, sans jour de bascule brutal. C'est plus lent sur le papier et bien plus sûr en pratique, surtout pour un service qui ne peut pas tomber.

Enfin, traitez la santé de l'amont de votre exécution comme une vraie dépendance. La contrainte de CCP n'était pas Python 2, c'était Stackless, un fork désormais archivé. Un fork qui résout un problème avec élégance aujourd'hui devient demain le plafond de votre plateforme. Vérifiez donc ce que vos forks critiques ont livré récemment.