Python Language Summit 2025

00:00 Every year, the core developers of Python convene in person to focus on high-priority topics for CPython and beyond.

00:07 This year, they met at PyCon US 2025.

00:10 Those meetings are a closed door to keep focused and productive.

00:14 But we're lucky that Seth Michael Larson was in attendance and wrote up each topic presented and the reactions and feedback for each.

00:22 We'll be exploring this year's Language Summit with Seth.

00:24 It's quite insightful to where Python is going and the pressing matters the core devs are

00:30 giving their attention to.

00:31 This is Talk Python To Me, episode 514, recorded June 17th, 2025.

00:51 to unite. We started in pyramid cruising. Welcome to Talk Python To Me, a weekly podcast on Python.

00:54 to unite. We started in pyramid cruising. Welcome to Talk Python To Me, a weekly podcast on Python.

00:57 This is your host, Michael Kennedy. Follow me on Mastodon where I'm @mkennedy and follow the

01:02 podcast using @talkpython, both accounts over at fosstodon.org and keep up with the show and

01:09 listen to over nine years of episodes at talkpython.fm. If you want to be part of our live episodes,

01:14 you can find the live streams over on YouTube. Subscribe to our YouTube channel over at

01:19 talkpython.fm/youtube and get notified about upcoming shows. This episode is brought to you

01:25 entirely by Sentry. It's a bit of an episode takeover, if you will. Sentry has two excellent

01:31 and exciting services to tell you about. Sear, your agentic AI debugging assistant, which takes

01:37 all the data already gathered by Sentry to help discover the problems and even propose fixes as

01:43 GitHub PRs. And the other is AI agent monitoring, which adds deep observability to your AI agents

01:50 in your app. If you're adding AI and LLM features to your Python apps, you'll want to know about AI

01:56 agent monitoring. I'll tell you more about both of these later in the episode. And remember,

02:01 however you happen to sign up for Sentry, if you do use our code, TALKPYTHON, one word, all caps,

02:08 let's get to the interview. Seth, welcome back to Talk Python. I mean, awesome to have you here.

02:12 Thank you for having me, Michael.

02:14 Yeah, it's always fun to have you on the show.

02:17 And you know what?

02:17 I don't even think we're going to talk that much about security this episode, are we?

02:22 Not too much.

02:22 No.

02:23 I mean, as I say that, I'm sure we're going to come up with something, right?

02:27 But the last couple of times I've had you on, it's because you're doing something with security

02:33 and Python, and it's always been very interesting.

02:35 It's true.

02:35 It's true.

02:35 Yeah, no, I do a lot of security these days, but I do other things too.

02:41 be the eyes and ears of everyone who could not attend the language summit yeah so i was the

02:46 be the eyes and ears of everyone who could not attend the language summit yeah so i was the

02:47 blogger again this year i got invited back they didn't uh they liked what i did last year so like

02:52 ah well we'll have this guy again why not right like yeah it was great i mean i love attending

02:56 the language summit blogging for it it's a it's a really unique way to contribute back to the to

03:01 python community it's a such a specific role so yeah it really is i think maybe we start there

03:04 python community it's a such a specific role so yeah it really is i think maybe we start there

03:07 Maybe we start with what is the Language Summit and why are there not just a bunch of videos online and why weren't there sessions that necessarily open sessions at PyCon, right?

03:18 It's kind of a special event.

03:21 Yeah, so the Language Summit is, historically, it is this event that happens every year before, right before PyCon US.

03:29 It's been hosted in other PyCons as well.

03:31 But nowadays it happens at PyCon US and it occurs kind of at the same time that like tutorials are happening.

03:37 So that's a day or two before the actual conference starts for most attendees where there's talks and all of that.

03:43 And basically what ends up happening is a bunch of core developers and triagers and some special guests all convene into one room for a full day of short talks followed by tons of discussion.

03:56 And the reason that it's like a closed session is like one, it's a logistical thing.

04:00 Like the room is only so big.

04:02 And I'm pretty sure the organizers know that if it was just like open session, it would be like, oh, we need to have this huge conference room of people.

04:09 And it's not really conducive to discussion because it is very fast moving, asking questions, getting answers and having people be able to exchange this information really quickly.

04:21 And so to offset the lack of openness, right, because not everyone can possibly attend that

04:26 wants to attend, what ends up happening is a blogger, someone who covers the actual event,

04:32 every single talk, every single discussion, all the questions, what gets discussed,

04:36 and then like the vibes of the room and like how people are feeling about topics.

04:40 That gets covered by a blogger, which this year was me, last year was also me, but then

04:45 the years prior has been like Alex Waygood covered the year prior to me starting.

04:50 So Alex taught me everything I need to know and what to expect and all of that.

04:54 Nice.

04:54 Yeah.

04:55 And I had you on last year and I had Alex on the year before, I believe.

04:58 So it's a bit of a tradition.

04:59 There we go.

05:00 Cool.

05:00 And yeah, also people should know it's a working session with the goal of not just presenting

05:06 ideas, but making decisions, trying to come to an agreement with the core devs and steering

05:12 council and maybe other councils, as we'll see all the councils.

05:16 Yeah.

05:16 Yeah.

05:16 Right.

05:17 No, it's lots of decision makers in there.

05:18 No, it's lots of decision makers in there.

05:19 I feel like it tends to be a really great arena to kind of just get really quick feedback on either ideas or questions.

05:28 Because like it's really funny.

05:30 One of the talks happened not to get into too much detail right away.

05:33 But like one of the talks happened.

05:35 They're like, oh, we have this problem.

05:36 We really need more arm builders for GitHub CI for this specific reason.

05:40 And E Durbin, director of infrastructure at PSF, was in the room and they were just like, oh, I just bought more.

05:46 And it's like, oh, great.

05:47 Oh, that's awesome.

05:48 Oh, that's awesome.

05:49 Quick feedback.

05:50 That's the way to make it happen.

05:52 That's right.

05:53 You know, before we get into that, just maybe it's worth a quick conversation about.

06:00 You were actually in New York City.

06:02 We just heard a siren go by.

06:04 So we now officially know that you're in New York City, right?

06:07 Yes, exactly.

06:08 There's always something going on there in terms of noise or energy or whatever.

06:11 There's always something going on there in terms of noise or energy or whatever.

06:12 There's always something going on there in terms of noise or energy or whatever.

06:14 For the UN Open Source Conference, that's super interesting.

06:16 For the UN Open Source Conference, that's super interesting.

06:17 For the UN Open Source Conference, that's super interesting.

06:17 What is that?

06:18 Yeah, so United Nations Open Source Week.

06:19 Yeah, so United Nations Open Source Week.

06:21 I got invited to attend through the Software Tech Agency and also Alpha Omega.

06:26 They are collaborating to host a maintain-a-thon, which is essentially just get a whole bunch of open source project maintainers, project leaders, governance people, like people doing more than just security.

06:38 So I was there to represent the security perspective and also Python, Python Software Foundation.

06:44 And just getting us all together and trying to talk about really complicated issues for open source and how open source can be used to better the world, to be a part of, you know, a more open access world, more open data world.

06:58 Those are kind of like the themes.

06:59 And specifically the maintain-a-thon was more like hosting small sessions with lots of discussion, almost kind of like the Language Summit, where there's a really short presentation about a topic I presented on low energy security.

07:12 So security practices and processes for projects that don't have access to tons of security expertise.

07:19 And then like, what are the, how can we make the situation better for those types of projects?

07:21 And then like, what are the, how can we make the situation better for those types of projects?

07:24 Oh, very cool.

07:25 There's, you know, there's a lot of energy for open source in the United States corporately,

07:31 but internationally, there's a lot of energy for open source at a governmental level.

07:35 More so, way more so than the US.

07:37 I mean, there's little pockets of things like, hey, we'd like to have some open source initiatives for what we're building in the US.

07:44 But there's, I can't remember what country's doing it right now.

07:47 One of the countries is trying to replace basically Microsoft Office and Windows with something Linux and open source.

07:54 And there's a lot of stuff like that.

07:55 Yeah.

07:56 I mean, it's about having sovereignty about or like over your technology stack, right?

08:01 Making sure that you have complete control and that there's interoperability and that.

08:01 Making sure that you have complete control and that there's interoperability and that.

08:01 Making sure that you have complete control and that there's interoperability and that.

08:05 Yeah. Being able to work independently as like a government agency, just as important as a company, right? You want to make sure that you're able to control all the processes and data that are inside that are important to you.

08:16 Sure. And I think we're in a bit of a special situation being in the U.S.

08:16 Sure. And I think we're in a bit of a special situation being in the U.S.

08:23 I don't think we have as much of a feeling of, wouldn't it be nice if we weren't beholden to U.S. companies?

08:29 Because we're already beholden to the U.S. We live here, we pay taxes, we're subject to the rules.

08:34 But if you're outside of the U.S., most countries and organizations are still beholden to U.S. companies.

08:39 And I think that that's a part of the vein of the ideas there, right?

08:43 And I think that that's a part of the vein of the ideas there, right?

08:45 Yeah, it definitely is a part of it. Being able to do your own thing without worrying about other countries, what they're doing or what their relationship is with you and still being able to interoperate on a global scale. Right. Because like a lot of these formats are open and they interoperate like PDF, Doc X. They're all they're all open. They can be written by any software, not just Microsoft software.

09:04 So yeah, absolutely. And I guess that's true for the U.S. in terms of software, but not so much for hardware, right? We're more in the same boat as everyone else with hardware, but that is a bit too far down the weeds, maybe, so we don't need to debate that. But it's super interesting that you're at that conference and it sounds really fun.

09:05 So yeah, absolutely. And I guess that's true for the U.S. in terms of software, but not so much for hardware, right? We're more in the same boat as everyone else with hardware, but that is a bit too far down the weeds, maybe, so we don't need to debate that. But it's super interesting that you're at that conference and it sounds really fun.

