#564: EVE Online Departs for Python 3

0:00Michael Kennedy:Every ship in EVE Online eventually undocks and leaves the station. This time, it's the whole game. EVE is run on Python 2 since its launch in 2003. All 2.4 million lines of it on a custom stackless interpreter that stopped at Python 3.8. And stackless Python was mothballed last year. Now it's destination Python 3 for EVE Online. The route runs through 6,500 lines of division that decide who wins a fight and 100 gigabytes of pickled Python objects that have to survive the jump intact.

0:34Michael Kennedy:Kristinn Sigurbergsen was on the show 10 years ago, and he's back, this time with Jamie Bannister, who is flying the EVE Online migration right now, and Thomas Darling, who took EVE Frontier through the jump first. In EVE, a destroyed ship is gone for good. There are no do-overs, and the universe has to stay online the entire time. That's a serious migration. This is Talk Python To Me, episode 564, recorded Thursday, September 10th, 2026. Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists.

1:25Michael Kennedy:This is your host, Michael Kennedy. I'm a PSF fellow who's been coding for over 25 years. Let's connect on social media. You'll find me and Talk Python on Mastodon, BlueSky, and X. The social links are all in your show notes. You can find over 10 years of past episodes at talkpython.fm. And if you want to be part of the show, you can join our recording live streams. That's right. We live stream the raw uncut version of each episode on YouTube. Just visit talkpython.fm/youtube to see the schedule of upcoming events.

1:55Michael Kennedy:Be sure to subscribe there and press the bell so you'll get notified anytime we're recording. This episode is sponsored by Sentry's Seer. If you're tired of debugging in the dark, give Seer a try. There are plenty of AI tools that help you write code, but Sentry's Seer is built to help you fix it when it breaks. Visit talkpython.fm/sentry and use the code talkpython26, all one word, no spaces, for $100 in Sentry credits. And it's also brought to you by Talk Python Courses.

2:24Michael Kennedy:Course completion certificates are now live. If you finished a course, there's a certificate waiting for you on your account page right now. Download it as a PDF or add it to your LinkedIn profile with one click under licenses and certifications. Same section as your formal degrees. Visit training.Talk Python.fm slash account to see what you've already earned. Kristinn, Jamie, and Thomas, welcome to Talk Python To Me. Kristinn, welcome back. Jamie Thomas, hello.

2:52Michael Kennedy:Welcome to the show.

2:53Kristinn Þór Sigurbergsson:Hello. Hello, Michael. Hello. Great to be back.

2:56Michael Kennedy:Yeah, yeah. Great to have you all here. So I'm really excited to be talking about EVE Online again. When was it we? I think it was 2016, 17. It was a while ago.

3:07Kristinn Þór Sigurbergsson:I think it was 2016. And I think we did even brought up the discussion point of the Python 3 upgrade. So it's been on the table for a while.

3:18Michael Kennedy:Well, we're here to talk about upgrading EVE Online to Python 3. Well, Virgin, are you going to start at 3.0 and work your way through all of them, or are you going to do a little bit of a skip ahead?

3:29Thomas Dähling:So we are going to Python 3.12. That's what we updated to. We first did a step in between to stackless Python 3.8. But when we did the work, 3.8 was already end of life, so to speak, and stackless Python didn't go any further. So we decided to go to 3.12 and have now worked on our infrastructure pipelines a little bit that any upcoming updates are a lot easier. So we have plans to go to 3.15 later this year, for example.

3:57Michael Kennedy:Oh, fantastic. That's really neat. I'm going to be excited to hear about that. Probably some cool performance benefits there and profiling and other types of benefits that you get from those last few versions there. We're going to dive into why stackless and all that. There's a lot of history here, and it's a really, really big project. Before we get to the project itself and the upgrade and so on, let's just start with a quick introduction for each of you.

4:24Michael Kennedy:I'll let you do that for yourselves. Kristinn, you go first. We'll go around the squares on the screen here.

4:30Kristinn Þór Sigurbergsson:Okay. My name is Kristinn Seupersson. I'm a director of gameplay engineering for eFrontier, which shares the same technology stack as eOnline. I've previously been everything from a game designer to software engineer to technical director of E1 Line and later technical director of platform or SEAR technology segment as well. So I was part of the team that did the migration for 2.5.3 for Frontier and now I'm the primary benefit from it.

5:03Jamie Bannister:So I'm Jamie. I've been an engineer on EVE for about 16 years, mostly on gameplay. But that has let me work across almost all the different aspects of the game, from the front end of the client all the way through to the back. So I've kind of seen all of the guts and the glory inside EVE. So I'm at the moment working on the actual migration project for EVE Online itself, building on kind of what the others have done previously.

5:31Michael Kennedy:Excellent. Thomas?

5:33Thomas Dähling:Yeah, I'm Thomas Delling. I'm a principal programmer on the platform segment for Fenris Creations. And I have been leading the initial Python 3 transition for Carbon, like getting us out of 2.7 onto Python 3.

5:48Michael Kennedy:Amazing. What a big project, y'all. What a big project. I think where we should start is just what is EVE Online? And I have, of course, EVE Frontier pulled up. But tell us, what is EVE Online? Whoever wants to take this one.

6:03Jamie Bannister:So Eve Online, it's an MMORPG in the classic sense. It's been going since 2003. So it's a massively multiplayer online game set in the far future where humanity has gone through the wormhole to a new system and society has kind of collapsed and then rebuilt in a new form. It's a very, what we would call in gaming, an open world sandbox. So we support all sorts of gameplay professions from mining, trading, piracy, a lot of combat. I think the distinctive factor is the game is full, kind of full loss.

6:44Jamie Bannister:If you kill someone's ship, that's a ship removed from the game. There's no kind of getting things back. Nothing lasts forever. So the game is built on creation and destruction.

6:54Michael Kennedy:A big part of it, if I understand it right, is kind of the economy and just the society. Like there's a society that forms from the players.

7:03Jamie Bannister:Yeah, the economy I think, and before I joined to work on the game, I was a big player as well, and the economy was a big part of it for me. It's been used by, or been studied by economists, because it's, if you think, the data that we have on a big, real, on our economy is more accurate and detailed than you can kind of get from studying the real world economies, where you've always got imprecise data. So we have every single transaction. We know everything that's going on.

7:33Jamie Bannister:You see all the money as it moves around the game.

7:36Michael Kennedy:That's super interesting.

7:37Jamie Bannister:Yeah, very, very rich simulation.

7:39Michael Kennedy:What if we lived in a society where there was zero privacy and 100% data sharing? It would be creepy from a human perspective, right? Just like governments and alt-territarism and all that kind of stuff. But from an economics perspective, you have perfect data, right?

7:56Jamie Bannister:Yes, yeah. and it's interesting how real world things have come up in the game like there's no formal mechanic for banks for example but players themselves have built banks they've built uh kind of loan schemes organizations have got their own way of paying their members for turning up to operations so they they have all the equivalent of like we have welfare groups we have um very centralized democratic groups, communist groups, all those kind of different social phenomena have reappeared

