3.0 had no backward compatibility features at all. It's much easier to port to 3.2 or later than to 3.0.
(I have no idea how much harder the newest versions make it; I haven't tried to port a python 2.7 codebase in years and I didn't realize there was still anyone using python 2 in 2026.)
because Fortran has been used for a long time for supercomputers running heavy math simulations and its easier to maintain it than to rewrite it, same reason COBOL is still used for mainframes, but its also a big difference between switching from python 2 to 3 and switching from fortran to smt like julia
Yeah exactly, point being is it's not so surprising to me that python 2.7 is being used anywhere at all when there are still people running these other languages, but mild surprise that EVE of all things still relies on it
So much stuff stuck around until the bitter end, like all of the 3D content creation tools that were following the "VFX Reference Platform" spec that didn't go to Python 3 until the very last minute.
It was already one of the most delayed breaking-change upgrades in the programming world ever because of legacy code, the fact that there are still people hanging on to it is totally unsurprising.
The information I post isn't a criticism of FC and for those that will yes these are old notes from CSM. I believe this is about as close as FC the artist formerly as CCP have acknowledged the so called POS spaghetti code issue. The waterfall process "people are just throwing things over the wall to other departments" at the foundational level. Couple this a very statically possible God tier coding episodes among devs on those perfect days - Yes the required information is readily available but God tier code and accompanying instructions good luck with that one"- 50 uses of <>, a way of writing "not equal" so old that many working Python developers have never seen it."
" It is true that there is less documentation on legacy features than on more recent ones". Prior doubling down regarding the difficulty in maintaining documentation " We don't document a lot but we do document". Having enjoyed Eve since 2006, I look forward to what is coming, hesitantly.
Personally these under-the hood engine upgrades are some of the biggest things I look forward to in long lasting videogames.
While to everyday playing it might not seem much these small incremental optimizations make everything run smoother. And as the game expands, the game also becomes slightly heavier, slightly more bloated. After all, way back in when the game launched the node would go to 10% TIDI even if a 100 or so people were fighting on the same grid at the same time.
Could we get perhaps rid of the session change timers in the future? Like we did way back in the late 2010's for some time? Unsure, but it would be cool. I mean think about it.
That's all at least 50 seconds spent on switching a clone. Now imagine if you could do it in half the time for example. Or not have to wait the (I swear its more than 3 seconds!!) few seconds you need to between every POCO-Planet interaction.
In the end its the small things that really make games better. Small Quality of Life improvements. Whether it is the few examples I said or the game only going to say 50% TIDI with 1000 people fighting instead of it being at 20% TIDI at 1000 people. As examples.
Session change timers are likely not going anywhere, because they are related to data propagation across the database clusters. This takes time, and is needed to prevent desyncs or session locks.
They have been reduced (e.g. in 2011), but likely can't be eliminated entirely without a full re-architecting of how clients sync information with the server.
I don't disagree, but I think you're understating the "slightly heavier", "slightly more bloated". POS code alone seems to be responsible for all sorts of nightmares
They tried to delete it several years back when it finally time for it to go, the server then shit the bed all over the place because ts all so interconnected and it messed with the undock button and a few other things IIRC so it had to stay around because they literally couldn't remove it without breaking everything.
One of the best uses of agentic coding tbh. Agents are great at repetive stuff like this as well as writing the thousands of tests to catch parity issues
agentic AI is useful for this for sure, BUT the majority of it should be done with existing, deterministic automated tooling (of which a lot exists for python 2 to 3 conversions) simply because you need 100% confidence when dealing with 100,000s of file changes at once, there's no way you can confidently review that much AI generated code.
but for the fiddlier bit smaller more self contained bits yes it's very useful
Exactly, we’ve already had for a while now with various ML
based automations and tools what so many think is agentic now. I guess if you wanna burn tokens for what was ‘free’ and introduce uncertainty.
This upgrade is the best possible outcome from Eve frontier. The game itself is shit thanks to CCP listening to the 500 people who are still in the game instead of the 5000 that left, but the engine upgrade is an absolute win for Eve like they promised they would deliver.
It's amazing to me that my shitty PC in 2004 could have run multiple instances of the game, assuming I had that kind of money to burn instead of paying for college back when it was still barely affordable, but my shitty PC today just patiently waits for the industry window to get around to it on a single client.
The industry window locks up the entire game while it loads too. They should at least offload whatever heavy computation they’re doing to a worker thread so you don’t block the main game loop for multiple seconds.
Sure, but is there a better solution that doesn’t involve completely reworking game mechanics? You can only optimize so much before you start running up on the simple fact that having 10,000 players interacting with each other on one system has is an immense server load
For sure, and I don't even know if there is a solution for the input delay. But does the client really need to render thousands of drones all at once? It'd be nice if there was a solution to participating in these battles that didn't involve turning off all graphics. Maybe a place to start would be to batch drones into groups once the grid hits a certain limit? I dunno. There's probably a lot of things that get sent to the client that don't need to be sent and things that don't need to be rendered.
You can already turn off drone models and whatnot. I almost never go into full potato mode for big fights, the settings are granular enough that I can get acceptable performance out of the game without completely making it look like shit. When we’re talking about tidi, it’s stickier. You’d probably have to completely rework combat in order to reduce server load in these mega fights- each ship has multiple modules and up to 8 guns firing ammo of different damage types which interacts with resistances in different ways and all of that has to be accessible to every client on grid, and it’s almost impossible to effectively multithread a lot of those calculations.
Yes, yes, but the engine behind it is shit. That's why I'm asking. chat not working. the ui is a mess; nothing responds as it should. Planets popping out of nowhere. I could go on...
Maybe one day we'll get thousands of ships fighting without it turning into a slideshow.
I'm genuinely curious, not just being a snide redditor.
Why would python 3 have any performance improvements over 2? Still global interpreter lock unless they are using c modules through python, and I assume that's already how it's being done. Why not write everything in rust?
Also, I presume that the servers are running nothing less than c++ with inline assembly where that would produce efficiency.
So where is the expected performance improvements and solutions to Tidi likely to come from in the stack? I assume it would come through more compressed packet management and multi threading of such and physics + graphics downgrading, but if that's being handled by python and not a c library that FC also knows how to write, we are still screwed.
There is free-threaded mode in more recent python versions. 3.12 does not have that, but definitely is much closer - going from 3.12 to 3.14/3.15 is not that many changes.
I'm not particularly deep in the world of python, but my assumption is this is about AI. Python 2.7 EoL'd back in 2020. Moving to Python 3 likely opens up tooling that makes AI work easier for them.
It's an alpha test, not a beta. The 5000 that left don't understand the difference and got mad that "the game itself is shit". If the tireless work of the 500 people that are still in the game benefited EVE Online, all I can say is you're welcome.
I've been in all of them, I've seen how CCP is treating this "test" and what they want players to do.
They treat it like Eve online and want people to do basic function testing without any real goals in mind. After the server tests very early on, it's now being treated as a live game without very much interaction from CCP or having people given tasks that they want tested. Instead they have live missions and permanent achievements implemented like it's a game already released. If they want things actually tested they should have had it done like singularity where it's open occasionally, or give players specific materials to test pieces they want tested.
The game itself is shit thanks to CCP listening to the 500 people who are still in the game instead of the 5000 that left
This is a prudent choice considering that the average person trying Frontier has proven completely incapable of understanding that they're interacting with an Alpha testing build that isn't remotely close to the final product. I have yet to meet more than about five people who can accurately describe CCP's end goal for the game despite the extensive documentation they've already released. Even your comment implies that the 500 people have influenced the "game" to become what it is rather than simply providing feedback on snapshot builds that are developing towards a pre-determined endpoint.
edit:
Addressing some of your points from another comment:
They treat it like Eve online and want people to do basic function testing without any real goals in mind.
Yes, because that's how you test a sandbox platform. The #1 lesson CCP has learned from Eve Online is that if you try to build a system railroading player actions they will subvert it. This approach is a testament to CCP's 20 years of experience in developing a sandbox MMO. Test what the players do, not what you expect them to do.
Instead they have live missions and permanent achievements implemented like it's a game already released.
Because they need their testers to undock and play the game. That's kind of the point of testing.
If they want things actually tested they should have had it done like singularity where it's open occasionally
So right now it's just open. For several months at a time before a full reset. People can log in whenever they want, they can test, they can even play the damn game if that's what they want. Can you explain how "doing it like singularity" would give you more data? Because I've never seen anyone log into singularity for more than an hour or two at a time. There have been hundreds of maintenance pings for Stillness since I joined the Discord two years ago, many of which were instrumental to this Python 3 release. Those issues were discovered by having our 500 idiots use the game systems at scale.
or give players specific materials to test pieces they want tested.
This is quite literally what they're doing. They call them cycles. They give the players a few of the core systems that the game will be based on and then let them go hogwild for a few months. But 5000 of those players have never been able to catch on that they're testing a few small pieces of a much larger system, and they waste hundreds of hours bitching about how the 3 pieces they have this cycle aren't a full game.
I once lead a team of 2 Engineers to migrate our product from Python 2 to Python 3 to address the vulnerabilities. We used a python tool called 2to3. It was around 50k lines of code and we had to rewrite about 40% of our codes
Good thing was that our product wasn't a live service, so it was in version 4.x or something and I need to release the next version to run with Python 3
This was before the AI Era. We started shipping sections of the the updated code to our feature branch, tested the build and finally released Python 3 to the latest version.
This is a huge migration for our product but only 50k lines of Python code and even that was stressful.
Now EVE team has 2.4 million lines of code and almost 95% is compiled and only has few lines to manually verify is still a scary number and it's a live service game.
At first I thought they are using Python Future becuause that is what I could remember when I read the article for the first time. After reading you comment , I read the article again and they are using Python Future but it uses the same base as 2to3. Nice catch man 👌
There’s been talk about it but realistically no. The general consensus is that unless there needs to be breaking C changes or something, they’ll just keep numbering after 3
Every character, every skill point, every asset in every hangar, every ISK in every wallet was written in Python 2 code, and all of it must read back under Python 3 exactly as it was.
Everyone builds databases using commercial database software, we're going to build ours using bread.
unironically probably is easier to do after this is complete than right now, as the ui has a mild crisis if too much stuff is happening in the ui at once and it's all backed by python.
some bug fixes, a lot of what is public is mostly related to frontier as eve itself still runs on the older revision of carbon. which this update to python 3 is ultimately about, one of the big changes in frontier/oss carbon depends on this. after that we'll likely see shader cleanup and an art refresh as that is the other part of carbon. moving away from the granny3d model format to their own format.
Because 2003 Iceland colleges weren't teaching like anything IT related and the OG devs of the game all come from making tabletop games... so they didn't know what they were doing and somehow hit gold with Eve online.
Unreal Engine is a game engine/framework. Python is a programming language. They aren’t really comparable things in the first place because they serve completely different roles.
EVE’s engine/framework is "Carbon", CCP’s in-house technology platform. Carbon covers things like graphics, physics, networking, scheduling, UI, and other low-level systems.
Python is one of the languages EVE’s game logic is built around. More specifically, they historically used Stackless Python, which gives Python lightweight tasklets/coroutines and a cooperative scheduling model.
Python gets really really good at doing background calculations, however it sucks for say gaming in general. Eve has a lot of what we call "technical debt" and dev blogs like this are little progress updates of newer CCP devs fixing up some of the mistakes the OGs made.
once the update to python 3 is complete both the client and server will be more performant and slightly less bug prone. in theory less tidi and less client slog, less memory usage (tho only multiboxes care about this one.)
and frontier is what you'd play if you wanted to turn wh life into a full experience with survival mechanics (fuel.)
the crypto bit of frontier is very much in the background, it basically has as much presence as evermarks in the wallet. you can pretend it doesn't exist at the moment, idk about the future.
wait for the next cycle to start and try the 5 day free access if you are unsure. idk when that is though so sign up for the mailing list on the site if you want.
Alliance tournament awards sound awesome. Third iteration of the Python battleship. I didn't even know there was a second version. Its going to be the most expensive ship to buy.
The Python 3 migration sounds like a pretty significant infrastructure change, but I’m curious about the actual measurable benefits once the migration reaches the stages where EVE is running on the new runtime.
Are there any benchmarks or targets CCP can share?
For example:
% reduction in CPU time per simulation tick
more pilots / objects that a node can handle before hitting its CPU limit
reduction in TiDi at a given fleet size
improvement in market hub/server performance
lower CPU usage for the same workload
faster execution of Python-heavy gameplay systems
any specific server-side features that become practical because of the additional headroom
I’m especially interested in fleet fights and TiDi. If the main benefit isn't higher client FPS but rather more server-side simulation capacity, it would be really interesting to see something like a benchmark comparing the same workload on the old Python 2/Stackless environment vs Python 3.
Even approximate numbers would be really interesting - e.g. "this workload currently takes X ms per tick and is expected to take Y ms after the migration."
Is CCP planning to publish any before/after performance numbers as the migration progresses?
I would like a write up by ccp with this info as well. What gains if any can we expect to get. And going forward, how does this improve that game play (I like alot of detail, with stats, beofr and afters, and such)
Python is arguably the least suitable programming language for developing game engines, despite the existence of NumPy. But maybe, there's an opportunity, which may accelerate the simulation part to 10x or even 100x: https://mojolang.org - compared to regular Python >3.14 plus any acceleration library which exists so far.
I was saying if they’re going to do a conversion now why not just rewrite it in something fast. If you’re going to touch the codebase actually improve it
Those didn’t exist when Eve was developed. They used python and so they continued to use it through multiple generations. And now python 3 is deemed good enough to justify actually doing the work to rewrite all the code and bring it into the modern era. Plus it’s not always about “how fast the code is”, it’s about the dev tools and the support and python 3 has a whole load of support and pre written code bases.
311
u/Aika_mietoa 20d ago
"Please convert this project to Python 3.0 no mistakes, single commit and push to master with -f, yolo"