09:24 Yeah, it's a great time. A lot of really smart people here. So I'm happy that they let me in.

09:30 How'd I get here?

09:31 Exactly.

09:32 What office did you run for to get elected to that?

09:34 What office did you run for to get elected to that?

09:34 Oh, none. None of them.

09:36 Cool. So let's talk Language Summit.

09:39 When we started sort of backstage, we were trying to plan out some of the themes and stuff.

09:44 You talked about there being a couple of major themes of the Language Summit this year.

09:49 And I certainly, reading your write-up, thought like, wow, multi-threading has got some attention.

09:54 Yeah, free-threading was a big part of the Language Summit.

09:57 I think it was like a third, somewhere between a third and a half of the talks touched free

10:04 threading or parallelism or the concurrency model of Python.

10:08 It was obviously a big thing.

10:09 Yeah.

10:09 What are some of the other themes?

10:09 What are some of the other themes?

10:11 Yeah.

10:11 So the other ones are things like, okay, we have all these other platforms for Python.

10:16 If you read, if you've read like the last year's language summit, there's kind of this

10:22 through line of like mobile and web both kind of got discussed.

10:26 And so if you contrast like the status of those projects, then what the write ups were to now, the projects are way further down the line. So like Russell came up and got to say like, oh, mobile for Python, both on Android and iOS are basically here. And a huge round of applause from all the core devs because they were super successful in achieving the mission that they set out to do back a year ago at the language summit where they laid out what their plans were.

10:54 So yeah, there it will be basically mobile support. I think it's for three working, I think is the hope that it's going to be actually like working and you should use it and you can build apps with it. And that's really exciting.

11:05 So yeah, there it will be basically mobile support. I think it's for three working, I think is the hope that it's going to be actually like working and you should use it and you can build apps with it. And that's really exciting.

11:07 It is very exciting.

11:09 Yeah. And then the other platform is web, obviously. So Pyodide is, is one of the big

11:13 ones there. So if you've heard of like PyScript or, Jupyter light uses Pyodide, both of

11:20 those platforms, like for Python on the web, there was this talk about upstreaming, the

11:26 FFI, the JavaScript FFI and some JavaScript APIs, to see Python as opposed to keeping them

11:33 resident in Pyodide. And what that would essentially mean is that if you ran Python

11:34 resident in Pyodide. And what that would essentially mean is that if you ran Python

11:35 resident in Pyodide. And what that would essentially mean is that if you ran Python

11:38 compiled for, what was it, like the WebAssembly platform, you would be able to interact with

11:44 JavaScript from the standard library, like the OS module or something like that.

11:48 And that is pretty exciting to hear something like that.

11:49 And that is pretty exciting to hear something like that.

11:51 And there was also some talk about, apparently recently, MicroPython got web support.

11:56 And so trying to unify a little bit the APIs that the two are using.

12:01 Yeah, that's super exciting.

12:02 We'll definitely dive into it.

12:03 The fact that MicroPython got web support means it's possibly a good use for broader web applications, right?

12:11 Because PyDot is awesome, but it's also something like 10 megs or somewhere in megs.

12:17 And it takes a bit to load up because it is basically CPython.

12:20 Whereas MicroPython is 100k.

12:22 And people are used to doing 100k JavaScript, but not multi-meg JavaScript for standard stuff.

12:27 So yeah, really exciting.

12:29 We'll dive into that.

12:29 We'll dive into that.

12:30 So not surprising. I thought we could just maybe work our way through the different presentations.

12:36 How long is each presentation besides the lightning talks about?

12:39 Yeah. So it's each session is, I think it's like 30 minutes. The talk itself is usually

12:39 Yeah. So it's each session is, I think it's like 30 minutes. The talk itself is usually

12:46 10 minutes. I could actually think of the schedule. I should know that's off the top of my head.

12:49 The recitations are super fast. They're like 10 minutes and then the rest is discussion. So it's

12:53 The recitations are super fast. They're like 10 minutes and then the rest is discussion. So it's

12:54 quite a quick format. And your write-up mirrors that, right? So people read your

12:54 quite a quick format. And your write-up mirrors that, right? So people read your

12:55 quite a quick format. And your write-up mirrors that, right? So people read your

12:59 post, I'll link to, what I'm going to do is I'm going to link to the meta post, I guess,

13:04 in the sense of like a meta package in that it says, here's all the articles for, that

13:09 I wrote up for the language summit.

13:11 So you can jump to the ones you want to see.

13:13 And it, your, your write-ups mirror that.

13:15 It's like, here's what happened in the presentation.

13:17 And then the discussion that happened below it from all the core devs.

13:20 Yeah.

13:21 Yeah.

13:21 It's short presentation.

13:22 And then it's just like immediately into questions, feedback, all of that.

13:27 So it mirrors it.

13:29 This portion of Talk Python To Me is brought to you by Sentry's Seer.

13:34 I'm excited to share a new tool from Sentry, Seer.

13:37 Seer is your AI-driven pair programmer that finds, diagnoses, and fixes code issues in

13:43 your Python app faster than ever.

13:45 If you're already using Sentry, you are already using Sentry, right?

13:49 Then using Seer is as simple as enabling a feature on your already existing project.

13:54 Seer taps into all the rich context Sentry has about an error.

13:58 stack traces, logs, commit history, performance data, essentially everything.

14:02 Then it employs its agentic AI code capabilities to figure out what is wrong.

14:07 It's like having a senior developer pair programming with you on bug fixes.

14:12 Seer then proposes a solution, generating a patch for your code and even opening a GitHub pull request.

14:18 This leaves the developers in charge because it's up to them to actually approve the PR.

14:23 But it can reduce the time from error detection to fix dramatically.

14:27 Developers who've tried it found it can fix errors in one shot that would have taken them hours to debug.

14:33 SEER boasts a 94.5% accuracy in identifying root causes.

14:38 SEER also prioritizes actionable issues with an actionability score, so you know what to fix first.

14:46 This transforms sentry errors into actionable fixes, turning a pile of error reports into an ordered to-do list.

14:53 If you could use an always-on-call AI agent to help track down errors and propose fixes

14:58 before you even have time to read the notification, check out Sentry's Seer.

15:03 Just visit talkpython.fm/Seer, S-E-E-R.

15:08 The link is in your podcast player's show notes.

15:10 Be sure to use our code, TALKPYTHON.

15:13 One word, all caps.

15:14 Thank you to Sentry for supporting Talk Pythonemy.

15:18 So the first one, let me, I didn't always write down the names here, is the first one

15:22 is how can we make breaking changes less painful by Itmar Oren?

15:27 And so this one, Itmar deploys a bunch of Python code for production at meta

15:33 and said, going from version 3.11 to 3.12 or 3.12 to 3.13 has breaking changes that can be challenging.

15:43 I don't encounter too many breaking changes in upgrading Python versions,

15:48 but I also don't have literally millions of lines of code doing intricate things either so

15:53 right this is a pretty pretty edge case but also an important one right yeah this so this talk I

15:56 right this is a pretty pretty edge case but also an important one right yeah this so this talk I

15:59 think one of the big things about this talk too is it wasn't just about like oh jumping from one

16:04 version to one version a lot of companies employ like a skip version upgrading style where they'll

16:10 experience breaking changes in a slightly different way than a lot of other users where they're jumping

16:14 from like 3.11 to 3.13, as opposed to like 3.11 to 3.12 to 3.13, because upgrading is obviously

16:18 from like 3.11 to 3.13, as opposed to like 3.11 to 3.12 to 3.13, because upgrading is obviously

16:19 from like 3.11 to 3.13, as opposed to like 3.11 to 3.12 to 3.13, because upgrading is obviously

16:22 this like big task. And so they don't want to do it every year. Maybe they do want to do it every

16:26 two years and that's fine for them unless there's some feature that they really need or something

16:31 like that. But yeah, so like anytime that you're upgrading more than one tython version, like it

16:36 just, the breaking changes are obviously twice as, twice as many on average. Yeah. Sometimes they

16:41 just, the breaking changes are obviously twice as, twice as many on average. Yeah. Sometimes they

16:41 even go from 2.7 to 3.11. Yes and on rare occasions they go from 2.7 to 3.11 yeah thankfully that

16:43 even go from 2.7 to 3.11. Yes and on rare occasions they go from 2.7 to 3.11 yeah thankfully that

16:50 happens less and less yeah that's a story from uh the last decade thankfully yeah so this

16:54 happens less and less yeah that's a story from uh the last decade thankfully yeah so this

16:57 was like talking about like okay how we we're not trying to say breaking changes shouldn't happen

16:58 was like talking about like okay how we we're not trying to say breaking changes shouldn't happen

17:03 because we know that they're important and they're a good way to unblock things and remove pieces of

17:07 software that we don't want users using, but trying to make it so that we can almost like quantify

17:15 how bad a breaking change will be for users. And then based on that quantization, figure out what

17:21 we need to do, maybe extra if it's like a particularly bad breaking change, or if it's

17:26 just like, Oh, well, this has been deprecated for five years, and then removing it, or like,

17:30 there's an easy drop in replacement, that's one to one, those sorts of breaking changes are really

17:35 easy versus things like, oh, this behavior changed and you won't know until runtime and

17:40 things like that are way more difficult.

17:42 You have to have like a test harness that's actually testing all of the possibilities in

17:47 the code to know whether you're safe or not versus like a syntactical control F find the

17:53 bad function and then replace it.

17:54 Yeah, it could be super subtle, right?

17:55 Yeah, it could be super subtle, right?

17:57 It could be the runtime things, but it could also be the memory structure of something we

18:05 to a redis cache via pickling has changed and that's the that the cache version no longer works

18:11 and we have to somehow figure out how to completely delete the cache and start over and some web apps

18:17 that's a problem right when they're under tons of traffic that sort of cold start experience can be

18:18 that's a problem right when they're under tons of traffic that sort of cold start experience can be

18:18 that's a problem right when they're under tons of traffic that sort of cold start experience can be

