O que é EVE Online e a migração para Python 3
O EVE Online é um jogo online lançado em 2003. Em uma atualização publicada em 25 de agosto de 2026, a equipe do jogo explicou que uma grande parte do funcionamento de New Éden depende de Python e que a migração para Python 3 finalmente começou.
O código nasceu sobre o Stackless Python. A equipe relembra atualizações para o Stackless Python 2.5 em 2007 e para o Stackless Python 2.7 em 2010. Desde então, o jogo ficou por 16 anos na mesma versão principal da linguagem.
A mudança acontece porque Python 2 chegou ao fim oficial de vida em 2020. Bibliotecas, depuradores e profilers atuais estão concentrados em Python 3. Para o jogador, a meta inicial é curiosa: a atualização deve ser praticamente invisível, com eventuais melhorias de fluidez ao longo do tempo.
O anúncio não promete uma troca instantânea nem um ganho de desempenho garantido em todas as situações. A primeira etapa prepara o código e reduz riscos enquanto o jogo continua funcionando.
Como funciona
A migração foi planejada em camadas. Primeiro, o código precisa ficar compatível com Python 3 sem deixar de rodar em Python 2.7. Para isso, a equipe usa o Python-Future, que aproveita a mesma família de ferramentas de reescrita associada ao 2to3.
Depois da conversão mecânica, começa a parte mais difícil: encontrar trechos que compilam nas duas versões, mas produzem resultados diferentes. Divisão, strings, inteiros e algumas regras do modelo de classes podem alterar o comportamento sem provocar um erro de sintaxe.
O time mede o avanço compilando aproximadamente 20 mil arquivos Python em um interpretador Python 2.7 real e em um interpretador Python 3 real. Essa verificação separa o que é incompatibilidade de sintaxe do que exige leitura, testes e decisão humana.
python2 arquivo.py; python3 arquivo.py; compare também os testes e os resultados produzidosO exemplo acima é um modelo de validação para projetos legados, não um comando para acessar o código do EVE Online. A ideia é executar a mesma suite em dois ambientes e investigar qualquer diferença antes de trocar o interpretador padrão.
Principais recursos da estratégia
O primeiro recurso é a compatibilidade progressiva. Em vez de tentar converter milhões de linhas de uma vez, a equipe deixa o código pronto para as duas versões e mantém o serviço ativo durante o trabalho.
O segundo é a medição automatizada. A compilação dos arquivos mostra exatamente quais construções antigas ainda impedem Python 3 de interpretar o código. Segundo o anúncio, 95,9% dos arquivos já compilavam nas duas versões no primeiro levantamento.
O terceiro é o uso de testes em ambientes próximos da produção. Os primeiros passos foram avaliados no servidor de testes Singularity e depois começaram a ser implantados no Tranquility, onde os jogadores realmente estão.
- Ferramentas de reescrita: removem parte do trabalho repetitivo e deixam os padrões antigos visíveis.
- Compilação dupla: captura incompatibilidades de sintaxe com uma regra objetiva.
- Testes de comportamento: procuram resultados diferentes mesmo quando o programa inicia normalmente.
- Implantação gradual: reduz o risco de uma mudança quebrar o jogo inteiro.
A estratégia também prepara partes específicas do produto. A equipe citou o backend de missões de agentes como uma área que está sendo preparada para Python 3, sem que o jogador deva perceber uma mudança imediata.
Como começar uma migração parecida
O caso do EVE Online é enorme, mas o método pode ser adaptado para um serviço menor. Comece inventariando versões de Python, bibliotecas, scripts de inicialização, formatos de dados e testes. Sem esse mapa, é fácil corrigir a sintaxe e deixar um problema escondido em produção.
Em um projeto próprio, use uma cópia controlada do código e uma ferramenta de compatibilidade. O Python-Future oferece o comando futurize para aplicar transformações conhecidas, mas cada alteração ainda precisa de revisão.
Python -m pip install future; futurize -w -n exemplo.py; python3 -m compileall src/; python3 -m unittest discoverSe o sistema ainda precisa suportar Python 2, rode os testes nas duas versões. Quando o suporte antigo não for mais necessário, retire a compatibilidade em uma mudança separada e documentada. Não misture limpeza ampla, atualização de dependências e troca do interpretador no mesmo passo sem uma boa razão.
Faça uma lista de diferenças semânticas para revisar manualmente. Divisão de inteiros, leitura de bytes, tratamento de texto, ordenação e exceções são bons pontos de partida em uma base antiga.
Não execute a conversão diretamente na única cópia do projeto. Mantenha controle de versão, backup dos dados e uma forma simples de voltar ao interpretador anterior.
Exemplo prático
Considere um módulo antigo que calcula uma média. Em Python 2, a expressão 1 / 2 produz 0 quando os dois operandos são inteiros. Em Python 3, a mesma expressão produz 0.5. Um código que compila pode, portanto, tomar decisões diferentes após a migração.
media = total / quantidade; assert (1 / 2) == 0.5O teste acima documenta a intenção de usar divisão real em Python 3. Em uma base que ainda precisa funcionar em Python 2, a equipe pode usar uma estratégia de compatibilidade, converter os valores para ponto flutuante ou ajustar o código de acordo com a regra de negócio.
O passo seguinte é testar dados representativos. Para um sistema de jogo, isso significa verificar inventário, habilidades, carteira, missões e outros estados persistidos. Para um SaaS, podem ser pedidos antigos, relatórios, filas e integrações externas.
Por fim, compare os resultados dos dois ambientes com tolerância definida para números e com igualdade exata para dados que não podem mudar. O objetivo não é apenas fazer o processo terminar, mas provar que a mudança preservou o significado do programa.
Comparação com alternativas
Uma migração gradual não é a única escolha. Um time pode congelar o sistema antigo, reescrever tudo em uma linguagem diferente ou fazer uma troca direta para Python 3. Cada opção combina risco, custo e velocidade de uma forma diferente.
| Estratégia | Quando faz sentido | Principal risco |
|---|---|---|
| Migração gradual | Serviço ativo, base grande e dados importantes | O período de compatibilidade fica longo |
| Reescrita total | Domínio pequeno e requisitos bem conhecidos | Perder regras que só existiam no código antigo |
| Congelar Python 2 | Aplicação isolada e sem evolução relevante | Dependências e ferramentas continuam envelhecendo |
| Trocar de linguagem | Há uma necessidade clara de outro ecossistema | O custo de reimplementar comportamento e operação |
Para o EVE Online, uma reescrita total seria especialmente arriscada porque o jogo reúne uma base enorme, serviços em funcionamento contínuo e mais de duas décadas de dados de jogadores. A migração em etapas preserva conhecimento e permite medir o avanço.
Para uma aplicação pequena, a decisão pode ser diferente. Se houver poucos usuários, poucos dados e testes fortes, uma reescrita curta talvez seja mais simples do que manter duas versões de Python durante meses.
O ponto forte da estratégia adotada pelo EVE é separar o trabalho mecânico da validação de comportamento. Essa separação ajuda a descobrir cedo o que uma ferramenta pode automatizar e o que ainda depende de quem conhece o sistema.
Pontos positivos e limitações
O maior benefício é recuperar acesso ao ecossistema moderno do Python. Bibliotecas, ferramentas de depuração e profilers atuais podem tornar a manutenção mais produtiva e abrir espaço para otimizações futuras.
Também existe um ganho de sustentabilidade. Uma base de código que novos desenvolvedores conseguem entender e testar tem mais chance de receber correções e recursos sem depender apenas de especialistas em versões antigas.
A limitação é o tamanho do trabalho. O anúncio informa cerca de 2,4 milhões de linhas de Python, aproximadamente 20 mil arquivos e cerca de 20 mil linhas que compilam nas duas versões, mas podem se comportar de forma diferente. Automação reduz o esforço, mas não elimina a análise.
Outra limitação é que a primeira etapa pode não trazer uma mudança visível. Para o usuário, o sucesso é não perceber falhas. O benefício de desempenho é uma possibilidade para o futuro, não uma promessa de que toda ação ficará mais rápida imediatamente.
Compilar sem erro não prova que o sistema continua correto. Testes de integração, dados antigos e observação em ambiente controlado continuam indispensáveis.
Casos de uso reais
Para uma equipe que mantém um jogo online, o caso mostra como modernizar o runtime sem interromper uma comunidade inteira. A prioridade é proteger estado persistido, disponibilidade e compatibilidade entre servidores.
Para uma empresa com um SaaS antigo, a mesma abordagem ajuda a separar a atualização da linguagem da troca de bibliotecas. O time pode medir cada etapa e manter um caminho de rollback enquanto aprende sobre os pontos frágeis.
Para quem mantém pipelines de dados, comparar Python 2 e Python 3 é uma forma de detectar mudanças em divisão, strings, bytes e ordenação antes que relatórios ou cargas sejam alterados silenciosamente.
Para estudantes e desenvolvedores que trabalham com código legado, o EVE Online oferece um estudo de caso concreto: ferramentas automáticas cuidam da parte repetitiva, mas testes e conhecimento do domínio protegem o comportamento real.
Dicas e boas práticas
Uma migração segura começa com observabilidade. Antes de trocar a versão, registre métricas, erros, tempos de resposta e resultados importantes para que uma regressão não dependa apenas de percepção.
Também vale transformar diferenças conhecidas em testes pequenos. Um teste de divisão, de conversão de texto ou de leitura de bytes pode evitar que uma regra importante fique escondida em uma função muito maior.
Por último, mantenha a comunicação clara. Em sistemas com usuários, explique o que está mudando, o que não deve mudar e como reportar um comportamento estranho. No EVE Online, a equipe pediu que os jogadores continuem enviando relatos de bugs durante os testes.
Comece por uma métrica de negócio ou de operação que realmente importa. Uma lista de arquivos convertidos é útil, mas não substitui um indicador de comportamento correto.
Separe testes de compilação de testes semânticos. O primeiro encontra código que Python 3 não aceita; o segundo encontra código que Python 3 aceita, mas executa de outra maneira.
Não trate a ferramenta de reescrita como uma aprovação automática. Revise cada área que manipula dinheiro, permissões, datas, texto, arquivos ou dados persistidos.
Faça a implantação em grupos pequenos e defina de antemão qual sinal fará o time pausar ou reverter a etapa.
Vale a pena?
Para o EVE Online, a migração faz sentido porque Python 2 limita o acesso a ferramentas modernas e torna cada mudança futura mais difícil. A equipe escolheu uma rota longa para proteger um sistema grande, ativo e cheio de dados históricos.
Para quem mantém uma aplicação menor, a resposta depende do custo de continuar no legado. Se dependências antigas já bloqueiam correções ou contratação, preparar uma migração pode ser melhor do que acumular mais dívida técnica.
Não espere um recurso visual novo apenas porque o interpretador mudou. O resultado mais valioso é uma base mais sustentável, com espaço para correções, novas funcionalidades e possíveis melhorias de desempenho ao longo do tempo.
O próximo passo é escolher um módulo pequeno, executar a suite em Python 2 e Python 3, registrar as diferenças e corrigir uma categoria por vez. Modernizar código legado fica menos assustador quando o progresso é mensurável.