Wild to see this headline in 2026. The last big Python3 migration I remember is Dropbox in 2019.
Scale-wise, EVE has 2,400 kloc of Python 2.7. That's double Dropbox's desktop client (1000 kloc) and 2-5x more code than the recent Bun rewrite (535 kloc Zig to 1,000 kloc Rust).
Python's dynamic typing makes that harder to wrangle than the static typing in Zig and Rust, especially because Python 2.7 doesn't have any native type annotation support.
Python's modern type annotation system actually got a big boost from the Dropbox migration. Dropbox employed the Mypy core team at that time.
Not that I think it will be a huge help, but you can run mypy against a 2.7 codebase in case anyone reading this has a silent shame they’re inspired to try to upgrade.
The devblog could use a little more explanatory background, I suppose. As I recall, they've decided to become active contributors to python-greenlet (https://github.com/ccpgames/greenlet, forked from the python-greenlet project) so they can continue to use the greenlet pattern without being pinned to an older interpreter version. As I recall, at the time that Stackless was created the CPython interpreter did not expose its internals in such a way that Greenlets could be added as an extension, hence Stackless being a different interpreter. CPython3 resolves these issues so that Greenlets can be added as a native extension.
From the wording I presume it will use standard CPython. They did not mention here any particular minimal target version other than "3", but mentioned speed ups to the language would mean minimum 3.11 (also 3.14 was another bump), because previous versions could be sometimes even slower than 2.7. If they don't have too much C modules they could possibly try out PyPy with even earlier versions. Asyncio with coroutines give CPython a Stackless-Python-like functionality, it was added in CPython 3.4.
https://youtu.be/-x299qHLQs0 is a 45 minute talk explaining how they did this for their EVE Frontier game, with the intention to do the same thing for EVE Online.
I was part of google's migration from 2.7 to 3.6. it was long and tedious, but also a fascinating project. I primarily worked on the type checker (ensuring code type checked under 2.7 was an extraordinarily valuable step on the way to migration) and on automated refactoring tools. the refactoring tools were very specific to the task at hand and were discarded afterwards, but the typechecker continued to be valuable long after the migration was done. I think it is to date the only typechecker that attempted whole-program type inference and analysis of unannotated python code.
pbronez | 10 hours ago
Wild to see this headline in 2026. The last big Python3 migration I remember is Dropbox in 2019.
Scale-wise, EVE has 2,400 kloc of Python 2.7. That's double Dropbox's desktop client (1000 kloc) and 2-5x more code than the recent Bun rewrite (535 kloc Zig to 1,000 kloc Rust).
Python's dynamic typing makes that harder to wrangle than the static typing in Zig and Rust, especially because Python 2.7 doesn't have any native type annotation support.
Python's modern type annotation system actually got a big boost from the Dropbox migration. Dropbox employed the Mypy core team at that time.
tclancy | 9 hours ago
Not that I think it will be a huge help, but you can run mypy against a 2.7 codebase in case anyone reading this has a silent shame they’re inspired to try to upgrade.
ahelwer | 9 hours ago
Heh, OCaml also uses this.
zk | 8 hours ago
So does SQL!
lorddimwit | 7 hours ago
Goes back to Pascal and some dialects of ALGOL, and older BASIC dialects. It was a Whole Thing
WilhelmVonWeiner | 8 hours ago
I see it in Forths a lot. Forth 200x (a standard you should probably ignore fwiw) states:
<> not-equals CORE EXT ( x1 x2 -- flag )
flag is true if and only if x1 is not bit-for-bit the same as x2.
borntyping | 9 hours ago
I've been writing Python for well over 10 years now and never knew it once supported
<>as an alternate form of!=.moreati | 6 hours ago
I came to Python (2.2, IIRC) from Visual Basic, for a long time I didn't realise <> support was unusual.
alper | 8 hours ago
But stockless python does not exist anymore, so what'll they do there?
mysteriouspants | 7 hours ago
The devblog could use a little more explanatory background, I suppose. As I recall, they've decided to become active contributors to python-greenlet (https://github.com/ccpgames/greenlet, forked from the python-greenlet project) so they can continue to use the greenlet pattern without being pinned to an older interpreter version. As I recall, at the time that Stackless was created the CPython interpreter did not expose its internals in such a way that Greenlets could be added as an extension, hence Stackless being a different interpreter. CPython3 resolves these issues so that Greenlets can be added as a native extension.
hawski | 8 hours ago
From the wording I presume it will use standard CPython. They did not mention here any particular minimal target version other than "3", but mentioned speed ups to the language would mean minimum 3.11 (also 3.14 was another bump), because previous versions could be sometimes even slower than 2.7. If they don't have too much C modules they could possibly try out PyPy with even earlier versions. Asyncio with coroutines give CPython a Stackless-Python-like functionality, it was added in CPython 3.4.
simonw | 6 hours ago
https://youtu.be/-x299qHLQs0 is a 45 minute talk explaining how they did this for their EVE Frontier game, with the intention to do the same thing for EVE Online.
Short version: they built https://github.com/carbonengine/scheduler for this.
thomas536 | 8 hours ago
Yes the points seemed quite superficial...
zem | 6 hours ago
I was part of google's migration from 2.7 to 3.6. it was long and tedious, but also a fascinating project. I primarily worked on the type checker (ensuring code type checked under 2.7 was an extraordinarily valuable step on the way to migration) and on automated refactoring tools. the refactoring tools were very specific to the task at hand and were discarded afterwards, but the typechecker continued to be valuable long after the migration was done. I think it is to date the only typechecker that attempted whole-program type inference and analysis of unannotated python code.
plop | 11 hours ago
Oh wow that is quite funny
nelson | 7 hours ago
This is going to be a fascinating project, I hope they keep reporting how it is going. Some big questions for me:
symgryph | 2 hours ago
If ever there was an argument not to use python!
ag | 4 hours ago
Only took 18 years, but better late than never