18:19 that's a problem right when they're under tons of traffic that sort of cold start experience can be

18:22 a problem yeah and there's there's even things that like aren't even part of this gets mentioned

18:23 a problem yeah and there's there's even things that like aren't even part of this gets mentioned

18:28 in a future talk about parallelism where it's not even a function of the language but it just happens

18:33 to be a property of how a particular set of code executes in one version versus another.

18:38 So like with the, from the difference between 3.9 and 3.10, where something is thread safe,

18:40 So like with the, from the difference between 3.9 and 3.10, where something is thread safe,

18:41 So like with the, from the difference between 3.9 and 3.10, where something is thread safe,

18:44 that it doesn't look thread safe at all. Like if you look at the code, you're like, oh, that's not

18:47 thread safe. But the GIL based, like the implementation of the GIL in 3.9 keeps it thread

18:52 safe. But in 3.10 and beyond, it's no longer thread safe. But the thing is, is you were relying

18:57 on behavior that's not defined in Python. It wasn't guaranteed. Yeah, there's no guarantee that.

18:59 on behavior that's not defined in Python. It wasn't guaranteed. Yeah, there's no guarantee that.

19:03 And so it's like, is that a breaking change?

19:04 And so it's like, is that a breaking change?

19:05 No, but also like it'll probably break somebody.

19:07 And also how do you detect that at a syntax level?

19:10 You can't, the syntax is the same.

19:12 Should it be written down as a breaking change?

19:13 I don't know.

19:14 Maybe does it, does your code feel broken if it gives you different answers

19:18 and those answers start becoming wrong?

19:20 Maybe.

19:20 Yeah, it's tough.

19:21 It's a really tough thing.

19:22 It's a really tough thing.

19:23 I think core developers were like pretty happy with the idea of like treating different breaking changes differently, trying to develop some

19:30 sort of taxonomy of breaking changes.

19:32 And there were some interesting ideas with like running these like code update scripts, providing code update scripts that if you have code and there's breaking changes that are on the syntax level, being able to upgrade them.

19:42 Apparently, Ruff had some ability to do this for two major versions of NumPy.

19:47 And so like that got brought up as an example of like, oh, this worked really well for NumPy.

19:50 And so like that got brought up as an example of like, oh, this worked really well for NumPy.

19:51 And so like that got brought up as an example of like, oh, this worked really well for NumPy.

19:51 So maybe Python?

19:53 Yeah, absolutely.

19:54 Well, I was.

19:55 Yeah, absolutely.

19:56 I think Ruff is certainly in a good position to do that.

20:00 Yeah.

20:00 You could say, this pattern isn't wrong, but maybe it should come up with a warning, just so you know.

20:06 We can run this check if you really want to see, right?

20:09 Yeah, so one of the things Edmar pointed out was, it's difficult to find the documentation of deprecated and removed modules,

20:16 because after a module is removed, the documentation is also removed.

20:20 It's like, it's a bit of a catch-22.

20:23 Yeah, that one was really interesting, because, yeah, like, especially if you're skipping versions, too.

20:28 Like you go to the docs and the module is just gone and you're kind of left to figure

20:35 out what was the last version that had that module.

20:38 When did the deprecation warning start?

20:39 Where's the warning?

20:40 Like where is the actual documentation that says what to do?

20:42 Like where is the actual documentation that says what to do?

20:44 And so, yeah, apparently the docs editorial team are working on that.

20:48 They're trying to figure out a solution for better documentation for removed modules specifically

20:50 They're trying to figure out a solution for better documentation for removed modules specifically

20:53 or removed.

20:54 Yeah.

20:55 Yeah.

20:55 Carol Willing said they were working on that.

20:57 Very interesting.

20:58 You can go to the documentation, like docs.python.org, and pick through it.

21:02 You can go to the documentation, like docs.python.org, and pick through it.

21:02 You can go to the documentation, like docs.python.org, and pick through it.

21:03 But by default, it lands on the latest, right?

21:05 Yep.

21:06 By default, it lands on the latest.

21:07 And if there are any links to modules or to deprecation links that aren't pinning to a specific version,

21:14 it'll go to the latest and be like, oh, we don't have those docs anymore.

21:17 Yeah.

21:17 It's just 404.

21:17 It's just 404.

21:18 You're like, huh, weird.

21:19 Yeah.

21:19 Weird, weird.

21:20 Okay.

21:21 Well, very, very interesting.

21:22 The next one, we have an uncontentious talk about contention.

21:26 And now we start into the heart of the topics, which is threading, async, IO, parallelism,

21:33 concurrency, all these things, right?

21:35 And this is the one you were referencing when you ask, is this code thread safe?

21:40 So just give people a sense.

21:41 There's an incredibly simple parallel example of create a counter class.

21:45 The counter has a value.

21:46 You can run some code that goes for 100,000 times, increment the value, start 10 threads

21:52 at all, jam on that.

21:54 And then this is by Mark Shannon.

21:56 He says, we would like this to print exactly 1 million.

22:00 I'm not sure that that's necessarily true.

22:02 You would, as a creator of this program, you wanted to exactly print a million,

22:06 but there might be advantages to allowing code to run more parallel rather than less parallel.

22:14 And say it's on the author of that code to make it thread safe.

22:18 Yeah.

22:19 If it's five times faster If it's five times faster because Python, the runtime doesn't make it thread safe.

22:24 maybe you choose the time and the way that you run that code.

22:27 That's all I'm getting at.

22:28 Like we would like it to print exactly a million times as a correctness,

22:32 but maybe it's not Python's job.

22:34 No, I think maybe that comment is like not necessarily like we core developers

22:40 should want this program to print exactly one million.

22:42 I think it's more of like, oh, if you were someone who's writing this code,

22:46 you would maybe expect it to print a million because they're like, oh, you would maybe expect it to print a million because they're like, oh,

22:48 in three nine and before it prints a million.

22:51 So like, that's fine.

22:52 But then...

22:52 But then...

22:53 Yeah, so you know what changed in the GIL?

22:54 Yeah, so you know what changed in the GIL?

22:55 I actually don't know specifically what changed in the GIL.

22:59 It was something to do with context switching in the GIL.

23:02 Made this no longer change.

23:04 My guess is that it's performance, like you said.

23:04 My guess is that it's performance, like you said.

23:05 My guess is that it's performance, like you said.

23:07 Yeah, exactly.

23:07 Exactly.

23:08 They probably said we can make the GIL more fine-grained and get more perceived cooperative or primitive multithreading as it goes.

23:15 and get more perceived cooperative or primitive multithreading as it goes.

23:16 and get more perceived cooperative or primitive multithreading as it goes.

23:16 Something like that, right?

23:17 Exactly.

23:18 Yeah, and that's kind of what I was hinting at there.

23:20 Okay, so that's the story.

23:25 And basically, Mark said, thread safety is a property of the program, the Python code you write, or someone's written,

23:31 in the implementation of CPython and how it behaves, in this case, the GIL, right?

23:36 Yeah, so Mark was, I think the big thing for Mark's talk Yeah, so Mark was, I think the big thing for Mark's talk

23:39 was this synchronization quadrant, where he is basically trying to make some bets

23:46 about what's going to happen next to try to solve some of the problems that we're going to start seeing or parallel Python, right?

23:53 And that's either anytime that you have both mutability and shared references, you have problems with synchronization.

24:02 And if you introduce more immutability or less sharing, then you're starting to solve these problems.

24:10 But the unfortunate thing is that there's a lot of Python that happens in the shared and mutable section.

24:15 And we don't want to have to like ask everyone to rewrite all their Python programs.

24:21 So it's definitely like a tough like quantization problem.

24:24 Like how how big of an issue would making changes like this be?

24:28 But then also like we don't even really today give people a ton of the tools that they would need to be able to work with like immutable data structures.

24:36 Because like we have frozen set and we have tuples frozen list, frozen dictionary, any of that.

24:39 Because like we have frozen set and we have tuples frozen list, frozen dictionary, any of that.

24:41 Because like we have frozen set and we have tuples frozen list, frozen dictionary, any of that.

24:44 And so, yeah, Mark just basically gave a whole bunch of things where it's like, here's all of these ideas that I have

24:48 for making this more easy, having more immutability.

24:54 And we should probably start thinking about that now because we're starting to get into free threading time.

24:59 Yeah, certainly a threading collections sort of deal would be great.

25:04 Yeah, I think the final thing there was like, Yeah, I think the final thing there was like,

25:07 oh, we should definitely be doing this on PyPI.

25:09 And I think the free threading team is planning on creating some immutable data structures and putting them on PyPI at first before migrating them.

25:17 Oh yeah, that's an interesting idea.

25:18 Like take them for a test run before people, before they get baked into a pattern, right?

25:23 Exactly.

25:24 You know, one of the things that I think is a danger of those types of data structures

25:29 and they, don't get me wrong, they're useful and they're good.

25:32 But one of the dangers is they can give people a false sense of security, right?

25:37 If you have four or five lines of code that is changing state, you know, check to see something that is in the list.

25:44 And then in the next line, remove something from the list.

25:48 Even if that list itself is thread safe, if it's immutable, that's one thing.

25:52 But if it's a mutable list that you're trying to make a thread safe version of, it's still possible that the check was thread safe and the remove was thread safe.

26:01 But something happened between those two where the thing's no longer in the list, right?

26:05 It gives people this sense of, well, I've got a thread safe collection, so I'm good to go.

26:09 It's like on a line by line basis, that's true.

26:12 But as a block of code, it's still not true.

26:14 And you still have to think more about these things.

26:16 That doesn't mean you shouldn't have them.

26:17 But it is like an awareness sort of thing.

26:20 Because I'm doing thread safe.

26:22 Look, from system.threading.collections, import, whatever.

26:26 We're good to go.

26:27 Like, better.

26:29 Yeah, yeah.

26:29 You actually have to use the data structures.

26:31 You can't.

26:32 You have to use the immutable ones.

