EVE Online empieza a mover 2,4 millones de líneas de Python 2 a Python 3

CCP Games empezó el 25 de agosto de 2026 a migrar EVE Online de Python 2 a Python 3, según una publicación para desarrolladores en el sitio del propio juego. Para quien mantiene código antiguo, lo interesante es la escala y el método: 2,4 millones de líneas repartidas en unos 20.000 archivos, movidas mientras el juego sigue en línea.

EVE funciona sobre Stackless Python 2.7 desde 2010. Stackless Python es una versión modificada de Python creada para una concurrencia muy alta. La publicación de CCP atribuye a sus «tasklets ligeros» que «un solo nodo servidor haga malabares con miles de pilotos a la vez». Los tasklets son unidades mínimas de trabajo que un programa puede pausar y reanudar de forma económica. Así una máquina puede seguir a muchos jugadores sin un hilo por jugador.

Qué está ya arreglado y qué no

Los números de la publicación de CCP son la parte útil. La empresa dice que el 95,9 % de la base de código ya se analiza bajo Python 2 y bajo Python 3. Analizar significa que el intérprete puede leer el archivo, antes de ejecutar una sola línea.

Quedan dos problemas distintos. Unas 3.300 líneas todavía fallan al analizarse bajo Python 3 y hay que reescribirlas. Un conjunto mayor, unas 20.000 líneas, se analiza bien pero se comporta de forma distinta entre las dos versiones. El segundo grupo es el más difícil, porque nada se cae para indicarle dónde está.

CCP lo hace por etapas. La etapa uno, en marcha ahora, mantiene el juego en Python 2.7 mientras reescribe código para que sea válido en ambas. La etapa dos, aún por llegar, atiende las líneas que se comportan distinto. Según la publicación, algunas etapas usan herramientas que la comunidad de Python ya construyó, como Futurize, y otras apuntan a funciones propias de EVE.

Por qué Stackless Python es un callejón sin salida

Quedarse quieto no era realmente una opción. El proyecto Stackless quedó archivado como solo lectura en febrero de 2025, según una reseña de la charla de CCP en el Fanfest 2025 publicada por The Nosy Gamer. Un proyecto archivado no entrega más versiones, así que lo construido sobre él también deja de avanzar.

Esa misma reseña cubre una migración que CCP ya terminó en su capa de motor, y conviene separarla de la noticia de esta semana. CARBON es el motor que comparten los juegos de CCP. Pasó de Stackless Python 2.7 a Stackless Python 3.8.1 en noviembre de 2023. Después pasó al Python 3.12 estándar, que se entregó primero en EVE Frontier en junio de 2024. The Nosy Gamer informa que CCP midió una mejora media del 20 % en el rendimiento del motor. La reseña cita también un segundo beneficio, más silencioso. Python 3.12 incluye tracemalloc, una herramienta integrada de seguimiento de memoria, y encontró fugas mejor que las herramientas internas de CCP. The Nosy Gamer señala además una razón de personal muy directa para el cambio: los programadores nuevos que llegan a CCP no tienen experiencia con Python 2.7.

Cuándo	Qué se movió
2007	EVE pasa a Stackless Python 2.5
2010	EVE pasa a Stackless Python 2.7
Nov. 2023	El motor CARBON alcanza Stackless Python 3.8.1
Jun. 2024	CARBON alcanza Python 3.12, entregado en EVE Frontier
Feb. 2025	Stackless Python archivado, solo lectura
Jul. 2026	La migración de EVE se prueba en Singularity, el servidor de pruebas
25 ago. 2026	La etapa uno entra en Tranquility, el servidor en vivo

Qué reciben los jugadores ahora mismo

Nada, y CCP lo dice directamente. Preguntada por lo que cambia a corto plazo para los jugadores, la publicación responde: «A corto plazo, nada, y eso es a propósito». La recompensa prometida llega después, y se expresa en términos llanos: correcciones de errores más rápidas, mejores herramientas, espacio para nuevas funciones y un juego más rápido con el tiempo.

Qué significa esto para los desarrolladores

La cifra del 95,9 % es la que hay que tomar prestada. CCP no sigue el «porcentaje migrado». Sigue el porcentaje que se analiza bajo las dos versiones a la vez, y esa es una medición que usted puede ejecutar hoy en integración continua. Compile cada archivo con el intérprete de destino, cuente los fallos y tendrá una gráfica descendente en lugar de una estimación vaga. Eso convierte una migración temible en una migración contable.

Fíjese en qué cubo trata CCP como el trabajo real. Las 3.300 líneas no analizables son ruidosas y finitas. Las 20.000 líneas que solo se comportan distinto son el riesgo. La división entera, el orden de los diccionarios y las diferencias entre cadenas y bytes producen respuestas equivocadas en vez de errores. Si planea un cambio parecido, invierta en pruebas que comprueben valores, no en pruebas que solo comprueben que nada se lanzó.

La estrategia de doble ejecución es la parte que la mayoría de los equipos se salta y no debería saltarse. Hacer que el código sea válido en las dos versiones antes de cambiar de intérprete significa que cada cambio pasa por el proceso normal de entrega, sobre el runtime antiguo, sin un día de cambio brusco. Es más lento en el papel y mucho más seguro en la práctica, sobre todo para un servicio que no puede caerse.

Por último, trate la salud del upstream de su runtime como una dependencia real. La restricción de CCP no era Python 2, era Stackless, un fork que ahora está archivado. Un fork que hoy resuelve un problema con elegancia se convierte mañana en el techo de su plataforma. Compruebe entonces qué han entregado últimamente sus forks críticos.