8:30Michael Kennedy:in the game kind of organically. So interesting. And many online games are, you go here, you find a server, you join 40 people, and you go have an experience, right? But this is a single, unified, one world that everybody is in. They can all interact, all that kind of stuff, right? Yeah.

8:49Jamie Bannister:So we take place where we call it a single shard. So yeah, like you say, it's one universe. Any two people in the game, if they go to the same place, they will meet and see each other. And so we have, I think our largest kind of player group is about 15,000 characters. And so all of those potentially could get together and go to one place at one time and have a huge fight. I think we have two Guinness World Records for the most,

9:19Michael Kennedy:uh people taking part in a pvp fight wow how do you coordinate that as a as a group you know what i mean like how do you coordinate just the conversations amongst the people without it

9:32Jamie Bannister:just being a cacophony um between in turn ourselves i mean with the players i mean with the players

9:38Michael Kennedy:if there's 1500 people in like uh some sort of action how can you have conversations and communication without it being they built built their own solutions for a lot of this um so they've

9:51Jamie Bannister:replicated a lot of a chain of command that you get from from real kind of real world and some of the bigger groups they have their own it departments uh that take care of of things a lot of groups use uh discord for kind of coordination but they have and various other kind of voice uh systems they have uh what's called an fc which is like a fleet commander so that's the person uh giving the orders and kind of directing the troops. And then it kind of, there's a hierarchy, if you like, of communication that goes down.

10:21Jamie Bannister:So yeah, the bigger groups have built very complex kind of command and control systems with themselves.

10:29Michael Kennedy:I guess that makes sense, but wow. And you think of a real army, if there's a thousand people, they don't all just get onto the same audio channel. They do have certain people who talk to each other and then they give commands down the line. And interesting.

10:42Jamie Bannister:They replicate the processes like scouts filtering information up. They'll have then some people gather that information and feed it into the FC, who makes the calls of where they're going to go, what they kind of do next. Yeah.

10:55Michael Kennedy:Kristinn, Thomas, you guys want to add anything to that overview before we dive in?

11:00Kristinn Þór Sigurbergsson:Yeah, I would say that this doesn't really happen by its own. There are a lot of people that play EVE online that spend an incredible amount of time orchestrating all this. not only just the fights themselves, but the reasons behind the fight, gathering everybody up. So it is really fascinating to see. And to some extent, these people are playing the game, but they're not actually in the game because they are managing the spreadsheets and the communications and all of that. And to some extent in certain circles, like people have put their experience in managing these larger corporations in EVE onto their CV and it has

11:42Michael Kennedy:helped them get a job. That's a level of commitment there. Yeah, I can now function as a full logistics operation person because I've done it for a thousand people in EVE Online.

11:56Thomas Dähling:Very much so. Yeah, very much. Crazy. Thomas? Oh, I've got nothing more to add there. I think they both described it really well. It can sometimes be almost more like a job than a game if you want it to be. You learn a lot of valuable things. You meet a lot of great people that way as well, right? I mean, over the 20 years, so many people that met each other. We even had a wedding at one of our FanFests, I believe.

12:20Michael Kennedy:We've actually had a few, I think. Thomas, you gave a great talk at FanFest about upgrading and inspiring the folks. That video is online. I'll link to it in the show notes. We'll maybe get to that in a little bit later. So that sounds like a really cool gathering. You know, I really, the last couple of years, I've really enjoyed just diving into games. And my daughter is getting older. And one of the things she really likes to do is sit down and play games together.

12:46Michael Kennedy:Not even online, it's too big, but sort of cooperative stuff and just sort of exploring. And I think that there's, well, I know that studies have shown that there's more loneliness. There's fewer third places that people find themselves at and all that. Having something like this where you can gather and be with people and immerse yourself in, I think it's really neat, honestly. As long as you don't take it too far, you know, still go to work and stuff.

13:11Jamie Bannister:Yeah, yeah. I mean, before I joined and as a player, we would organize meetup events at different places around the UK where I was from. And so I got to know a lot of people. I travel to a lot of places just for the purpose of meeting up with other EVE players. So for a lot of people, EVE or a lot of games like this, they can be your primary social connection to a lot of them.

13:38Michael Kennedy:Let me take us back 35 years or something like that to the days of BBSs. Have any of you guys done BBSs? Remember them?

13:49Jamie Bannister:Yeah, I used to play the MUDs back in the day.

13:51Michael Kennedy:Oh, I used to play MUDs as well. Though that's not what I'm thinking of. But actually, MUDs have a really interesting multi-user dungeons. They have some really interesting analogies as well. But I was thinking of Trade Wars. Have any of y'all played Trade Wars from the BBS days? I know of it.

14:07Jamie Bannister:I've never played it.

14:09Michael Kennedy:It's really interesting. It was this multiplayer thing way back in the 90s. And you would dial in and you'd have to take turns because only one phone could be connected to the BBS at the time, at a time. And it was really, it has some real similar vibes. It's, you know, you travel to different planets. There's mining, there's an economy, there's trade. Anyway, I feel like this is like, what if it could be real? Instead of just a little sort of simple game, what if you could make it real with all the nuances and intricacies of reality and multiplayer?

14:39Michael Kennedy:And it's just the realization of what that thing should have become. Yeah.

14:45Jamie Bannister:Because Eve was heavily inspired by a game called Elite, which was one of the very early 3D space games. And that had a big world, a big universe of systems. Trading was a big part of it. And so there's definitely links from there. And also classic role-playing games as well. Our character stats have similar kind of perception, intelligence, charisma sort of stats. Interesting.

15:10Michael Kennedy:Almost a D&D sort of. Very much, yeah.

15:13Jamie Bannister:Yeah, you can tell there were D&D players in the very early EVE designers, for sure.

15:18Michael Kennedy:This portion of Talk Python To Me is brought to you by Sentry and Sear AI. There are plenty of AI tools that help you write code, but Sentry's Seer is built to help you fix it when it breaks. The difference is context. Sear isn't just guessing based on syntax. It's analyzing your actual Sentry data, your stack traces, logs, and failure patterns. Because it has the full context, it can A, spot buggy code in review and help prevent issues before they happen, and B, identify the root cause of production errors.

15:49Michael Kennedy:It can even draft a fix and hand the work off to an agent-like cursor to open a PR for you. Seer turns Sentry into a complete loop. You have your traces, errors, logs, and replays to see the problem, and now AI to help solve it. Join millions of devs at companies like Claude, Disney+, and even Talk Python, who use Sentry to move faster. Check them out at talkpython.fm/sentry and use code talkpython26, all one word, for $100 in Sentry credits. Thank you to Sentry for supporting Talk Python.

16:20Michael Kennedy:We're going to also talk about this thing called Eve Frontier, which is a little different, but very much inspired, shares a lot of the code base. So give us a quick comparison to Eve Frontier, which I'm sure fewer people know about.