26:33 Don't use the mutable ones and expect.

26:35 Yeah.

26:36 So it's, but it is certainly in the right way.

26:36 So it's, but it is certainly in the right way.

26:38 There was some, there's some pretty extreme in terms of how much they would change programming

26:44 paradigms and ideas, suggestions here.

26:46 And I don't remember if they, how these are starting to blend together these different

26:50 topics, but yeah, like one of, one of the challenges is that functions and types are

26:57 mutable, right?

26:58 And that makes it hard, even at a CPython implementation, runtime level of dealing with some of these things.

27:06 But changing them breaks the style of Python somewhat.

27:11 That's a trade-off, right?

27:12 That's a trade-off, right?

27:12 It's a huge trade-off, yeah.

27:14 And the fact that everything is mutable and a lot of things are shared, like the standard library,

27:19 the whole standard library is shared across everything.

27:22 It's really difficult to say that, oh yeah, if you're in that top right quadrant of shared and mutable,

27:28 which way does like the standard library move like you can't uh uh you can't make everything

27:35 immutable and you can't make everything not shared so it's what do you do yeah for sure and it's also

27:40 immutable and you can't make everything not shared so it's what do you do yeah for sure and it's also

27:41 a performance issue that you could because you know like right here mark points out that

27:47 where mutability is lots of day uh maybe it is there but not for a good reason like functions

27:52 and class method resolution order, all that stuff.

27:56 It's mutable, but should it be?

27:58 The thing is, if it's going to remain mutable, you probably have to do locks and stuff down in CPython,

28:04 which will slow it down.

28:05 If it were immutable, you don't have to lock it.

28:07 You can read from multiple threads all day long and it's not going to hurt anything.

28:11 So it's actually a performance consideration, not just a flexibility, right?

28:15 If you say, we really value this multi-threading and we wanted to operate as quick as regular Python,

28:21 but scale really well, these are trade-offs you got to consider, but then we all have like scars from two to three.

28:27 And this could be a little like that. Yeah. Yeah. I think it's going to, it's going to

28:29 And this could be a little like that. Yeah. Yeah. I think it's going to, it's going to

28:32 matter. And I think that like companies are going to have to maybe start even like profiling their

28:37 own code and trying to see where they're hitting those, like those like stop or stop the world

28:42 locks or any sort of like performance issue, like, and trying to like track down where in their code

28:47 we're hitting those like really expensive operations. And if they're trying to write

28:52 this like extremely high parallel code, having having a way to profile it would be sounds really

28:59 like a good idea, because I think that there's like going to be once this starts happening,

29:04 people are going to have to start thinking about like CPython the runtime. What are the expensive

29:09 operations that are happening in my own code that maybe could be done differently to take

29:14 advantage of free threading completely. Yeah. Well, and going back to the opening part with like

29:16 advantage of free threading completely. Yeah. Well, and going back to the opening part with like

29:19 the red safe collections and so on, it's really difficult for us as Python devs to create those

29:24 because we could write that in Python, but that makes it fairly slow. You need that down at the

29:29 machine level, right? Like probably CPython. We'll see if it's CPython or RPython or whatever,

29:35 as we go through this series of talks. But at the time of speaking, recording, it's CPython,

29:36 as we go through this series of talks. But at the time of speaking, recording, it's CPython,

29:37 as we go through this series of talks. But at the time of speaking, recording, it's CPython,

29:41 right? It would be way faster if there was a in the standard library C implementation of a thread

29:47 safe thing that's not being coordinated by a bunch of calls from the Python level. Okay. I guess

29:54 closing this one out, Mark suggested adding a freezing method to data structures like byte arrays.

29:59 That's kind of what we were talking about. And Barry Warsaw said that he'd brought up a proposal,

30:04 a PEP that was a freeze protocol that was rejected 20 years ago.

30:12 Those were different times.

30:13 Those were different times, right?

30:14 How many cores do we have?

30:16 Or was it like a dual?

30:18 Single digit still.

30:18 Single digit still.

30:19 Yeah, certainly a single dual, maybe a quad core if you were awesome back then.

30:24 That's not the case anymore.

30:25 So the benefit of having something like this is certainly higher.

30:28 So I was like, why was that rejected again?

30:29 So I was like, why was that rejected again?

30:31 We don't know.

30:32 Yeah.

30:32 Freezing comes up yet again in another one of the talks about a fearless concurrency as well.

30:39 So I think that something like that is probably going to get resurrected,

30:43 at least tried to be done again.

30:47 This portion of Talk Python To Me is brought to you by Sentry's AI agent monitoring.

30:52 Are you building AI capabilities into your Python applications?

30:55 Whether you're using OpenAI, local LLMs, or something else, visibility into your AI agent's behavior, performance, and cost is critical. You will

31:05 definitely want to give Sentry's brand new AI agent monitoring a look. AI agent monitoring gives you

31:12 transparent observability into every step of your AI features so you can debug, optimize, and control

31:18 the cost with confidence. You'll get full observability into every step of your AI agent.

31:24 That is model calls, prompts, external tool usage, and custom logic steps.

31:29 AI agent monitoring captures every step of an AI agent's workflow from the user's input to the final response.

31:36 And your app will have a dedicated AI agent's dashboard showing traces and timelines for each agent run.

31:44 You'll get alerts on model errors, latency spikes, token usage surges, and API failures protecting both performance and cost.

31:53 It's plug-and-play Python SDK integration.

31:56 Open AI for now for Django, Flask, and FastAPI apps with more AI platforms coming soon.

32:02 In summary, AI agent monitoring turns the often black-box behavior of AI

32:07 in your app into transparent, debuggable processes.

32:11 If you're adding AI capabilities to your Python app, give Sentry's AI agent monitoring the look.

32:17 Just visit talkpython.fm/sentryagents to get started and be sure to use our code,

32:24 TALKPYTHON, one word, all caps.

32:26 The link is in your podcast player's show notes.

32:28 Thank you to Sentry for supporting Talk Python and me.

32:29 Thank you to Sentry for supporting Talk Python and me.

32:32 I don't know if you wanted to jump to that one because I think that one and the uncontentious talk

32:34 because I think that one and the uncontentious talk because I think that one and the uncontentious talk

32:36 is quite, they're pretty related.

32:37 We were talking fearless concurrency?

32:37 We were talking fearless concurrency?

32:39 Yes.

32:39 Yeah, let's talk that one.

32:41 So that's by Matthew Parkinson, Tobias Rigstad and Rudolf Stoltz.

32:47 Hopefully I did a justice to your name, folks.

32:50 Yeah, so fearless concurrency.

32:51 This was one of the more detailed ones.

32:54 And so this one, I don't know how I feel about this one, Seth.

32:59 This is one of those things where it's like, if we take this really wild idea that really changes the way people have

33:07 traditionally done programming for concurrency, then we could get great benefits.

33:11 But it also is like, I don't know what your assessment is.

33:15 My sense is that most Python people don't think a lot about threading, haven't done much threading, and their skills of threading, problem solving, using fairly straightforward things like locks is still pretty much like, I think they have those in the language.

33:32 You know what I mean?

33:33 Like, not really like, yeah, oh yeah, yeah.

33:35 I use event signals and all sorts of like producer consumers, like not very much of that.

33:39 You know what I mean?

33:41 And so anyway, tell us what this is about because it's an interesting concept.

33:46 Yeah.

33:47 So.

33:47 Debate it.

33:48 Yeah.

33:48 This concept is all about, so like the central concept is regions and regions are essentially

33:55 in Rust, they have this model where a mutable reference is only allowed to be like a mutable

34:01 object is only allowed to be referenced once, right?

34:03 Like that's the ownership model in Rust, but that's like not compatible with how Python

34:04 Like that's the ownership model in Rust, but that's like not compatible with how Python

34:05 Like that's the ownership model in Rust, but that's like not compatible with how Python

34:08 programs are in general. Yeah, because we love our mutability. And so this is essentially like,

34:14 okay, well, what if we could have kind of like a looser version of that, where you have objects

34:20 that are doing mutability and all of that within a region, but then anything outside the region

34:27 can't mess with it. And then if you have that situation, which is more common and more like

34:32 understandable for like a Python programmer, then you can get a bunch of performance benefits,

34:37 because you know that nothing outside of the region is going to be doing any sort of like that special mutability.

34:44 Just out of nowhere, we're going to change something about your function signature or something.

34:49 And so then when you have this situation, you can even do, yeah, like so this diagram is showing

34:53 all these references into that region from a specific thread.

34:59 We know because of how the region is created that the other thread can't modify anything inside.

35:04 And so you get a bunch of performance benefits for all of the operations that are happening inside that region.

35:09 So I think that's kind of like the, that's like the elevated top.

35:13 Regions are like Rust, but better for Python programmers.

35:15 Regions are like Rust, but better for Python programmers.

35:16 Yeah, yeah, sure.

35:17 And if you want some other thread to have access to it, you've got to make all the things in that region and let go of it

35:23 so that it can be transferred ownership over to the other thread and so on.

35:28 Yeah, it's an interesting idea.

35:32 Like I said, I feel like it's powerful, but I feel like it might be a bridge too far, you know?

35:36 I don't know.

35:37 Yeah, I think that, again, immutability came up here.

35:41 They even had some talking about, like, being able to freeze regions.

35:45 And so, like, you create a region of objects and then freeze the entire region of objects,

35:50 and then none of those references can get modified.

35:53 And so the whole freeze protocol discussion kicked off again.

35:57 Yeah, so maybe something to look forward to for each protocol in Python.

36:01 Yeah, the region-based ownership, It was definitely an interesting. I feel like, yeah, like, like you said, there's, there's a bunch of people that were asking questions about like, how much is the benefit? Yeah, it's, it's this different, like to, to take advantage of it, you would have to change your code slightly. So it's not just this like free thing that happens. It's more of like, okay, if you're like a library or project that really wants to take advantage of tons of parallelism, you would use these features. It wouldn't be just like, oh, every Python programmer, once they upgrade, they just get a bunch of free performance.

