EVE Online começa a mover 2,4 milhões de linhas de Python 2 para Python 3

A CCP Games começou em 25 de agosto de 2026 a migrar o EVE Online de Python 2 para Python 3, segundo uma publicação para desenvolvedores no site do próprio jogo. Para quem mantém código antigo, o interessante é a escala e o método: 2,4 milhões de linhas em cerca de 20.000 arquivos, movidas enquanto o jogo segue no ar.

O EVE roda sobre Stackless Python 2.7 desde 2010. Stackless Python é uma versão modificada do Python feita para concorrência muito alta. A publicação da CCP credita aos seus «tasklets leves» o fato de «um único nó de servidor equilibrar milhares de pilotos ao mesmo tempo». Tasklets são unidades mínimas de trabalho que um programa pode pausar e retomar de forma barata. Assim uma máquina acompanha muitos jogadores sem uma thread por jogador.

O que já foi corrigido e o que não foi

Os números da publicação da CCP são a parte útil. A empresa diz que 95,9% da base de código já é analisada sob Python 2 e sob Python 3. Analisar significa que o interpretador consegue ler o arquivo, antes de executar uma única linha.

Sobram dois problemas distintos. Cerca de 3.300 linhas ainda falham na análise sob Python 3 e precisam ser reescritas. Um conjunto maior, cerca de 20.000 linhas, é analisado sem erro mas se comporta de forma diferente entre as duas versões. O segundo grupo é o mais difícil, porque nada quebra para indicar onde ele está.

A CCP faz isso em etapas. A etapa um, em andamento, mantém o jogo em Python 2.7 enquanto reescreve código para que valha nas duas. A etapa dois, ainda por vir, trata das linhas que se comportam de forma diferente. Segundo a publicação, algumas etapas usam ferramentas que a comunidade Python já construiu, como o Futurize, e outras miram recursos exclusivos do EVE.

Por que o Stackless Python é um beco sem saída

Ficar parado não era realmente uma opção. O projeto Stackless foi arquivado como somente leitura em fevereiro de 2025, segundo um relato da palestra da CCP na Fanfest 2025 publicado pelo The Nosy Gamer. Um projeto arquivado não entrega novas versões, então o que é construído sobre ele também para de avançar.

Esse mesmo relato cobre uma migração que a CCP já concluiu na camada de motor, e vale separá-la da notícia desta semana. CARBON é o motor compartilhado pelos jogos da CCP. Ele saiu do Stackless Python 2.7 para o Stackless Python 3.8.1 em novembro de 2023. Depois passou para o Python 3.12 padrão, entregue primeiro no EVE Frontier em junho de 2024. O The Nosy Gamer relata que a CCP mediu uma melhora média de 20% no desempenho do motor. O relato cita também um segundo benefício, mais silencioso. O Python 3.12 traz o tracemalloc, uma ferramenta embutida de rastreamento de memória, e ela achou vazamentos melhor do que as ferramentas internas da CCP. O The Nosy Gamer aponta ainda um motivo de pessoal bem direto para a mudança: os programadores novos que chegam à CCP não têm experiência com Python 2.7.

Quando	O que mudou
2007	EVE passa para Stackless Python 2.5
2010	EVE passa para Stackless Python 2.7
Nov. 2023	Motor CARBON alcança Stackless Python 3.8.1
Jun. 2024	CARBON alcança Python 3.12, entregue no EVE Frontier
Fev. 2025	Stackless Python arquivado, somente leitura
Jul. 2026	Migração do EVE testada no Singularity, o servidor de teste
25 ago. 2026	Etapa um entra no ar no Tranquility, o servidor de produção

O que os jogadores ganham agora

Nada, e a CCP diz isso diretamente. Perguntada sobre o que muda no curto prazo para os jogadores, a publicação responde: «No curto prazo, nada, e isso é proposital». O retorno prometido vem depois, e está dito em palavras simples: correções de bugs mais rápidas, ferramentas melhores, espaço para novos recursos e um jogo mais rápido com o tempo.

O que isso significa para desenvolvedores

O número de 95,9% é o que se deve tomar emprestado. A CCP não acompanha «percentual migrado». Ela acompanha o percentual que é analisado nas duas versões ao mesmo tempo, e essa é uma medição que você pode rodar hoje na integração contínua. Compile todo arquivo com o interpretador de destino, conte as falhas, e você tem um gráfico de queima em vez de uma estimativa vaga. Isso transforma uma migração assustadora numa migração contável.

Note qual balde a CCP trata como o trabalho de verdade. As 3.300 linhas não analisáveis são ruidosas e finitas. As 20.000 linhas que apenas se comportam de forma diferente são o risco. Divisão inteira, ordem de dicionários e diferenças entre string e bytes produzem respostas erradas em vez de erros. Se você planeja uma mudança parecida, invista em testes que verificam valores, não em testes que só verificam que nada foi lançado.

A estratégia de rodar nas duas versões é a parte que a maioria das equipes pula e não deveria pular. Tornar o código válido nas duas versões antes de trocar o interpretador significa que toda mudança passa pelo processo normal de entrega, sobre o runtime antigo, sem um dia de virada brusca. É mais lento no papel e bem mais seguro na prática, sobretudo para um serviço que não pode cair.

Por fim, trate a saúde do upstream do seu runtime como uma dependência real. A restrição da CCP não era o Python 2, era o Stackless, um fork que agora está arquivado. Um fork que hoje resolve um problema com elegância se torna amanhã o teto da sua plataforma. Verifique então o que os seus forks críticos entregaram por último.