16:33Kristinn Þór Sigurbergsson:Yeah, sure. So what matters for the tech is that we've essentially forked Eve Online, the code base, and are sharing a lot of the underlying tech. We've made a lot of modifications. We haven't been kind of pulling in stuff lately because it's just, it's become too different. Where it differs from EVE Online is maybe if you play EVE Online, you very much come into a society. Part of it is definitely player built, but part of it is also kind of NBC built.

17:05Kristinn Þór Sigurbergsson:The environment is there's a police, there's everything. Whereas in Frontier, you're more coming into like an unbuilt, uninhabited zone and you're the first kind of writers in that universe. And it's up to the players to build that society up and kind of build up all of that infrastructure. It doesn't really differ from even a lot of like the design paradigms. I think both games aim to give players as much player agency as they possibly can. But this also allows us to make like a lot more dramatic changes in the gameplay itself.

17:42Kristinn Þór Sigurbergsson:it's very hard to change the gameplay on evil line for example very drastically because honestly like after 20 years that's the game that people are playing they don't really like they didn't play it for 20 years to change all of it so uh we've been doing that it's more survival survival based it's more like uh like a survival game than it is uh uh not necessarily more than an mmo but it definitely has a lot more survival elements to it uh yeah and the environments are a little bit more kind of claustrophobic and smaller.

18:13Kristinn Þór Sigurbergsson:Obviously, that's very hard in a space game because space is pretty vast.

18:17Michael Kennedy:Yeah, amazing. Okay, really, really neat. Now let's talk about the reason that I reached out to you, which is I saw this article or post from you all that said the move to Python 3 begins. And, you know, credit to you all. This is a really fun article that it's like, it's told as sort of the next phase of a game or something where it's kind of a mission in the game, I guess. But a mission for you all, right?

18:44Jamie Bannister:Yeah, I think that we kind of got a little bit cheeky with the heading because it isn't necessarily the beginning because, like we were saying earlier, Frontier itself is already on Python 3. But this is specifically for EVE Online itself. It's now actively moving to Python 3. And a lot of it is building up on the tech that we've developed ready and kind of start to prove out through Frontier. But yeah, this is kind of our big formal announcement that the legacy of 20 plus years of code, we're now kind of actively working

19:20Michael Kennedy:to migrate. I think we should start maybe with a little bit of the architecture and just a big tech picture of EVE Online. When we spoke, Kristinn, way back in the day, you were doing a bunch of interesting things. I think you must have been the single largest deployment of Python, a Python app on Windows? Is that correct? I would say yes, right? What else would it be? That seems very plausible.

19:44Kristinn Þór Sigurbergsson:I think it was a very kind of like a niche environment. And what I'd often run into is that I would try to take some libraries and try to use them and they just wouldn't work on Windows. Like somebody broke it and nobody cared because they weren't really using it on Windows, except we were. Obviously, like at that time, like 10 years ago, we couldn't really use a lot of, especially native Python libraries. I can't even remember if we had removed- we must have removed.

20:11Kristinn Þór Sigurbergsson:We had our own importer as well, which made it also difficult to use third party libraries. But I think we fixed that.

20:20Thomas Dähling:Yeah, there's a lot of- I mean, it's a very old project. And a lot of the early beginnings in the code base were before a lot of the things in Python actually being standardized to a degree. plus the special circumstances of having a packaged program with its own Python interpreter just makes certain things more interesting. Like, you know, as Kristen alluded to, like you can't just import a random public package because we don't have pip as an example, right?

20:47Thomas Dähling:Or uv these days. But like, there's a lot of interesting problems you need to solve when you have such a large deployment, for sure.

20:53Michael Kennedy:Yeah, there was a lot of custom stuff. When did this first get created? So I know we spoke in 2016, but it's been around for more like 20 years, right? So 2005, 2006? I think it's earlier than that.

21:06Kristinn Þór Sigurbergsson:It's like the game is released that 2003, the development started in 99, I think. They didn't really choose Python. I don't know the exact date of that, but like there was, that is an interesting story as well. Like why they chose Python, which was actually rather new at the time.

21:29Michael Kennedy:Yeah, I was actually wondering about that as well. I'm glad you chose Python. I think it's really cool. And I'm sure you all really enjoy working on it. And this has got to be an exciting project to say. We're moving to 3.15. We can use uv. We can import libraries, like all the exciting stuff. But at the time, it was pretty new. And we said, well, we could run this much faster and easier if we wrote it, I don't know, with C++, Java, C#, something like that, right?

21:57Jamie Bannister:I think a lot of the core libraries, they are in C++, so our physics engine, which we call Destiny, that's all C++. Trinity, our graphics engine, similarly. But yeah, most of our kind of higher level, all the gameplay logic, a lot of the network stack that we have, that's all built, or clustering stack, that's all built in Python.

22:25Kristinn Þór Sigurbergsson:Yeah, probably add to that as well is that like the time when we started or not me, even though I've been here for a very long time, it hasn't been that long. But when they started writing EVE, like that was around the.com era and kind of the older listeners probably remember that era. But the programming resources were scarce and heavily sought after. So very expensive. So part of the reason why they chose Python was to get more junior people and even designers to be able to write sequential code in Python in order to speed up development.

23:04Kristinn Þór Sigurbergsson:It was all about development speed.

23:06Jamie Bannister:Especially in Iceland, right, where you've got a much smaller pool of people to work from.

23:12Michael Kennedy:Honestly, that's kind of a cool success story, right? Like bring more people in to help build the thing that we're building.

23:19Thomas Dähling:Yeah, absolutely. Yeah, absolutely. And as Kristin just said, allowing people to write sequential, simple, straightforward Python code as well, which then led to us discovering stackless Python, integrating that one, and then building an abstraction on top that people don't realize that they are writing code that runs asynchronously. And it enabled us to scale to the degree that we're able to scale with thousands of people being in the same solar system and so on.

23:47Michael Kennedy:Yeah, you needed concurrency before Python was inspired by concurrency. Maybe we should talk a little bit about free-threaded Python later, as well as the possibilities there. But I just want to kind of touch on this historical angle a little bit more. To me, there's two really significant milestones that matured Python. I'm sure there are more, but these are the ones that stand out in my mind. They both are around 2006 or so time frame. So one is Django coming to Python, really making it a first class way to build web apps.

24:21Michael Kennedy:People start building on top of that. That puts a lot of pressure to make Python operate a little bit differently, right? 10 years later, we've got Instagram running the largest Django deployment in the world and doing things like trying to juggle weird memory stuff by turning off the GC, for example, entirely and other things along those lines. The other one around 2006 as well is the invention of NumPy and then later Jupyter and the whole data science stack, which also put really hard computational pressure on Python rather than, say, the parallelism of web apps and so on.

24:56Michael Kennedy:You all were before both of those, right? So it was early, early days.