36:32 No, no, of course not. Of course not. Yeah. I feel like there was some interesting questions,

36:38 like interesting discussion, but for some reason I kind of, I left it out on my notes here, but

36:42 let me see. There was, so one of the things is there's basically four PEPs proposed or at least

36:43 let me see. There was, so one of the things is there's basically four PEPs proposed or at least

36:48 imagined. I don't know if they're actually proposed yet that would make this, this happen, but maybe

36:53 it's coming from a different section, but a different freezing conversation somewhere else.

36:57 but there was the conversation like, okay, well, I've got a list.

37:01 The list has a bunch of pointers.

37:03 Some other thread got a hold of one of the items that's somewhere in the list,

37:08 but I freeze the list.

37:10 And so the list is frozen, but then you still have this object graph that has leaked some of the mutable data.

37:20 So you could use that one pointer to one part in the array and you could be making changes to it.

37:24 So there's like this discussion of object graphs as their whole becoming invalid or like they're becoming problems with like trying to share those that were not obvious, right?

37:35 Like really subtle programming challenges, not a race condition, but kind of a syntactical structure behavior problem that you run into.

37:43 And you can say, well, this section is frozen, but someone got a piece of it.

37:46 So now what do you say about it?

37:47 You know what I mean?

37:48 Yeah, I think the idea with like freezing and regions and all that is it would definitely be tracking the number of references that are held by objects that are outside of the region.

38:02 And so like if you would then try to like freeze an object or freeze that region, it would know that it's being referenced by something outside of a region.

38:10 And it would raise an exception instead of like allowing that to happen.

38:13 Because like right now it would just allow it to happen.

38:16 Whereas like getting an exception that, hey, a race condition is possible in this situation.

38:21 We're not going to let you freeze this object or freeze this region like that.

38:24 I think that's like a better user experience because if you're using regions, you probably

38:29 want these properties.

38:29 want these properties.

38:32 And that is a big benefit of that proposed idea that what would have been a runtime, either

38:39 race condition or deadlock becomes an exception that tells you this would have been a problem,

38:44 which that's massive.

38:46 yeah so okay interesting my first impression is that it's too much it's too much for the python

38:51 people yeah i'm sort of counting myself i'm not like just throwing shade like i'm sort of counting

38:51 people yeah i'm sort of counting myself i'm not like just throwing shade like i'm sort of counting

38:52 people yeah i'm sort of counting myself i'm not like just throwing shade like i'm sort of counting

38:53 people yeah i'm sort of counting myself i'm not like just throwing shade like i'm sort of counting

38:55 myself in the same group to some degree even though i've done a lot of like block event-based

39:00 style threading still you know no it's it is interesting i think that it is a really good

39:02 style threading still you know no it's it is interesting i think that it is a really good

39:05 idea for them to break the project down into multiple peps instead of trying to like you know

39:09 land this huge jet plane at the very end of the project instead just like try to incrementally

39:14 because I think that it'll be interesting going into the future, seeing how many of these peps

39:20 land, right? Like, will it be all of them? Or will it be one of them? You know, like,

39:24 I think there are some interesting things in this project, even if we don't get the entire

39:29 region based ownership model. Yeah, yeah. Yeah. Okay. Interesting. Jumping back one in time,

39:30 region based ownership model. Yeah, yeah. Yeah. Okay. Interesting. Jumping back one in time,

39:35 we've got number three of nine. So I'm feeling like we're gonna have to go faster.

39:39 Yes, yes, we might have to. This one is really interesting. This was a long

39:41 Yes, yes, we might have to. This one is really interesting. This was a long

39:44 at least a long write-up.

39:45 This is the state of free-threaded Python.

39:48 And the question is, does it make sense to move to the next phase of PEP 703,

39:54 which is, I believe that's the one that defined free-threaded Python by Sam.

39:59 So this was done by, this presentation was done by Matt Page, saying free-threaded Python has come quite far.

40:06 And I believe since actually this was done, this PEP has actually moved forward to say,

40:11 yes, we are moving on, right?

40:13 So this is a bit of the lag that you were talking.

40:15 So this is a bit of the lag that you were talking.

40:15 Yes.

40:16 So I just, I shared a link with you also the, this just came through from the steering council.

40:22 How long ago?

40:23 A day ago from this recording.

40:25 Oh yes.

40:25 We bring you the fresh news folks.

40:27 Yes.

40:29 Where PEP 779 basically removed the experimental tag from the free threaded build.

40:34 And yeah, I think that this presentation probably had a good chunk to do with that,

40:40 where they showed off.

40:41 Here's the state of everything.

40:42 Here's our proof that the community is adopting it at the expected rate at this point in the project, especially like the scientific computing community where like the benefits of free threading are huge.

40:54 We're seeing all this uptake.

40:55 We're seeing within the bounds of the performance allowance for single threaded performance.

41:01 Can we remove the experimental so that we can see this like next wave of adoption?

41:06 That was basically the whole point of Matt's.

41:08 And it seems like the answer is yes.

41:10 It does seem like it's yes.

41:11 It does seem like it's yes.

41:11 Yeah.

41:12 That's very cool.

41:13 Yeah.

41:14 It means yes for 3.14.

41:16 So what was it, June?

41:18 That means yes in like four or five months.

41:20 Yep.

41:20 Stay tuned in October where you get your stable.

41:23 But please test your betas.

41:24 Which, yeah, we're already in the beta, aren't we?

41:26 Yeah, we're already in the beta phase.

41:28 So test your betas, folks.

41:29 So I guess it's worth pointing out just a little bit for folks who haven't been tracking this

41:33 super closely, like you and I.

41:35 This free-threaded Python's PEP 703 deal, I haven't seen anything like it, but I haven't.

41:42 there might've been other stuff like this and I just didn't notice, but I'm all about the threading.

41:46 So I've been paying more careful attention in that it was accepted, but conditionally marked as experimental.

41:52 And with the caveat that we may take it away from Python later, if we don't like it anymore,

41:56 which is an odd acceptance.

41:59 I thought.

42:00 Yeah.

42:00 That, that mechanism of, I think it was just this, this knowledge that this project would last multiple steering councils and

42:08 multiple years.

42:09 And we were kind of going into the brave unknown a little bit and acknowledging that, that,

42:16 hey, if it doesn't work out, we're going to have to pull it all out.

42:18 And that is unfortunate, but it's just reality.

42:21 We don't know what we're going to experience, what we're going to find.

42:21 We don't know what we're going to experience, what we're going to find.

42:21 We don't know what we're going to experience, what we're going to find.

42:22 We don't know what we're going to experience, what we're going to find.

42:23 It's such a big change.

42:25 And so one of those criteria was it can't slow non-threaded Python down too much, right?

42:32 And it looks like that's within 10%, unless you're on a Mac, then it doesn't seem to matter

42:37 for some reason.

42:38 Apple Silicon.

42:39 Yeah, Apple Silicon is magic.

42:41 But also with memory, right?

42:43 I think it adds a little bit of a memory overhead for extra data structures to track safe reference counting and stuff.

42:50 Yeah, and actually the new acceptance criteria for the next stage actually explicitly mentions the memory allowance.

42:58 This is like in Donghee's new post about it This is like in Donghee's new post about it

43:02 is that there's actually like an explicit number now.

43:04 I don't think there was before.

43:05 I think it was just tracking the CPU performance.

43:08 Yeah, interesting.

43:09 And I guess it's worth pointing out, there's a couple of resources that you highlighted here.

43:14 There's a resource page by QuantSight, which is a big data science crew, that talks about what are the different projects that are relevant, I imagine, to the data science folks.

43:26 And what is their status with supporting being tested, being released for free threading, right?

43:31 And what is their status with supporting being tested, being released for free threading, right?

43:31 Yeah.

43:31 No, these sorts of statuses.

43:33 And there's also one from Hugo, which tracks which wheels have the free threading available

43:39 for just like an easy pip install.

43:41 And in theory, that kind of means that these projects have tested it with free threading.

43:46 Yeah, it looks like we're at 20%, I guess.

43:48 Yeah, we're doing pretty good for this stage of like, it's experimental and it might get

43:48 Yeah, we're doing pretty good for this stage of like, it's experimental and it might get

43:52 ripped away.

43:53 Like that was what it was before.

43:55 Exactly.

43:56 People are trying it out.

43:58 I mean, like, this is how you get proof of people willing to try it.

44:02 I know that inside of the actual Language Summit discussion, they also talked about, like, wanting to dig in deeper into this data, where it's like, okay, the projects support it, but how many users are installing those wheels to kind of show, like, how much is the community testing out free threading?

44:19 Because just because a project supports it doesn't mean that, like, the community is trying it out at the same level.

44:25 Right.

44:25 So maybe that'll be relevant for the future.

44:27 I suppose at least for the ones that offer true rethreaded wheels, you could use PyPI data.

44:27 I suppose at least for the ones that offer true rethreaded wheels, you could use PyPI data.

44:33 Yep.

44:33 The Lime Hall, Google Cloud, BigQuery, or yeah, BigQuery.

44:34 The Lime Hall, Google Cloud, BigQuery, or yeah, BigQuery.

44:36 The BigQuery thing.

44:36 The BigQuery thing.

44:38 There are other ones that are, well, it's just pure Python, so it probably works.

44:42 That's harder to quantify.

44:44 So yeah, basically that change came along here.

44:48 It says we support moving to what they call phase two, something like that.

44:53 So there's multiple phases still, but yeah, excellent.

44:55 So there's multiple phases still, but yeah, excellent.

44:56 talked about this fearless one. We're no longer afraid of it. People are tired of hearing about

45:02 threading for a minute. How about governance? Yeah. So Eric Snow did a presentation entitled

45:08 The Challenges of the Steering Council. That's pretty interesting here. Tell us about this one.

