EVE Online begins moving 2.4 million lines of Python 2 to Python 3

CCP Games began migrating EVE Online from Python 2 to Python 3 on 25 August 2026, according to a developer post on the game's own site. The interesting part for anyone maintaining old code is the scale and the method: 2.4 million lines across roughly 20,000 files, moved while the game stays online.

EVE has run on Stackless Python 2.7 since 2010. Stackless Python is a modified version of Python built for very high concurrency. CCP's post credits its "lightweight 'tasklets'" with letting "a single server node juggle thousands of pilots at once." Tasklets are tiny units of work that a program can pause and resume cheaply, so one machine can track many players without one thread each.

What has already been fixed, and what has not

The numbers in CCP's post are the useful part. The company says 95.9% of the codebase already parses under both Python 2 and Python 3. Parsing means the interpreter can read the file at all, before running a line of it.

That leaves two separate problems. About 3,300 lines still fail to parse under Python 3 and must be rewritten. A larger set, roughly 20,000 lines, parses fine but behaves differently between the two versions. The second group is the harder one, because nothing crashes to tell you where it is.

CCP is doing this in stages. Stage one, now running, keeps the game on Python 2.7 while rewriting code so it is valid under both. Stage two, still to come, deals with the lines that behave differently. The post says some stages use tools the wider Python community already built, such as Futurize, while others target features unique to EVE.

Why Stackless Python is a dead end

Staying put was not really an option. The Stackless project was archived to read-only status in February 2025, according to a write-up of CCP's 2025 Fanfest talk by The Nosy Gamer. An archived project ships no further releases, so anything built on it stops moving too.

That same report covers a migration CCP already finished on its engine layer, which is worth separating from this week's news. CARBON is the engine shared across CCP's games. It went from Stackless Python 2.7 to Stackless Python 3.8.1 in November 2023. It then moved to standard Python 3.12, which first shipped in EVE Frontier in June 2024. The Nosy Gamer reports CCP measured an average 20% engine performance improvement. It cites a second, quieter benefit too. Python 3.12 ships tracemalloc, a built-in memory-tracking tool, and it found leaks better than CCP's in-house tooling. The Nosy Gamer also names a blunt staffing reason for the move, which is that new programmers arriving at CCP do not have Python 2.7 experience.

When	What moved
2007	EVE moves to Stackless Python 2.5
2010	EVE moves to Stackless Python 2.7
Nov 2023	CARBON engine reaches Stackless Python 3.8.1
Jun 2024	CARBON reaches Python 3.12, shipping in EVE Frontier
Feb 2025	Stackless Python archived, read-only
Jul 2026	EVE's migration tested on Singularity, the test server
25 Aug 2026	Stage one goes live on Tranquility, the live server

What players get right now

Nothing, and CCP says so directly. Asked what changes for players in the short term, the post answers: "In the short term, nothing, and that is by design." The promised payoff is later, and stated in plain terms: faster bug fixes, better tools, room for new features, and a faster game over time.

What this means for developers

The 95.9% figure is the number to steal. CCP is not tracking "percent migrated." It is tracking the percent that parses under both versions at once, and that is a measurement you can run in continuous integration today. Compile every file under the target interpreter, count the failures, and you have a burn-down chart instead of a vague estimate. That reframes a scary migration as a countable one.

Note which bucket CCP treats as the real work. The 3,300 unparseable lines are loud and finite. The 20,000 lines that merely behave differently are the risk, because integer division, dictionary ordering, and string-versus-bytes differences produce wrong answers rather than errors. If you are planning a similar move, invest in tests that assert values, not in tests that only assert nothing threw.

The dual-run strategy is the part most teams skip and should not. Making code valid in both versions before switching interpreters means every change ships through the normal release process, on the old runtime, with no big-bang cutover day. It is slower on paper and much safer in practice, especially for a service that cannot go down.

Finally, treat your runtime's upstream health as a real dependency. CCP's constraint was not Python 2, it was Stackless, a fork that is now archived. A fork that solves a problem beautifully today becomes the ceiling on your platform tomorrow, so check what your critical forks have shipped lately.