25:00Jamie Bannister:Yeah. I mean, what we also found was, or what I found in some of work here is the original developers had to invent a lot of things which didn't exist. So like the containerized system, a way to kind of cluster an application across multiple CPUs and notes. There wasn't really a lot of easy off the shelf frameworks for that kind of thing. So they had to roll their own. Even logging and telemetry systems, there weren't great ones of those. So what we found from the early years is we have a lot of in-house tools, which we made or the people at the time made, which are now using the models that you see being replicated by much more popular systems.

25:50Jamie Bannister:So whether it be Redis for a storage system or your containers as well. The way that maybe we can talk about this a bit more in a bit is the way we distribute EVE as an application across about 200 nodes in our server cluster. And each of those has certain jobs to do. And so we have to deploy and configure all of those as one giant cluster. And we have our own coordination tools that have been built over the years. Nowadays, if you were starting this from scratch, you would have so many off-the-shelf solutions that we just didn't have the options for.

26:26Michael Kennedy:Oh, you just set up Kubernetes and then do this auto-scaling thing. And it's, oh, yeah, it's just easy.

26:33Kristinn Þór Sigurbergsson:I would also like to add, I feel like the data scientists kind of grabbing onto Python and I feel like pushing it towards Python 3 because I think without that army going into Python 3, I feel like it mirrors the rationale of why we chose to go into stackless Python. You were giving basically a tool to a bunch of people that aren't really programmers, but they need to write code. So I feel like that is an interesting thing.

27:03Michael Kennedy:Yeah, you know, I've forgotten the 2v3 wars and all that. Now, yeah, it's easy to forget the details of that from, it's been a while now, actually, but you're right. It was the data scientists that were going into Python 3, and the rest of the folks were kind of dragging their feet because they had existing code bases that needed to keep running and keep being migrated, whereas the data science projects are more frequently like, we'll start a new project to answer this question or to study this new bit of data.

27:32Michael Kennedy:So they had many more opportunities to choose the most modern tools. And I think, honestly, we should give the data scientists a little bit more credit of making the two to three change happen. All right, well, let's talk stackless Python because this is one of the foundations that you all had to migrate from. And the journey begins, The move to Python 3 begins article talks about upgrading from 2.5 to 2.7 not too long ago. And then finally up to 3.8.

28:06Michael Kennedy:What is it about Stackless Python? I know it has strong origins with you all because some of the core developers worked on it and refined it there. But this far down the line, I imagine there's a lot of people that don't know what this is.

28:19Thomas Dähling:Yeah, absolutely. Stackless Python itself was a very great solution at the time, right? I mean, it's basically Golang's GoRoutines, but in Python, before things like this co-routine model became so popular as it is in recent years. A big problem that we faced was, on the one hand, that because of the customizations we had to do to the network stack to make all the magic of people writing sequential code, but it does end up not blocking the main process.

28:51Thomas Dähling:That was a big learning curve for a lot of people. And also always something that even the experienced developers tended to forget about in a moment. And they're like, oh, yeah, hang on, there's a DB call. Of course, that we yield. I need to put a lock here or whatever. So the model in itself is great, but it comes with a few learning hurdles, I want to say. And it served us really well. One problem that we had over the years that had become more and more interesting, especially last 15 years, I want to say, is that we relied on a heavily customized version of it. So stackless Python itself is a fork of the CPython interpreter with a lot of changes in the interpreter. And we put some changes on top because doing a real-time game of sorts requires some solutions that go very far down the tech stack to be performant. Like if you want to get certain metrics, if you want to control how memory is allocated and so on and so forth right so all these customizations and also meant that made it very difficult for us to like always go to the next newer version of python as the article current calls out like you know there was some code that was still python 2.5

30:02Thomas Dähling:when we did the native extension porting to python 3 we discovered things from python 2.3 that we were still using that shouldn't have been used but we somehow kept around on our customized version of of Stackless Python.

30:14Michael Kennedy:This portion of Talk Python is brought to you by Talk Python courses. Here's the thing that always bug me. You finish one of our courses, that's hours of video, a pile of code you actually wrote, and real skills you didn't have a month before, and then nothing happens. No paper, no credential, nothing to show for it. So we fixed it. Every Talk Python course now generates a completion certificate automatically. Go to your account page in your dashboard section, scroll down to your completed courses and click certificate.

30:42Michael Kennedy:That's the whole process. Two things you can do with these course completion certificates, download the full PDF, which is handy if your employer reimburses training or gives you credit for finishing it. Or you can make the certificate public and hit share on LinkedIn, which adds it to your LinkedIn profile under licenses and certifications. Not a poster that scrolls away in a day, an actual credential sitting on your profile where your manager and recruiters can see it.

31:07Michael Kennedy:Plus, if you've been taking our courses for a while, you've probably earned several of these without even knowing they existed. Just visit training.Talk Python.fm slash account and collect them. Thanks to all of you who have taken a Talk Python course. It's a great way to support the podcast.

31:24Thomas Dähling:Another aspect certainly is that stack lists had become like a sort of niche project in the ecosystem overall. With Python 3, we have async.io built on the twisted model. And even in the Python 2 world, G event had become a lot more famous than Stackless Python, presumably because you could just import G event in a standard CPython interpreter, while Stackless Python is more complicated to get started with. So-

31:53Michael Kennedy:So Stackless Python is basically its own runtime.

31:56Thomas Dähling:Yeah, it's basically- Yeah. Yeah, very much that. It's like its own Python runtime. You kind of need your own. Like, it has a stackless lib, so to speak, which basically monkey patches similar to what Gvent does all of the threading and socket modules and so on to be able to do them in non-blocking fashion. And yeah, all these things.

32:14Michael Kennedy:So that's really, I mean, that's what made it possible. That's really awesome. One thing, just, I don't know if you all know this, but how is it possible that it says it's forked from CPython on GitHub when CPython itself didn't go to GitHub until like the 20s, you know, 2020, I don't know what it was, but maybe some GitHub magic, I don't know.

32:34Thomas Dähling:Oh, it's git magic. You will find on GitHub there are repositories where there are commits from Abraham Lincoln and various other historical figures because you can just make up all the history, right? Interesting.

32:45Michael Kennedy:Yeah, it is nice, though, actually, that it shows it. If you go to the repo now, it says that it was archived in 2025, which, you know, not every project is meant to last forever. But it made it possible for you. Although I'm sure that you would think, you know, all right. You're like, wouldn't it be cool if we could use, I don't know, libraries like Pydantic or FastAPI or AIO Redis or I don't know, whatever, right? Anything that is new and fancy.

33:13Michael Kennedy:And then you go back and you look and you're like, well, but not here. Not on Stackless, right? Like that was one of the major problems, wasn't it?

33:21Thomas Dähling:Yes, this was a major headache for us. But for every native extension- or not just native extensions-- for every Python package we took on, we had to take a really close look about how can we integrate it in our stack. Again, we didn't have a package manager. We still don't have it, but we're working on it. And that just meant that you would take the zip file from PyPy, for example, extract it into our environment, and then see what happens. If that then happened to be something that had a native extension, well, good luck.