45:13 Yeah. So this one was kind of talking about as a core developer, how is the experience of having

45:20 a steering council governing the development of Python? How is that working out right now? What

45:26 What's the good? What's the bad? And I think the highlights are having a rotating, a completely

45:33 rotating governance set of people on a council. Even if that means that most people are still on

45:39 the council year over year, you still have that whole complete stoppage of time because people

45:44 are starting to kind of like wind down because they know an election is coming. And then,

45:49 so like PEP development gets impacted by that, right? If you're not timing your PEP authorship

45:55 right, then sometimes you just get these huge delays. Also talking about how much the need for

46:02 consensus impacts people's ability to participate in the discussions. So before, you could just

46:09 participate openly. You don't have to worry about like, oh, am I speaking as the steering council,

46:13 or am I speaking as individual or core developer? But now there's such a need for consensus that it

46:19 kind of puts steering council members in a weird spot where they can't participate in the discussion

46:24 unless they've already talked with other people in the steering council or do that as easily.

46:29 And I think there was one more.

46:29 And I think there was one more.

46:31 Yeah.

46:31 One of the thoughts, one of the threads was I had a conversation with somebody who is a core developer,

46:37 but also happens to be on the steering council.

46:39 I felt like we were in agreement on this idea.

46:43 But then when I spoke to them as steering council member, then the story changed a little bit because it was a committee response.

46:51 And you're like, I think Eric Snow himself expressed frustration that like, I've, yeah,

46:56 And you're like, I think Eric Snow himself expressed frustration that like, I've, yeah,

46:58 I've worked on this project.

46:59 I thought we had agreement.

47:00 And then turns out for some reason it wasn't right.

47:03 Yeah, I think, yeah, they, it's really hard to know if you have consensus when the like

47:09 response, right, is delayed because you can't tell then if it's consensus because like the

47:15 discussion is, you know, slowed down and no one's bringing up any new points.

47:18 or if it's because like people have thoughts, but then they have to talk

47:23 to their steering council fellow members.

47:25 And then, you know, it's difficult to judge and you don't really want to tip the hat

47:29 one way or the other during the discussion because you don't want to get people with false hope.

47:34 You don't want to like tell people not to work on something when it's actually going to go through.

47:38 So it's challenging.

47:40 Yeah, two other issues.

47:42 I guess it's also worth pointing out before I say this that Eric said, look, things are working pretty well.

47:47 Python hasn't stagnated.

47:48 peps are getting approved things are happening right so that's good but one challenge is just

47:53 it's slower to get responses about peps and so on because it's volunteer committee work rather than

48:02 one person who can just be the decider you know yeah it's it is really tough and especially and

48:04 one person who can just be the decider you know yeah it's it is really tough and especially and

48:05 one person who can just be the decider you know yeah it's it is really tough and especially and

48:07 one person who can just be the decider you know yeah it's it is really tough and especially and

48:08 this kind of comes through with like here's all these things that are happening to python all at

48:13 once and uh yeah good luck steering council with like trying to make all of those things work

48:19 together because the thing is the steering council wants all of these good projects that

48:23 are having to python to all land and to all have a good time but they all interdepend on each other

48:28 i know that there was like a like people were talking about delegation as like a potential

48:33 solution for this and i think the steering council like loves delegation they want to delegate more

48:38 but they sometimes have an issue with delegation when it comes to these topics that like overlap

48:43 with other big projects that are happening concurrently in Python, where you can't delegate

48:48 someone for free threading because free threading touches everything. And so if you delegate

48:53 something for free threading, then that person is not looking at all the other projects that are

48:58 happening in Python. And that's a problem. Yeah. Yeah. I think another two other things I want to

49:00 happening in Python. And that's a problem. Yeah. Yeah. I think another two other things I want to

49:03 touch on real quick. There's a lot of interesting stuff in this one. One is visibility into what's

49:08 happening in the steering council discussions, right? And that talks, it's a little bit addressing

49:13 the surprise, but also just knowing. Kind of like you did for the language summit, you brought a lot

49:18 visibility and awareness of what's happening there. A lot of this wouldn't be known, especially what

49:23 happened in the discussion, if it weren't for something like that. So Guido pointed out that

49:28 California, where he lives, has the Brown Act, which requires all meetings, like governmental

49:33 meetings, to be open to the public for local governmental groups in charge of infrastructure

49:38 without private deliberations barring personnel issues or something like that right so basically

49:43 there's um regulations or rules for saying like here's how the stuff is open you know maybe all

49:49 the conversations are lives all the meetings are live streamed or who knows you know something like

49:54 that yeah no the there was a lot of different options thrown out there for like how to make

49:54 that yeah no the there was a lot of different options thrown out there for like how to make

49:59 these meetings or the deliberations or decision making of the steering council more open one of

50:04 we don't put out there that like oh maybe they should just be open like everyone can see it like

50:09 a live stream or like the meeting minutes are just you know transcribed instantly and then published

50:14 the next day or whatever like something like that or because right now they publish meeting minutes

50:19 and they're they're getting more regularly doing that like actually getting the meeting minutes out

50:24 on time i know there was like some uh there was definitely some issue with that in the past where

50:29 like the meeting minutes were really delayed and so it's really hard to to keep up to date with

50:34 what actually got discussed.

50:35 You want the 2025 version, not the live stream, but you put your AI assistant in all the meetings.

50:40 Sure, yeah.

50:41 And let it creep meeting notes.

50:44 Honestly, it probably wouldn't be that bad.

50:46 There might be a few things like, oh, you got that wrong, sorry.

50:51 But in general, I think it'd be pretty good.

50:52 And then the last thing here is there was some conversation of like, well, deciding by committee's tough

50:57 and how much of the community should we listen to?

51:00 And somewhere it was proposed that maybe, Maybe things like discuss.python.org.

51:06 We've had polls and people said what they wanted and didn't want, right?

51:10 And Barry wisely points out, like, polls are useful, but there's a whole bunch of people, millions of users,

51:16 that are not participating in discourse.

51:19 And I just want to take a moment to, like, restate.

51:24 I think that Scott Hanselman has such an amazing topic or idea here where he talks about the dark matter developers, the unseen 99%.

51:32 and I'll link to this.

51:33 So obviously we know what dark matter is in astronomy, but like these are people who just go to their jobs.

51:38 They don't spend their evenings on discussion boards.

51:41 They don't go to conferences and participate in panel discussions.

51:46 They're not on social media.

51:47 They just use Python or whatever language and they do their thing and it matters deeply to them,

51:52 but you won't ever notice them in these polls or PSF surveys or whatever

51:57 because they just don't do those things.

51:58 There's probably a good chunk of them.

52:00 Yeah.

52:00 And the steering council has the difficult job of representing these folks too, because

52:05 they try to do what's best for Python.

52:07 And that's for everybody, not just people that vote and polls on Discord.

52:10 Right, right.

52:10 That's what Barry was saying.

52:11 It's like, it's tricky though.

52:12 It's like, how do you measure that?

52:13 You know what I mean?

52:14 Yeah, it is super, super tricky.

52:16 All right.

52:17 All right.

52:17 All right.

52:18 Packaging.

52:19 Yeah.

52:19 So this one was really quite a quick talk or it was mostly just talking about, hey,

52:23 this PEP is happening.

52:25 The packaging governance process.

52:26 I know that this got discussed a lot more in the packaging summit.

52:30 Here, I think it was mostly just like, hey, this is happening.

52:33 Here's what the steering council needs to know.

52:35 Here's what core developers need to know.

52:37 This whole thing came out of the wheel next directive, which is like wheel next.dev.

52:42 They've got their own website.

52:44 And it's basically trying to adopt the steering council model, but for packaging, because right

52:50 now packaging peps tend to be delegated to like one or two people.

52:54 And obviously, if things 10x or 100x in complexity and concurrent projects, it is just not possible for one person to just be doing that work.

53:03 And so trying to adopt a council model, similar to the steering council.

53:07 And I think the biggest open questions right now are things like, how is that initial council and how is the voting body going to be formed?

53:15 Because the voting body for the steering council is core developers.

53:18 But what is the voting body for Python packaging?

53:20 But what is the voting body for Python packaging?

53:22 Right, exactly.

53:23 And again, it runs into some of the issues of sort of delegating, but packaging touches

53:28 everything and so on.

53:29 Yeah.

53:30 Tricky.

53:30 Okay.

53:31 Excellent.

53:31 And you referenced this one, Python Unmobile by Russell, Keith McGee and Malcolm Smith.

53:34 And you referenced this one, Python Unmobile by Russell, Keith McGee and Malcolm Smith.

53:35 And you referenced this one, Python Unmobile by Russell, Keith McGee and Malcolm Smith.

53:36 I just had Russell on the show not too long ago to talk about some of this work as well.

53:41 But he says, after many years, this year, I can say that Python Unmobile is there, met

53:46 with a large round of applause from the room.

53:48 Yep.

53:49 Yeah.

53:49 It was it was an awesome moment, especially because I covered kind of like one of the last status reports before the big hurrah.

53:56 We did it with Russell and Malcolm.

53:59 Yeah, basically both of the peps for Android support and iOS support are finished.

54:04 And they are tracking really, really close to basically adding tier two support for iOS and Android to Python.

54:11 And tier two support basically means that if any feature change or bug fix or anything ends up breaking support for that platform,

54:19 then a release can't proceed.

54:21 So the platform basically needs to be supported for a release to happen.

54:24 And that's a huge deal because it means that people can be confident that support isn't going to just be taken away

54:30 or not surprised it doesn't work, which is great.

54:33 or not surprised it doesn't work, which is great.

54:33 So basically it just means there's a whole new, hopefully a whole new set of users

54:38 that can use Python to build on these mobile platforms.

54:40 Yeah, that'd be great.

54:41 So specifically PEP 730 and 738, meaning that CPython builds and runs on iOS

54:48 and builds and runs on Android, right?

54:50 And that the core development team considers breaking that build part of breaking Python, right?