33:51Thomas Dähling:Does this support our minimum spec environment? does this run on all our environments? Does this work with our version of the forked Python interpreter? And we have discovered a few cases where we took on modules that were built for 2.7.18, and they then corrupted memory because in 2.7.6, the memory layout of the PyType object changed, and we didn't have that change. And yeah, things like that. So we had to fight the way forward.

34:20Jamie Bannister:Jamie, you want to jump in? Yeah, no, I was just going to say when it comes to support as well, because we support Mac and we have in the past, but we don't now support Linux as well. So sometimes with a native extension, we've got to figure out does it even support all of our clients? Our servers run on a Windows cluster. Most of our players are running on Windows clients. Mac is also kind of a smaller majority. And like I say, we used to also support Linux.

34:51Jamie Bannister:So keeping all of those in sync as well with all of these extensions has been problematic at times.

34:57Michael Kennedy:Yeah. Sure, that's an understatement. Earlier, when you guys mentioned how you deploy as an app, or.app,.exe, whatever, or to your server clusters, how do you do that? That's honestly one of the biggest challenges of Python that many attempts have been made, but I honestly don't think that there's a good answer, a really foolproof answer yet. And until it's built into CPython itself with a --build flag or something, I think it's going to be 90, 95% solutions.

35:28Michael Kennedy:But you all have something that works. What are you doing?

35:31Thomas Dähling:So effectively, I mean, with Python 3, this all got a lot easier because you can initialize the interpreter a lot more straightforward. But what we have been doing for the last 20 years is effectively we are embedding the Python interpreter in a custom binary that we have, a custom library that we use. And from that moment onwards, we basically just heavily customize what paths are available to the interpreter and what environment variables are considered, all these little things.

36:00Thomas Dähling:And then we package up the remaining things that we need in a way that it fits this layout that we set up in the embedded interpreter. But yeah, it's also more like a 75% solution than a real one because the Python build process in itself requires some system-specific paths. We had to go to great lengths to patch that out. Not necessarily in the best way possible either, but it gets us there.

36:24Michael Kennedy:If you're shipping it, that's off you all. That's pretty impressive.

36:28Kristinn Þór Sigurbergsson:It was kind of like that we have a solution for our players, but also we built a lot of tools for game designers to use and stuff like that. And it's convenient to write them in Python because we can share some of the code base of the actual game, game logic, for example, when we're creating static data. And that has been like a very painful experience of distributing Python, like Python, basically a Python script to developers, because there is really amazing how much people can mess with their environment by just changing the Python path, running the wrong version of Python.

37:04Kristinn Þór Sigurbergsson:It's been a struggle for years, honestly.

37:07Jamie Bannister:Even if we get a new hire, the first few days are often spent setting the machines up. And inevitably, as Windows slightly changes from release to release, it will or won't come with certain things. Sometimes we have to disable the built-in Python that ships with Windows just so that we can use our own specific Python 2.7 versus Python 3. So that's also quite a lot of fun that we have to get started out.

37:36Michael Kennedy:What about things like uv Run or uvx in the future? There's some interesting possibilities there, potentially.

37:44Thomas Dähling:Absolutely. And as I said, we are working on it. We are exploring the angle there. Because it is still a bit of a hassle of getting things into our special environment for the game itself. We have historically had also the issue that we were using a different built environment than the standard Python distributions, right? Partially because there's a lot of code that would need to be migrated. Partially because it works. We don't want to spend resources on that at the moment, partially because, well, especially with Stackless Python, you could only go so far until there's a new compiler version that then breaks some internals, and you would have to do major rewrites.

38:24Thomas Dähling:So these issues have existed, but we want to be able to be in a place where a developer can also just say, "uv install this package into my game environment," then be able to use it. Needs to solve a few things, like if it's a native extension, needs to find the right build environment and so on, which is non-trivial, unfortunately.

38:45Michael Kennedy:What workflows do you think, do you see becoming possible that were much, much harder once you have nice package managers and maybe more reuse, right? For example, you could ship versions of things more easily than, you know, as one monolithic element. Yeah, for sure. I mean, for example,

39:03Thomas Dähling:we recently open-sourced basically the game engine, right? And there is, I can see a world where you can just uv install or pip install these things into your custom interpreter to get going or into your Python interpreter to get going without requiring our custom interpreter. For our internal workflows, I don't think, I mean, sure, the acquisition of an external package will definitely get a lot easier, but many of the other workflows probably won't change that much since we, I was in 2011 or 12 or so, we added an interpreter mode to the game engine itself, so you can can basically start the game engine with a special flag, and then it basically starts the Python REPL, and you get as much of the standard Python interpreter behavior as possible.

39:49Michael Kennedy:That's cool. So you can kind of poke around that in the game memory and values and data structures as you want, right?

39:57Kristinn Þór Sigurbergsson:I guess the director in me doesn't really, it doesn't see it as all negative that there's a bit of a hassle to add a new dependency.

40:07Michael Kennedy:I was thinking about that too, Kristinn. I was. And you can see these headlines of all the supply chain issues and you're like, well, I mean, we should worry about it, but not to the degree that other people with 200 dependencies do, right?

40:20Kristinn Þór Sigurbergsson:Yeah, definitely. And I'm not arguing necessarily for making it hard, but you can see a reality when you have a large development team and people just kind of flippantly add the dependency that causes issue. It's very vulnerable to individual mistakes.

40:38Michael Kennedy:Yeah, and also just duplication of now there's three libraries that kind of handle the same thing, but not entirely.

40:45Kristinn Þór Sigurbergsson:On the flip side, if it's harder to upgrade, you're also less likely to actually upgrade it out of the.

40:53Michael Kennedy:What libraries or tools or experiences did you all see out there and you're like, all right, we have to upgrade. Were there certain packages you're like, oh gosh, we really, really would benefit from using this one or having this feature like the JIT or something in Python that makes such a difference that it's worth all this effort.

41:13Thomas Dähling:So, I mean, Jamie, maybe you can talk about the Python side a little bit, but from the game engine perspective, the main driver for really wanting to get the upgrade project pushed through was the native backline that we worked on in the early 2020s. It has just like Python 2.7 was not a way of silicon to begin with. Then a lot of other changes that had happened, like macOS behaves very different with Unicode than Windows does when it comes to system calls and so on.

41:45Thomas Dähling:Historically, before we had the native MacWords, clientists would go through a translation layer similar to Wine for Linux. So we really pushed for it because we just saw that, okay, if we don't go up to Python 3, we are stuck with having a small team that is dedicated to nothing else but maintaining the Python interpreter. That seemed like it's one possible solution, but not necessarily the best one if you want to just go rapidly than to add new features or iterate on other existing functionality.

42:19Jamie Bannister:I think for me as a gameplay programmer who's mostly using the Python framework that we have, things that we've sorely been lacking for a long time is a good way of type declaration. It's sort of there in Python 2.7 if you're using the right IDE, but it's not consistent. That gets a lot better as you move through the Python 3 versions. Another thing we end up making a lot of is what's effectively a data class, where we just want to kind of define a small packet of data in a particular structure and pass it around and do things.

42:52Jamie Bannister:Having kind of the language support that at a more fundamental level is kind of something I'm really looking forward to getting.

42:59Michael Kennedy:Yeah, that's really neat. And think about such a large code base. Was it 2.4 million lines of code, something like that? That's non-trivial. I mean, that's kind of the scenario that typed Python is perfect for and could have been invented for before AI was a thing, which also helps. But having the ability to use tools like Pyrefly or TY and ask the question in an automated way, is our code still consistent? That's pretty neat, right?

43:24Jamie Bannister:Yeah, I think given the size of our code base and the fact that we have reasonable test coverage, but we don't have complete by any means. So the more we can put in a kind of leverage from the language to help prove correctness and find issues, that's going to lead to a better product and less issues.

43:44Michael Kennedy:Yeah. Last question before we actually get into the details of the migration and how you all did it. What about free-threaded Python? You started with this concept of high concurrence, so much so we need concurrency that we're going to get our own runtime and maintain it. Are you considering free-threaded Python? Is this interesting in any way? Or is it all asyncio driven? What are you considering here?

44:08Thomas Dähling:We are looking at it. I've actually just been to Europe iPhone back in July and attended some of the very interesting presentations on where 3.30 is heading. There is a lot of work ahead of us to adopt it, because there are many places which just implicitly rely on the GIL for synchronization. We will need to identify those. There are some interesting parts where I think we could benefit from it when it comes to our resource loading system, for example.

44:38Thomas Dähling:But yeah, it's on our radar. We are interested. It's not necessarily going to be the biggest performance improvement that we could possibly get, I think. But once it's there, we also have more possibility or more options to explore as well and what we might be able to do different.

44:56Michael Kennedy:Yeah. I imagine that AsyncIO, given how much network, Redis, etc., stuff you do, will give you a pretty mega boost as well as just the performance of CPython has gotten so much better, right?

45:08Thomas Dähling:Yeah, we've gotten, like, what was it, 15% to 20% improvement across the board for most things. Like, there's the one- like, string handling obviously changed. You can't really compare that with Python 2, because now it's all Unicode. That always bears a little bit of overhead compared to operating on bytes directly. But so far, we have been very happy with the performance improvements that have gotten-- that we basically gotten for free, right? On the topic of async I/O, though, unfortunately, we can't really benefit from that because you need to annotate your functions with async and so on.

45:45Thomas Dähling:And with the 2.4 million lines of Python code written without that in mind, it had become quite quickly quite clear that, unfortunately, that one is out of the window for us. Interesting.

45:58Kristinn Þór Sigurbergsson:We did discuss it at the time, whether it was just completely out of scope of everything that we were doing.

46:07Michael Kennedy:You know, one thing in terms of colored functions, that is one thing I just talked to Joe from the Gradient Project about Tone.io, which is a multi-threaded async runtime in Python written in Rust, but implemented in Rust. But it has this way of running without necessarily decorating the thread. Anyway, maybe, I don't know, maybe it's interesting. Who knows?

46:29Thomas Dähling:I attended his talk at EuroPython. Oh, yeah, yeah. And it looked interesting. But on the other hand, we are doing a lot of similar things underneath the hood already. So basically, all of the I/O already happens on multiple worker threads in the background. Interesting. Yeah. Really just that we have- I mean, the main reason why- the main way that we facilitated Stackless back then at the new schedule and what you'll know is that it acts as a synchronization point to get the data from those worker threads into the main thread that's running Python.

47:00Thomas Dähling:And I've looked at Toneio a little bit, but even that is not very straightforward to integrate in our stack, unfortunately. So doing comparisons is a bit difficult.

47:10Michael Kennedy:Yeah, honestly, and the free-threaded stuff, honestly, it scares me. I used to do tons of concurrent programming, threads, events, signal, locks, all that kind of stuff. It's not my code that scares me. It's all the libraries that are written in Python that, like you all said, a lot of people assume the GIL was a thing and how many of those have some little latent race condition that when they figure out what it is they're gonna put locks on it then it'll become a latent lock a deadlock you know what i mean like just having faith that all the foundational stuff has really been through the ringer of pre-threading i don't know scares me i'm optimistic

47:46Thomas Dähling:for it and i want it to exist but it scares me yeah there's a lot of work for sure you know also like the other side that the single threaded use case shall not degrade in performance either you know it's there are many things but that being said like even with the asynchronous programming that we that we use underneath the hood we are already in the world of having to be careful what we put a lock on and whatnot right

48:07Michael Kennedy:for you guys you all are in this world but I think 99% of the Python people don't even think about locks and race conditions you know and that's I think that's where we're going to have to as a community work through the issues to make these dependencies stable

48:24Thomas Dähling:Yeah, absolutely. There is actually-- I think there is a community effort going on, as far as I remember, where- is the URL really rb-free-threaded yet or something? So there's a project where they basically track all of the public libraries in PyPy and how they behave under free-threaded Python already. So we also-- well, I keep an eye on that as well to see where that is happening and where there may be some of our dependencies in there.

48:50Michael Kennedy:There's the compatibility, the free-threading compatibility status checker. It's got the tested in CI, the PyPI release, when it was first supported, the free threading bit. It's very data science heavy though, isn't it?

49:03Thomas Dähling:Yeah, I guess it's once again the data scientists that are leading the way here. I guess they're also mostly benefiting from a free thread in Python, given that they are doing a lot of number crunching.

49:11Michael Kennedy:Right, exactly. Because I think async.io, even though it may not apply to you all, does solve the problem of I got to talk to the database a whole bunch of times concurrently or to microservices concurrently because it's the IO bit, but when you got to do computation, it doesn't help you a bit. So yeah, you're right. I think that's fundamentally why. All right, let's talk the actual migration. So you all started by just making sure, well, first converting everything to run in two and three, right?

49:41Michael Kennedy:Tell us about that.

49:43Jamie Bannister:Yeah. All right, so I'm going to take this. So a lot of the work that kind of came our way was to take our 2.4 million lines of code that we have and bring it forward so that we can eventually end up everything on Python 3. What we found is, like we mentioned earlier on, we still have a lot of code that was technically 2.4, 2.5, or using 2.4 and 2.5 kind of idioms, which are no longer suitable in Python 3. So the very first step that we've taken is what we're calling legacy to 2.7, which is get all of those legacy bits of code up to 2.7 standard, because a lot of those changes then become more forwards compatible into 3.

50:30Jamie Bannister:We've actually already released and deployed the first part of that a few weeks ago. That was around the time that we wrote that blog. And for a lot of that, we use these Futurize scripts, all the fixes from Futurize. And what they do is they take one particular idiom of Python and update it to Python 3. There's a subset of those which you can run whilst still being 2.7 compatible. And so those are the ones that we've done so far.