54:59 There's still work to be done in terms of tooling, right?

55:03 Like I'm not going to get a Python plugin for Xcode and drag a storyboard across

55:08 and then publish it, right?

55:09 Some of that stuff is coming from the Beware team backed by Anaconda, which is great.

55:14 But I think this announcement is like the runtime CPython bits are in place.

55:19 the runtime CPython bits are in place.

55:20 Yeah, definitely.

55:21 So like, yeah, it's not like, oh, suddenly Xcode just works and you can just write an Xcode project in Python

55:28 just as easily as you would write, you know, a web app in Python.

55:31 But yeah, the fact that it works at all, like the fact that you can run it on an iPhone

55:34 like the fact that you can run it on an iPhone or on an Android phone, like that's huge.

55:39 And the core developer team is willing to say, And the core developer team is willing to say,

55:42 yeah, this is going to keep working.

55:43 They should.

55:44 It's not a flash in the pan, these mobile phones.

55:48 Some people use them.

55:49 Allegedly.

55:51 Allegedly.

55:51 How many do I have around me?

55:53 I know.

55:55 As I have one in view.

55:57 Yeah, exactly.

55:57 Where's the iPads and all the other stuff?

56:00 Yeah, if I never see Xcode again in my life, I would be too soon.

56:04 It's just such a bad, bad piece of software.

56:06 It's such a bad tool for building software.

56:08 I've had to work with a lot for our mobile apps.

56:10 I've thankfully not have to dealt with any app development yet I've thankfully not have to dealt with any app development yet

56:13 in my career. It's been all web development.

56:17 It's such, you don't appreciate the freedom that you have. I know open source means freedom in some ways,

56:24 but just the ability to go, I made a change. I published it.

56:28 The world has it. It's not like I've had a debate with random people The world has it. It's not like I've had a debate with random people

56:32 who are in a hurry and don't care about what I've built, and then they tell me that it infringes

56:36 on something somebody else built, even when that's actually not true, because they don't understand

56:40 what it does. That's even outside. A lot more people involved in mobile publishing. And rules

56:41 what it does. That's even outside. A lot more people involved in mobile publishing. And rules

56:43 what it does. That's even outside. A lot more people involved in mobile publishing. And rules

56:48 that don't align with your incentives. Like we want to extract money from you. Anyway, that's a

56:54 long story of through app in-app purchases. Yeah. Okay. Another one, I hinted to this, like,

57:01 are we going to need to change the name of CPython? Because CPython means literally the C language

57:07 implementation of python what a core developers want from rust and do they want rust in their

57:12 c python you know is this a uh reese's pieces reese's peanut butter cup sort of thing you got

57:18 your rust in my c or something yeah yeah yeah uh yeah this was this was a really interesting one

57:22 your rust in my c or something yeah yeah yeah uh yeah this was this was a really interesting one

57:25 because i think that um the room was maybe a little bit surprised by like how like open uh

57:32 core developers were about maybe the idea of something optional being in cpython that is

57:39 written in rust um because like cpython there's the core runtime right there's the syntax there's

57:44 the interpreter there's all that stuff that like everyone uses on every single python session but

57:49 then there's also all these standard library modules uh like os and sys and ssl and all of

57:56 these other libraries right and those modules are kind of their own thing they're their own little

58:02 project that just happens to live inside of cpython and i think the result of all of this

58:08 conversation of like oh what what does what do core developers want from rust was like hey let's try

58:14 let's try something uh maybe having a standard library extension module written in rust and like

58:20 what would that take what would that look like um would we need to change the build system would we

58:25 need to you know what would actually need to happen for for that to be a possibility um and i think

58:30 there's some like huge benefits to having rust I mean David talked about a whole bunch of them

58:35 where it's like this it's this new language there's lots of new programmers that are interested in it

58:39 has all the memory safety stuff it has all the performance stuff and also yeah brief threading

58:42 has all the memory safety stuff it has all the performance stuff and also yeah brief threading

58:42 has all the memory safety stuff it has all the performance stuff and also yeah brief threading

58:43 has all the memory safety stuff it has all the performance stuff and also yeah brief threading

58:44 works really great with it there's just like tons of benefits to to having rust be a part of like a

58:50 python python developers toolkit it's like how can we can we also have that in the cord for libraries

58:57 and I think the answer was like try it out and see what happens and maybe who knows right like

59:03 they definitely like core developers caveat it as like it'll definitely have to be an optional part

59:08 of the standard library because not everyone is going to be using Rust on CPython and yeah maybe

59:16 not one of the core parts of this of the actual of the interpreter in the runtime because they're

59:22 they're quite well used and well maintained right now.

59:26 So we'll see.

59:27 I think it's going to be interesting to see if, if David and some other interested folks will,

59:31 will put together something like a standard library module that uses rust.

59:34 Yeah.

59:35 Maybe in 2035, we'll still be doing this.

59:36 We'll still be talking about, but we'll be talking about how the C adaptive layer to integrate with rust is

59:43 working.

59:43 So we can still keep all these C extensions running instead of the other way

59:46 around.

59:47 Yeah.

59:47 Yeah.

59:48 A couple of interesting takeaways.

59:49 David points out, our best estimate is that somewhere between a quarter and a third of all native code being uploaded to PyPI for new projects is using Rust.

59:58 Yeah, so this uses like, basically use this, it's py-code.org, where it can introspect into Python, like packages, the actual files that are uploaded, and then looks for Rust.

01:00:11 And so like any package that is using Rust and it's a new package or a new release,

01:00:17 you can see like what percentage of new projects are using Rust versus like C or C++ or something else.

01:00:24 So David was able to extract that data point.

01:00:28 Yeah, there's a lot of Rust happening for new projects.

01:00:30 Obviously, old projects are likely very C, C++ dominated, but what are new Python developers choosing to use?

01:00:35 but what are new Python developers choosing to use?

01:00:36 but what are new Python developers choosing to use?

01:00:37 Yeah, they didn't choose C.

01:00:39 They just chose not to rewrite it in Rust yet, which is a different barrier, I suppose.

01:00:45 Not saying they should, but I agree that choosing new projects is an interesting metric.

01:00:51 So a couple other things from here is like, should we rewrite CPython in Rust?

01:00:56 There's a lot of people like, or a lot of comments of like, there's a lot of people who just don't want to learn Rust.

01:01:01 They don't care about Rust.

01:01:02 This is a challenge for CPython is that the core developers in particular

01:01:07 have a special skill of writing C and writing CPython in particular.

01:01:12 And this moved the cheese for a lot of folks.

01:01:15 And they like, how much do they care, right?

01:01:16 Like they took Rust on Linux, Rust in Linux core as an example, right?

01:01:22 People just, they don't want to change, which I'm not saying they should, but.

01:01:25 Yeah, it's a really difficult question, Yeah, it's a really difficult question,

01:01:27 especially when there's like this really tight ownership of like one or a few people

01:01:33 with like this very specific part of code.

01:01:35 And, you know, they've been maintaining it since for a really long time,

01:01:39 and it's hard to try to force that sort of change onto people.

01:01:43 But then things that are new or things that are optional, that's a really great place to start.

01:01:48 I think learning from the Rust and Linux project is a really great idea for Python,

01:01:55 because it's in a lot of ways, even though Linux maybe is an order of magnitude more complexity,

01:02:00 I think that the situation or the structure of the code in the project is pretty similar,

01:02:06 where there's like this really big core.

01:02:07 And then there's like a ton of different smaller sub projects that are all have

01:02:11 their own little owners, governance, contributors happening in the background.

01:02:15 Yeah.

01:02:15 A hundred percent.

01:02:16 I mean, it is, it is 2025.

01:02:19 We could try, try again.

01:02:21 I mean, we could just vibe code it like, Hey, cursor, rewrite CPython and Rust,

01:02:25 or you go to jail.

01:02:27 Is that the meta these days?

01:02:28 Is that the meta these days?

01:02:28 Is that the meta these days?

01:02:30 That's there's this really great video.

01:02:33 Senior engineer tries vibe coding.

01:02:34 It's always telling it, like, if it doesn't do it, it'll go to jail.

01:02:38 But also it says, please, like, or you go to jail, please.

01:02:41 It's amazing.

01:02:42 I mean, as much as I joke, honestly, I do think AI code assistance could help in supporting

01:02:49 the transition.

01:02:50 I know that's good at C and it's good at REST.

01:02:52 Not that you should vibe code it.

01:02:53 That's not what I'm saying.

01:02:55 But anyway, we live in weird times, Seth.

01:02:58 We do.

01:02:58 We really do.

01:03:00 I think the other constraint here that maybe a lot of people don't track is that it's not just, I need to somehow make CPython work on Linux, Windows, and Mac.

01:03:12 And if we build it in Rust, that's a different tool chain.

01:03:14 There are a bunch of edge cases and platforms that are not very commonly used that maybe Rust itself doesn't even support that Python has promised to keep running on, right?

01:03:25 Yeah.

01:03:26 Or, I mean, even if not promised, right?

01:03:28 Like there's people that are just running, running on these platforms.

01:03:29 Like there's people that are just running, running on these platforms.

01:03:30 Like there's people that are just running, running on these platforms.

01:03:32 And then if something would break, they would only show up when something breaks.

01:03:36 And what do you do?

01:03:38 Right.

01:03:38 Like you've been supporting these people for a very, very long time.

01:03:39 Like you've been supporting these people for a very, very long time.

01:03:39 Like you've been supporting these people for a very, very long time.

01:03:42 And what, what, what happens then?

01:03:44 What, what was stability guarantees?

01:03:45 Do you give those people that, you know, maybe you're not like a tier one platform, but if

01:03:50 Do you give those people that, you know, maybe you're not like a tier one platform, but if

01:03:50 you've been, you know, making them use like they've been using Python totally normally

01:03:51 you've been, you know, making them use like they've been using Python totally normally

01:03:54 for all this time.

01:03:55 What does that mean?