51:00Michael Kennedy:Yeah, and you just basically got them all moved to a way that theoretically would run on Python 3 because for people who don't know, some of the older ways of working in Python 2 were literally incompatible, like ways of declaring exceptions, handling some of the string stuff.

51:19Jamie Bannister:Yeah, the big one we found a lot of was testing membership in a dictionary. So now you do if X in Y. In the older Pythons, you would do if there was a has key function. That is no longer supported in Pyth 3. But we still have a lot of code, or we did have a lot of code that was using has key. So we had to change all of those to using the in state in operator. So that's the kind of thing that we've kind of done in this first phase. What we found was we were actually 94% of our code was technically Python 3 syntactically valid.

51:58Jamie Bannister:We've now got up to 99.8%. So that's syntactically valid. It doesn't mean it's going to do the right thing when you put it in Python. The classic example is division. Being a game that does a lot of things with a lot of numbers, we have about 6,500 lines that feature a division. some of those are going to break if we just switch to Python 3 without doing anything with them because the way it changes from integer to float division. So that's going to be part of the next phase that we're going to get into.

52:31Michael Kennedy:Yeah, that was one of the main deals. If you have x slash y in Python 2, that would do basically integer division, truncate it. They take the floor of it more or less, right? And then those just become floating point numbers, which that's terrible for like this thing equal, equal that thing and all, it's- And if you're doing a lot of damage calculations,

52:51Jamie Bannister:you've got one ship shooting another ship, that can make a lot of difference if suddenly your damage changes and now I should have won this fight and now I've lost it because the maths is working out differently. So that's gonna be important for us to get right.

53:05Michael Kennedy:Yeah, absolutely. Okay, so what next, what happened after that? You got it working on Python 2, but syntactically Python 3?

53:12Jamie Bannister:Yeah, okay, so the next phase, which we're now in at the moment, is we've forked the Python 2 branch into a Python 3 branch. Immediately, many, many things failed. All of our tests started showing up red and so on. And so what we're calling that is our Python 3 unstable. And so from there, we need to work through, get all of our tests passing, start getting that more stable. At the same time, we've got what we're calling a 2.7 unstable branch, where we're kind of introducing a lot of the shims and the adapters.

53:49Jamie Bannister:So this is where we can have code that's going to maybe fork if 2 do this, if 3 do this. The downside of that is it's going to be a lot slower. So that's more of a compatibility proof versus a releasable version. But that is going to be our middle ground for code that we can then say, we can put this into 2.7 and make it 4.0 compatible, or this is going to be breaking compatible, so we need to put it on the three side. And yeah, that's our next however many months of work.

54:18Jamie Bannister:But the other big angle of it, which is really worth calling out, is it's not just the runtime code. We have a lot of data that is either data at rest or data going across a network that is serialized Python. We need to get all of that compatible. So if we have, for example, Python 2 Alt-Star classes and we want to serialize that to send it to your Python 3 node. Well, that's not going to work because Python 3 is going to, what's this? I don't know what to do with it.

54:47Jamie Bannister:So as well as changing runtime code, there's a lot of data at rest and data on the network that we also need to change.

54:53Michael Kennedy:Right. You did mention that you're using Redis, and one of the real common things to do is just to pickle the objects and put them into Redis. Yeah. But you know what? Memory shape changes from version to version.

55:05Jamie Bannister:I've literally been writing a blog that's going to come out in the next week or two, a public blog, talking about exactly that problem that we have here.

55:14Kristinn Þór Sigurbergsson:Is that the agent blog?

55:17Jamie Bannister:Yes. So in EVE, we have a bunch of NPCs that we call agents, nothing to do with LLM agents. These are just characters and they have memory. So when you talk to them, it's going to remember that you talked to them. And then later on, you're going to come back and they'll give you a mission or to go, go and fetch me this or go and kill this. it saves that bit of memory in the database. The way it saves it is as a serialized Python block, so that when it comes back, we can kind of reload the memory or reload that bit of memory from the disk.

55:51Jamie Bannister:We have those going back now for 20 years. I think there's about 100 gigabytes of Python memory in the DB, of agent memory in the DB in the form of pickled Python objects. So that's a big part we need to go through. Because we can't just write a database script that's going to do those, right? Because a SQL script isn't going to be able to serialize and deserialize Python objects.

56:15Michael Kennedy:It has no idea, yeah. Yeah. Are you considering moving to something that's version independent, like msgspec, or Pydantic, or JSON?

56:26Jamie Bannister:Some of these things, what we want to do is change the format to probably protobuf, because we use that for a lot of our kind of communications and storage as well, either protobuf or flat buffer, depending on the size. But yeah, a big part of our internal and external APIs are all built on top of protobuf. They would probably use that.

56:48Michael Kennedy:Yeah, so that'd be really natural. Maybe you could even just not even deserialize it, just give me the stuff and shoot it back over the network if it wants in that format anyway, digitally, I guess. All right, we'll get really short on time. Maybe just take us through the remaining arc of what you all planned out, What's still in the story to be told?

57:07Jamie Bannister:So, yeah, so we've got the data formats that we need to change. We've got the runtime code. Once we've got those worked out, some of the things we want to start doing are what we call a mix mode, which is where we take our cluster of 200 nodes plus all of our clients, all of which are 2.7 at the moment, and start to be able to selectively replace one piece of those with the Python 3 equivalent. So rather than doing a big deployment day where we say, okay, this is the moment, we want to incrementally do it, kind of spread that risk and that load at the time.

57:42Michael Kennedy:Can you imagine the stress of just

57:45Jamie Bannister:Oh yeah. Pushing the whole thing. I've been there for those big deployments, very stressful. So by doing this, we can spread that risk and that load over a lot of time, but it also means we're developing a lot of tools to support this project that aren't necessarily Absolutely required, but they're going to give us a lot better abilities. So like this ability to deploy a kind of a heterogeneous mix of types of builds and even mixed. Do we want to do some nodes on Linux and some on Windows, for example?

58:19Jamie Bannister:By doing these tools, that's going to give us a lot of these options.

58:22Michael Kennedy:Yeah, give you more deployment options and so on, right? That's pretty interesting. It's an interesting consequence. I didn't really consider coming along, but yeah, it makes sense. All right. Kristinn, what else do you want to say about this?

58:31Kristinn Þór Sigurbergsson:migration from maybe from the director high level yeah it's i mean i think it helps a lot that we did this for frontier first because one of the problems we had when we started this is that like we could start migrating the python code but none of the python code would really work without the C++ modules being um importable to python as well and we could start in the python C++ modules but like they wouldn't really make sense without the python glue kind of tying it together so it was really convenient to do this on a project like Frontier where the risk of breaking things is a lot less and like the first release we did we had hourly downtime because after like one and a half, two hours the process would just some of the process, some process somewhere would just stop responding at all and we were like a bit in the dark there it was like a very stressful time and it turned out to be something really really stupid so as it obviously would have but so i think i think the team city or the build system helped us a lot obviously being a game with you can imagine we don't have a robust robust suite of unit tests for all of our code base like