01:03:56 So, yeah, well, we just talked about tier three iOS and Android.

01:03:56 So, yeah, well, we just talked about tier three iOS and Android.

01:03:58 support like does it work there i maybe i don't know but you've got like this little micro python

01:04:05 circuit python chip that i got that's like i don't know like size of a thumb or something

01:04:10 does the build system work for that i don't know yeah but i'm running python on it today yeah i

01:04:14 does the build system work for that i don't know yeah but i'm running python on it today yeah i

01:04:15 think that like one of the things that got identified was the state of gcc support for

01:04:20 rust as as like something interesting so that's something to track if you're if you're interested

01:04:25 in Rust and CPython working together, that's definitely like a project that's outside of Python and Rust's,

01:04:32 like, and, you know, Maturin and PyO3s if you want to watch that project.

01:04:37 Yeah.

01:04:37 Did say we need to go faster.

01:04:39 Lightning around.

01:04:41 Close things out here.

01:04:42 I guess there's really, there's just the Pyodide.

01:04:45 We didn't talk about the docs or the lightning talks.

01:04:48 What else should we say before we call it a wrap on this?

01:04:51 Should we go, let's go into the lightning talks and look at Guido's.

01:04:55 I think that one was the most well-received and interesting lightning talk,

01:05:00 which is contrasting how Python is developed today which is contrasting how Python is developed today

01:05:02 which is contrasting how Python is developed today versus how it was developed by Guido

01:05:08 and what sorts of things are we kind of like leaving behind by developing Python in this way?

01:05:14 And is there anything that we can learn from how we use it?

01:05:16 And is there anything that we can learn from how we use it?

01:05:17 Does he mean more committee, more community agreement?

01:05:19 Does he mean more committee, more community agreement?

01:05:21 Or what was he getting at?

01:05:23 I think it's the complexity side was the part that was really big for him, where it's like,

01:05:28 we're trying to, if you want to land a feature in CPython, you need to write a perfect pep,

01:05:35 come with a pull request that is, you know, performant and secure and the API is perfect

01:05:42 and it's been vetted and it's been used. And like, there's this super, super high bar to clear,

01:05:47 to add a feature to see Python.

01:05:51 And you're not allowed to get it wrong.

01:05:53 The first go around basically is I think was what he's mostly mentioning.

01:05:57 Because demanding perfection means it's like the, the code equivalent of don't let good be the enemy or the perfect great be the

01:06:05 enemy of the good or something like that. Right. Sure. Yeah, exactly. Yeah.

01:06:07 enemy of the good or something like that. Right. Sure. Yeah, exactly. Yeah.

01:06:08 Stuff like that where it's like, Hey, we, if, if Python were developed in that way early on,

01:06:13 it wouldn't have worked out because that would still be in the lab or an idea

01:06:16 it wouldn't have worked out because that would still be in the lab or an idea

01:06:16 it wouldn't have worked out because that would still be in the lab or an idea

01:06:17 or something exactly so i think that's a really interesting one to check out if you're looking at

01:06:21 lightning talks okay cool now i i know some features have to be absolutely dead center in

01:06:22 lightning talks okay cool now i i know some features have to be absolutely dead center in

01:06:28 the core of the cpython runtime like free threading or a no GIL initiative or some new memory model

01:06:35 or whatever but a lot of these things probably certainly with the standard library could maybe

01:06:41 You talked about the immutable, the thread-safe concurrency data structures.

01:06:46 Maybe there's a more formalized path of starting these things as third-party libraries on PyPI.

01:06:53 And once they reach a certain bar maybe of adoption and maturity, then they make a step towards that.

01:06:59 It would be interesting if, I know people can just go and create a project and do it,

01:07:02 but like here's the prescribed way of non-C runtime features being added to the language.

01:07:09 and it starts out in public and it makes its way over.

01:07:13 Yeah, I think that got discussed in the last language summit too.

01:07:16 I'm not sure if there's been any progress on like actually making a solid model

01:07:20 for like here's how you go from PyPI to PEP to standard library.

01:07:24 But it's definitely, I think it's just going to keep coming up until that happens.

01:07:28 Because it's really common, right?

01:07:29 Like so many features get developed this way now.

01:07:32 It's also interestingly, some of the ideas of that direction have been rejected,

01:07:37 like moving requests into cpython standard library was rejected because it would harm the growth and

01:07:44 status of requests not cpython even though request is clearly better than what's built into cpython

01:07:50 for your access you know not throw no shade that stuff's been around for a long time but yeah i

01:07:54 for your access you know not throw no shade that stuff's been around for a long time but yeah i

01:07:54 mean request is built on it so it obviously does some job well yeah yeah exactly it's just like a

01:07:59 mean request is built on it so it obviously does some job well yeah yeah exactly it's just like a

01:08:00 more user-friendly higher level api in front of it and we have httpx for like concurrent basically

01:08:07 asyncio requests equivalent.

01:08:09 So there's certainly history or examples of stuff starting out there becoming very popular

01:08:15 but not wanting to go in, but specifically things that you might want to.

01:08:19 Like, for example, would data classes be a thing if Pydantic was on a trajectory

01:08:24 to sort of fill that role or adders from Hennig to sort of fill that role or adders from Hennig

01:08:27 or something like that, right?

01:08:29 Maybe not, I don't know.

01:08:30 Yeah, no, I think that that whole road of experimentation and then moving into the standard library,

01:08:35 like, we're just going to keep seeing it because it's just, it's such a great way

01:08:38 to get stuff in the hands of users really, really quickly.

01:08:41 Yeah. And I don't think just like, if I just went out and made a library,

01:08:44 said I'm doing a library and I think it would be fun to have this as part of Python.

01:08:47 Like people go, good for you, Michael.

01:08:49 They would ignore it. Right.

01:08:51 But if it was a little bit blessed by the steering kit, like we're experimenting and considering this idea

01:08:57 as core developers, it starts here, but if it gains traction, it becomes Python.

01:09:01 I think that is a different positioning than just like a random project that looks interesting.

01:09:07 Yeah, definitely.

01:09:08 I think that last year, one of the things that got suggested was like, hey, maybe we allow people to have those sorts of projects

01:09:15 once they reach some amount of maturity and like direction to be housed under the Python GitHub org

01:09:22 to try to give them some sort of like legitimacy of like, to try to give them some sort of like legitimacy of like,

01:09:23 to try to give them some sort of like legitimacy of like, yeah, this project is on the track to going here

01:09:28 and here's us showing that it is, right?

01:09:31 Yeah, yeah, yeah.

01:09:32 I feel like I should just say one more thing though.

01:09:34 I do think there's a lot of value in having Python be smaller and having a bigger ecosystem outside of it.

01:09:42 I'm not suggesting that everything should just be moved in into Python.

01:09:45 I do think that just go like, I don't care what CPython does.

01:09:48 If I like this HTTP library, I'm going to use it.

01:09:50 And if it wants to implement itself in Rust or OCaml or whatever, I don't care.

01:09:54 If that's better, they can go do that.

01:09:57 And then I'll use it and it'll be great, right?

01:09:59 and that doesn't have to go through committees and all this kind of stuff.

01:10:03 So I'm not necessarily saying like everything should try to like find a hub

01:10:07 and spoke model into the core Python, but those things that do intend to be there,

01:10:11 it'd be cool to see like this sort of progressive path.

01:10:14 People can get to it sooner. Anyway. Yeah.

01:10:16 Final thoughts on that before we call it a show.

01:10:18 I think we nailed it. Honestly.

01:10:21 No, we definitely did. We definitely did. Yeah, no, let's, let's wrap it up. Thank you for doing this. This writeup.

01:10:29 It's really interesting.

01:10:30 I always value this look into, you know, to where's Python going.

01:10:33 It's a lot to take from it.

01:10:35 Final thoughts on this year's Language Summit?

01:10:38 It is a really exciting year to be a Python developer.

01:10:41 I think that 3.14 is, it's got so many really interesting things and changes to try.

01:10:48 I am quite excited to get my hands on the beta, but then also the stable releases.

01:10:53 I really am excited to see what people actually then go and do with the stuff, right?

01:10:58 like building web apps with Python, building mobile apps with Python, building these massively parallel

01:11:04 applications with Python.

01:11:05 It's a pretty good time to be a Python developer right now.

01:11:06 to be a Python developer right now.

01:11:09 It's only getting better.

01:11:10 Absolutely.

01:11:11 All right, Seth.

01:11:11 Thanks for being back on the show and thanks for doing the write-up.

01:11:14 Thanks for having me.

01:11:15 Yep. See you later.

01:11:16 This has been another episode of Talk Python To Me.

01:11:19 Thank you to our sponsors.

01:11:21 Be sure to check out what they're offering.

01:11:22 It really helps support the show.

01:11:24 Take some stress out of your life.

01:11:26 Get notified immediately about errors and performance issues in your web or mobile applications with Sentry. Just visit

01:11:33 talkpython.fm/sentry and get started for free. And be sure to use the promo code

01:11:38 talkpython, all one word. Want to level up your Python? We have one of the largest catalogs of

01:11:43 Python video courses over at Talk Python. Our content ranges from true beginners to deeply

01:11:48 advanced topics like memory and async. And best of all, there's not a subscription in sight.

01:11:53 Check it out for yourself at training.talkpython.fm.

01:11:57 Be sure to subscribe to the show, open your favorite podcast app, and search for Python.

01:12:01 We should be right at the top.

01:12:03 You can also find the iTunes feed at /itunes, the Google Play feed at /play,

01:12:08 and the direct RSS feed at /rss on talkpython.fm.

01:12:12 We're live streaming most of our recordings these days.

01:12:15 If you want to be part of the show and have your comments featured on the air,

01:12:18 be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:12:23 This is your host, Michael Kennedy.

01:12:25 Thanks so much for listening.

01:12:26 I really appreciate it.

01:12:27 Now get out there and write some Python code.

01:12:51 *music*