59:49Kristinn Þór Sigurbergsson:i mean even automated tests wasn't really like a big when we started doing this and a lot of the code was written in the first place. So doing like an incremental thing was kind of hard. But what we did do when we started, we started just running down the build system and just getting further and further into like an actual build.

1:00:09Michael Kennedy:So, yeah. Yeah, it's hard to test graphics and physics and stuff through automated tests to some degree, right?

1:00:17Kristinn Þór Sigurbergsson:And when we started, when I, at least when I started, I started talking to Thomas about this when I was a technical director in Yves and then we were thinking about it for Yves and it just, the entire concept of doing it just felt so, just so daunting and like big that I like couldn't imagine how we would do it. We did have a good plan, I think, and that plan kind of, we more or less did that for Frontier, but obviously like the stakes are higher for Yves Online.

1:00:47Kristinn Þór Sigurbergsson:So like it's a difficult thing.

1:00:49Jamie Bannister:And I can do a big difference So a critical thing for EVE is it's an online game, so the servers need to be running every single day. We can't afford to be taking the server down for a few hours every day. We need to kind of keep the product up. So that's where Frontier kind of running ahead of us was really, really helpful because they could prove a lot of this out before they got to the point where they needed to be online 24-7.

1:01:15Michael Kennedy:Yeah, it gives you a lot of flexibility to do all that testing, doesn't it?

1:01:20Thomas Dähling:Yeah, absolutely. especially because the transition to Python 3 is like an all or nothing step. You can't just put like one of your-- you can't just put the base interpreter on Python 3 and then keep all your native extensions to Python 2, right? You need to go all the way. Otherwise, it just doesn't work. That was actually the thing that gave-- I think that was the initial very biggest concern that we had, like, can we actually pull this off by doing this push out all at once? And I think it was also the main reason why we did this intermediate step of going to Python 3.8, stackless Python 3.8 first, because then we knew, okay, we are only changing the Python major version.

1:01:55Thomas Dähling:We're not also changing the async library underneath the hood, which a lot of the code still has some timing dependency somewhere, right? And all these things. Yeah, 100%.

1:02:05Michael Kennedy:Well, congratulations for Frontier and good luck on EVE Online. It sounds, honestly, it sounds like a really exciting project. Just a lot of fun to work on, even if it means you can't sleep quite as well at night for a little while. It's a little stressful.

1:02:19Kristinn Þór Sigurbergsson:It is exciting. I am proud of the team for delivering it to Frontieras. I'm sure I'll be proud of Eve when they deliver this. What I was fascinated by was that when I started looking into it, I wanted kind of like the war stories and I didn't really find a lot of people that had done it. And I'm sure a lot of people have done a very painful Python 3 migration. So my running theory was that nobody really wanted to talk about it after they had done.

1:02:49Kristinn Þór Sigurbergsson:some traumatic experience and just let it go.

1:02:54Michael Kennedy:Exactly, exactly. All right, well, let's close out the show. People who are maybe trying to accomplish the same thing, they have some older code base, they're trying to migrate even from maybe like old three to new three, something like that. Give them really quickly just some parting advice and also people interested in EVE online. Kristi, you wanna go first? So parting advice for people that wanna do this.

1:03:18Kristinn Þór Sigurbergsson:One of the things that I didn't mention is that we actually used a contractor for a lot of the stuff called Recon Digital. They deserve a shout as well. They did a really good job kind of migrating most of the Python code. And one of the reasons for it was also that developing a live game, we kind of knew that Frontier, the development team, would get immediately derailed when they had to do some feature work and not supporting Python 3. So that was one of the things.

1:03:46Kristinn Þór Sigurbergsson:So what I would probably argue there is like secure the resources, like make them untouchable while you're doing this migration. Because once you start, you have to finish it. If you pause it, it's almost wasted effort.

1:03:58Jamie Bannister:Yeah, that's a good point. Yeah, I was going to actually say something similar to that. Because we've got one group working on pushing ahead with the migration, we've still got a whole bunch of developers adding features to the game every day. So they're adding those features against our 2.7. And so we're putting a lot of work into trying to make sure that they have the new code they're adding is as forward compatible as possible. So a big thing we've rolled out this week is a new linter.

1:04:28Jamie Bannister:So we're getting and we're going to progressively ratchet up the strictness of it. So those kind of tools to kind of do code quality inspection, I think, are going to be really important for us going forward.

1:04:40Thomas Dähling:Yeah, 100% agree. Yeah, very much that. I would add the age-old advice of have really good test coverage. It helps a lot. But also, touching upon what Jamie just said, if you have a product that's live and you need to migrate it, make sure that you do this in a separate branch but have constantly ongoing migrations from the Python 2 side to the Python 3 side so that you discover all of these new pain points that may pop up as soon as possible. This helped us on Frontier as well, where sometimes things would come in that were clearly not Python 3 compatible, and then we could fix it up right away.

1:05:17Thomas Dähling:And the more frequent you do these integrations, like the less painful they are. If you do it once a month, oh my god. Like there was a period where we only did it like every other week, and we would basically spend a whole day just resolving all of the issues. So do it frequent, do it often, keep it small. Keep it small.

1:05:33Michael Kennedy:Good advice. Do it in small, small bite-sized bits. Yeah, absolutely. All right, you guys, thank you for being here. Everyone listening, check out Eve Online, eveonline.com. Very cool game, very cool ecosystem. Check out the video I linked that says This Is Eve. It's got some great graphics to inspire you as well. Bye, everyone. Thank you. This has been another episode of Talk Python To Me. Thank you to our sponsors. Be sure to check out what they're offering.

1:05:58Michael Kennedy:It really helps support the show. This episode is sponsored by Sentry's Seer. If you're tired of debugging in the dark, give Seer a try. There are plenty of AI tools that help you write code, but Sentry's Seer is built to help you fix it when it breaks. Visit talkpython.fm/century and use the code talkpython26, all one word, no spaces, for $100 in Century credits. And it's also brought to you by Talk Python Courses. Course completion certificates are now live.

1:06:26Michael Kennedy:If you finished a course, there's a certificate waiting for you on your account page right now. Download it as a PDF or add it to your LinkedIn profile with one click under licenses and certifications. Same section as your formal degrees. Visit training.Talk Python.fm slash account to see what you've already earned. If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from complete beginners to async code, Flask, Django, HTMX, and even LLMs.

1:06:57Michael Kennedy:Best of all, there's no subscription in sight. Browse the catalog at talkpython.fm. And if you're not already subscribed to the show on your favorite podcast player, what are you waiting for? Just search for Python in your podcast player. we should be right at the top. If you enjoyed that geeky rap song, you can download the full track. The link is actually in your podcast blur show notes. This is your host, Michael Kennedy. Thank you so much for listening.

1:07:19Michael Kennedy:I really appreciate it. I'll see you next time. I thought of me. Can we break the roll? Upgrade the code. No fear of getting old. We tapped into that modern vibe overcame each storm. Talk Python and me, async is the norm.