#475: Python Language Summit 2024 Transcript

00:00 Every year the core developers meet to discuss and propose the major changes and trends in Python itself.

00:05 This invite-only conference of about 50 people happens inside PyCon in the US. Because it's private,

00:12 we rarely get detailed looks inside this event. On this episode, we have Seth Michael Larson here to give us his account of the sessions and proposals.

00:21 It's a unique look into the zeitgeist of CPython. This is Talk Python to Me, episode

00:27 275, recorded August 22nd, 2024.

00:31 Welcome to Talk Python to Me, a weekly podcast on Python.

00:47 This is your host, Michael Kennedy. Follow me on mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both accounts over at fosstodon.org.

00:58 And keep up with the show and listen to over nine years of episodes at talkpython.fm.

01:02 If you want to be part of our live episodes, you can find the live streams over on YouTube.

01:07 Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows.

01:13 This episode is sponsored by Posit Connect from the makers of Shiny.

01:18 Publish, share, and deploy all of your data projects that you're creating using Python.

01:22 Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quatro, Reports, Dashboards, and APIs.

01:28 Posit Connect supports all of them. Try Posit Connect for free by going to talkpython.fm/posit.

01:36 And it's also brought to you by us over at Talk Python Training. Did you know that we have over

01:43 150 hours of Python courses? Yeah, that's right. Check them out at talkpython.fm/courses.

01:49 Hey, Seth. Welcome back to Talk Python to Me.

01:52 >>Hey, Michael.

01:53 >>Awesome to have you here. I'm really excited to get a look into the zeitgeist of the core

02:00 devs and the people building Python for us through the Python Language Summit.

02:05 >>Yeah, let's do it.

02:07 So we're going to talk about the 2024 Language Summit that happened in Pittsburgh.

02:12 It's like an embedded mini conference inside of PyCon, which is smart rather than trying to travel

02:18 all over. But before we get into that and all those things, I know you've been on the show not

02:22 too long ago, but for those who may have missed your introductions, who are you?

02:26 What do you do for Python these days?

02:28 >>I'm Seth Larsen, and I've been working at the Python Software Foundation for a little over a

02:33 year now as the security developer in residence. And so that means that I do a lot of stuff

02:38 related to security just for the entire Python ecosystem. That's CPython, pip, packaging

02:44 ecosystem, like outwardly facing things for PyPI, maybe not as much the internals. I leave that for

02:51 Mike Fiedler, the PyPI safety and security engineer. And I maintain a lot of open source

02:55 projects specifically in like the HTTP and internet space. So like requests, urllib3,

03:02 Trust Store, things like that.

03:05 >>Oh, awesome. Yeah. Thanks for everything you're doing there. And how's the role working out? I

03:10 know this is one of, you were the first person in this role, like officially, right? Is that true?

03:14 >>That is true. Yeah. I was the first security oriented hire at the PSF. It's been going really

03:21 great. I mean, I feel like we've made a lot of improvements and there's a lot of exciting stuff

03:27 that I'm working on today. And I don't know, I think one of the things that also got highlighted

03:32 because this role exists, it just means that more people at the PSF and in CPython core team and

03:39 just in the Python ecosystem in general are talking more about security. And like, that's just as

03:44 important as the stuff that I'm doing day to day is that it's just, there's just more awareness of

03:49 what's happening in security.

03:50 >>Yeah. So I have two polar opposite thoughts here. One is I'm really surprised how few

03:57 significant issues there are in Python, CPython, you know, the interpreter, the runtime, the

04:05 standard library, all that. It's really rare that you get a, you know, red light splashing. Oh my

04:11 gosh, go patch your systems now. There's sometimes really minor things like this audit trail is not

04:19 completely followed under this condition, but that's not a, the pager goes off and you know,

04:23 cause you got, it's now a race. That's one thing. So that's awesome. Right. That the other is

04:29 PyPI, typo squatting, all the, all the stuff that makes Python extra good, the half million

04:37 packages and other shady things people do. And we're going to talk about this in the broader

04:41 sense, not PyPI, but you know, in the open source space of like, well, what if, what if somebody

04:46 took over a GitHub account for a little while or, or something? Yeah. So, and that's not on fire,

04:53 but that's, there are battles being waged actively there, I would say. Right. So it's a

04:59 contrast, right?

05:00 >>There, I can speak with confidence that there is malware on PyPI right now as we speak, but

05:04 like, yeah, so that's, that's the case. Right. I think it really has to do with CPython is an

05:09 incredibly mature project in like every sense of the word, like governance, security, design, all

05:17 of these things. Right. And like, there's just a huge amount of people and resources being, being

05:22 work, like working on CPython at any one moment and like contrast that to the, you said half a

05:27 million, you know, I tend to focus on the like 95% of downloads by totality. Right. Because

05:35 there, there's a lot of projects on PyPI that maybe don't have the supply chain criticality of

05:40 others. Right. But yeah, absolutely. A hundred percent. And when you, I think when you hone in

05:45 on that smaller window of projects it ends up being a much better picture than

05:50 >>I think it's, I think it's a hundred percent good picture. Honestly, there are legitimate bugs

05:56 that people have to deal with. Like, you know, maybe there's a Django release that says we

06:00 didn't validate the CRF token in, in this particular form. So you should update your Django.

06:06 Right. And that's, that's just a legit bug. That's not people attempting to do bad things.

06:10 >>I mean, I can't even take really any credit for how secure and mature CPython is. I'm such a

06:16 late addition in the life of CPython and like PyPI projects. So it really is the community. I

06:23 think it is just, there's so much investment and so much love and care happening in all these

06:27 projects that it does speak volumes. But that, I mean, that doesn't mean that we need to think

06:32 that things need to be perfect or that it's necessarily a bad thing to have a vulnerability

06:36 in a, in a project because there's projects that are even more mature than CPython that have

06:42 vulnerabilities all the time. It's totally normal. I think the important thing is just like knowing

06:46 what to do when that happens. And that's where I come in.

06:48 >>Yeah. I don't want to belabor this because you know, the security angle, while interesting to me

06:54 and central to what you're up to is not the topic, but I do think it's interesting that the White

07:00 House recently came out. I think it was the White House. It said, we recommend Python and a couple

07:05 other languages. We basically, we, we recommend memory safe languages, which did you see that

07:10 post? You must have, right?

07:11 >>I certainly did. And I actually had a, a big part of recommending that to the White House. So

07:17 when the...

07:18 >>No kidding. I had no idea.

07:20 >>Yeah. Yeah. So the, the PSF, we responded to the request for information that CISA put out or the

07:26 office of the cyber director put out, I think a year and change ago. And in that post, we recommended

07:32 CPython and Python in general as a memory safe language and went into all the details about like,

07:38 yes, it's written in C, but like the language itself, what people will actually be programming

07:43 in is Python. And we also emphasized how Python is a bridge into memory unsafe languages. And because

07:51 of all the focus on performance lately, it's actually like sometimes in some cases more

07:55 performant to keep the code written in Python as opposed to writing it in C. And so we emphasize a

08:01 whole bunch of stuff. And so I think that that had a small percentage of the reason why that was

08:06 recommended as...

08:07 >>Put it on the radar and positioned it correctly, maybe.

08:10 >>Exactly.

08:11 >>Awesome. Well, congratulations. I was just going to say that's kind of interesting, but there's

08:15 way more to it than that.

08:16 >>There's a lot happening behind the scenes. Yeah, yeah, yeah.

08:20 >>Yeah, there is. All right. Shall we talk about this language summit thing?

08:23 >>Let's do it.

08:24 >>Let's do it. So let's just, I mean, I gave it sort of a vague intro. You wrote a nice blog post

08:31 about it here on the Python blog. Just give us a sense of what the language summit, what is it for?

08:38 Is this something, is it like an open space I can go to or not?

08:42 >>No, so it is a specific space for Python core developers to use. And so I think the whole goal

08:52 of this is to get a bunch of core developers in a room together to discuss things and to kind of get

08:59 some recommendations, some ideas flowing maybe without necessarily like having the full formed

09:07 thought, right? Because like putting something out there, like completely radically changing the

09:11 direction of Python, that's a lot to put that out just publicly, whatever. And so this is like a

09:17 place to collaborate for core developers and some special guests, because not everyone that's there

09:22 is a core developer, but it is invite. So you have to like apply to go and say why you want to go.

09:27 >>Yeah. I think just folks who were, I can't remember if it was Sebastian Ramirez or Samuel

09:34 Cullinan or something around the typing thing. I remember some of those folks might've been at one

09:38 of them because they're like, wait, we can't change typing to be more performant where it

09:42 completely ignores the runtime stuff. Cause we have all these frameworks.

09:45 >>Right, right, right. Yeah. Yeah. But the language summit, it's a whole bunch of different

09:50 like submitted topics. People will talk and then there's discussion and some outcome. Maybe

09:55 there's no outcome. Maybe there's like next steps. Maybe we solve some problems within the time of

10:01 the meeting. And yeah, my job there was to actually like take down all the notes and write about it

10:07 and like publish these blog posts. Cause one of the reasons why this is allowed to be like an

10:11 invite only meeting is that there is someone who is basically taking notes and blogging about

10:17 everything that gets discussed and like what happened during the discussion so that the

10:21 community can learn about what actually happened without necessarily, you know, getting the

10:27 rawness of it, I guess.

10:29 >>Yeah. There's a real careful balance you got to strike between allowing the freedom to say

10:34 whatever without public scrutiny, but at the same time, you don't want it to be like, well, the

10:39 Python cabal met. They've decided.

10:41 >>Exactly.

10:42 >>They don't like, they don't like your idea or whatever.

10:44 >>Exactly.

10:45 >>Yeah. It's cool. So I'll point people, obviously it's going to be in the show notes. When people

10:51 at your write up, it's like a meta post, I guess. Would you say that? It's, it talks about, you

10:56 know, sort of >>Landing page.

10:58 >>Landing page. Exactly. 4, 1, 2, 3, 4, 5, 6, 7, 8, 9. And then 9 topics and presentations that

11:06 were covered. And then the lightning talks, which is also almost like another sub meta section. So

11:11 there's a, there's a lot to explore here and there's nice write-ups on each of these. So where

11:16 should we start? And we want to kind of wrap up the conversation we were just having, because that

11:21 was actually a little bit of a topic at the language summit, right?

11:25 >>Yeah. Security was definitely a topic at the language summit. This, this was somewhat in the,

11:31 in the recent light, like the light of XZ when XZ had happened. Pablo, one of the release managers

11:38 for CPython 310 and 311, I believe brought this topic and it was basically discussing Python's

11:46 like contribution and release and all of that model in the light of XZ. So like XZ, I'll just

11:53 go over really quickly.

11:54 >>Yeah. Yeah. I'm sure people about XZ.

11:55 >>Yeah. I'm sure a lot of people have like heard of it at this point, but.

11:59 >>It was such a long game deal. It was crazy. So yeah. What is, >>That's the scary part.

12:05 >>What is XZ-utils and then what is the XZ-utils security issue?

12:10 >>Yeah. So XZ-utils is a library written in C for basically processing archives of the XZ

12:19 format, which is just a compression format like, like GZIP, like, you know, any other

12:25 compression format, Zotfli, Brotli, all of those. And so this library was maintained by a single

12:32 person, big surprise. And what is relatively little known, right before all of this happened,

12:39 I would say, it was probably just adding features, fixing bugs every once in a while, make a release

12:45 and all of that. And what ended up happening is this project was identified as a project that had

12:53 very few maintainers and also through a series of reasons had a linkage to SSH. And so what

13:02 ended up happening. Yep. And so SSH was , If you can get into SSH and SSHD, then bad things are going to happen.

13:09 >>Yeah. So the whole end goal of this entire operation was to get access to open SSH

13:15 through like linking basically. And so what ended up happening is a bunch of fake sock puppet

13:23 accounts showed up after this loan maintainer indicated that they were having a little bit

13:28 of trouble maintaining the project and like meeting user demands. Like these sock puppet

13:33 accounts show up like days before they were actually used and all kind of in similar fashion.

13:40 And basically are pressuring this maintainer to either make them feel like they're not doing a

13:46 good job or to try to add a new maintainer. In this case, Giotan is the pseudonym that this

13:53 account used. And what ended up happening is over a year of like legitimate positive contribution

14:02 from this account, this account was added as a like equivalent to a release manager, right?

14:07 Like someone who is approving PRs and merging things and is capable of accessing the actual

14:13 archives when releases happen. And then a good chunk of time passes after that. And there's a

14:20 couple of little changes added that on their own are not an attack, but it was preparing for

14:27 an attack where essentially a small change was added into the release archives that was not a

14:34 part of the source tree that activated the entire attack chain. And then when this started to like

14:41 be pulled in downstream into things like, you know, Fedora, early versions of Red Hat, this

14:47 never went into any stable builds, but it was all the pre-releases. This ended up getting onto

14:52 people's machines and then was eventually discovered because of a very small performance

14:57 difference when logging into SSH. - Yeah, and that was somebody who wasn't even looking,

15:03 forgot the person's name, but they worked at Microsoft and they were just, I think on the

15:07 Azure team or something. And they just were like, why did this slow down a little bit? That's weird.

15:11 And they're like, wait a minute, what is this doing in here? Yeah, it was on the verge. And,

15:17 you know, what a long game. One person, one account came along and was just, you know,

15:22 I'm going to hear to help you. I'm just going to make, I'm going to try to just become your

15:26 best friend contributor. And then another one is just abusing, like mentally abusing the people.

15:32 Like, why don't you just quit? Why don't you get some more support? And then like, who, well,

15:35 let me reach out to some people who are helping me out recently. And it turns out these are like

15:40 two sides of the same coin. - Yep, exactly. - Yeah, shady. Okay. Luckily that got caught.

15:45 Cause you know, there's a lot of servers in the world that can be SSHed into and like, well,

15:49 we got, you know, public private key encryption. You can't break through that stuff long as you

15:54 don't use passwords, like you're going to be fine unless you're not. - I received a lovely email

16:01 on the day that this happened, report to the security response team for Python, because we,

16:06 of course, use the XZ utils libraries because Python supports XC format as well. And I,

16:13 there was a, there was a lovely few seconds where I'm like, oh, this is either going to be

16:16 a fine day for me or a really bad day. And it ended up being a fine day. So. - That's good.

16:22 It's like, are we going to be canceling all our plans for next few weeks? - Yeah. Yep. Am I going

16:27 to have lots of questions to answer from like concerned customers, users, but it was fine.

16:33 - Yeah. Yeah. I find this kind of stuff is a lot like everything's fine. You're relaxed. Just

16:38 work's going good. Life's going good. And then, you know, something's on fire, just out of the

16:43 blue and you have this, you know, it takes your breath away moment. Like, oh, does that apply to

16:47 us as well? Because if it does, everything just changed. - Fun times. - Yeah. Really glad I did.

16:53 This portion of Talk Python to Me is brought to you by Posit, the makers of Shiny, formerly RStudio,

17:01 and especially Shiny for Python. Let me ask you a question. Are you building awesome things?

17:07 Of course you are. You're a developer or data scientist. That's what we do. And you should

17:11 check out Posit Connect. Posit Connect is a way for you to publish, share, and deploy all the

17:16 data products that you're building using Python. People ask me the same question all the time.

17:22 Michael, I have some cool data science project or notebook that I built. How do I share it with my

17:27 users, stakeholders, teammates? Do I need to learn FastAPI or Flask or maybe Vue or React.js? Hold

17:34 on now. Those are cool technologies, and I'm sure you'd benefit from them, but maybe stay focused on

17:39 the data project. Let Posit Connect handle that side of things. With Posit Connect, you can rapidly

17:44 and securely deploy the things you build in Python. Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask,

17:51 Quarto, Ports, Dashboards, and APIs. Posit Connect supports all of them. And Posit Connect comes with

17:57 all the bells and whistles to satisfy IT and other enterprise requirements. Make deployment the

18:03 easiest step in your workflow with Posit Connect. For a limited time, you can try Posit Connect for

18:08 free for three months by going to talkpython.fm/posit. That's talkpython.fm/posit. The link is in your

18:16 podcast player show notes. Thank you to the team at Posit for supporting Talk Python.

18:21 One of the talks was Python security model after this issue, the XZ-Utils backdoor. Tell us about

18:28 that. Yeah. So this entire talk was essentially just overviewing like, "Hey, is this possible?

18:35 Is this possible for CPython to be impacted by such an attack?" And I mean, the answer is yes,

18:41 it really is. Because if you have accounts that are willing to put years of effort into

18:47 contributing good code to CPython, right? That is enough to become a core developer likely.

18:54 And if you're a core developer, it means you can merge PRs. It means if you get two core

18:59 developer accounts promoted to this level of authorization, you can merge your own PRs with

19:04 review, right? The big focus on this talk was like, "Okay, how can we prevent this? And in the

19:12 ways that we can't prevent it, how can we be ready?" And kind of like discussing whether or not

19:17 we're ready at this point. And I think the big consensus was that if we were to discover

19:22 something like this that had already been merged into Python or had been released in Python, that

19:27 we would be okay to be able to get the word out. That sort of infrastructure already exists,

19:34 and we're not too worried about that. We're a CNA. We can create a CVE really quickly.

19:38 We can get the announcements out really quickly. We can get releases out really quickly. So in that

19:43 way, the reactive sense, we're okay. In the proactive sense, which is the more important

19:50 one, but it's also the harder one. - Yeah, because when nation states hire people to say the next three years of your job, it's almost like-

19:59 - And it's like a team. - Like a spy, yeah.

20:01 - A team of people for multiple years. - Yes, exactly. It's like the CIA or MI6

20:05 or something, on the code side. - To be honest with you, it doesn't even

20:09 need to necessarily be nation state level stuff for this to happen because vulnerabilities in

20:15 popular pieces of software are very lucrative. You can sell them and people make a lot of money

20:23 on selling vulnerabilities to projects. So why not grow your own, right?

20:27 - Exactly. - Yeah, go ahead.

20:31 - One of the things I think is great is there's a really long release cycle,

20:35 and a staged rollout. So I don't know how many people jump in and install alpha one of some

20:43 Python, but it's pretty limited and it's not gonna make it. No, no, of course, I know,

20:47 I see you raising your hand. However, I don't see that shipping on Ubuntu's update channel or

20:55 Docker's a whole different deal. Let's not even go there. But on the main Docker images.

21:00 - Yeah, yeah. I mean, the slow rollout is definitely a big part of it, right? A lot of

21:06 people get their Python, not direct from the source, they get it from a distribution or they

21:13 get it from, if they, like Amazon Linux with Python or whatever, right? Like it's a distribution of

21:20 Python. - Or brew install or-

21:22 - Brew install Python, yeah. So a lot of people are not living on the edge. And I think that that

21:29 helps in a way. Obviously, people that are living on the edge, maybe they're the more valuable

21:34 targets, but I mean, I'm not gonna be the one to encourage that. Yeah, I don't think that,

21:42 I think the biggest defenses against this, and this was what was discussed there, was

21:47 trying to push things to be in the open. And actually, in a way, open source is uniquely

21:53 able to respond and- - Right, right, right, right.

21:55 - Defend it against for these sorts of attacks. Because if this were to happen in Windows,

22:00 for example, would we have had the almost immediate, being able to debug what the actual

22:07 attack was, how long this had been going on, what patches were bad, right? That sort of visibility

22:14 into the source code is something that was really important in being able to actually track this

22:18 thing down. And so having test files and binary files not checked into source code and instead

22:25 generated. So one of the parts of this attack that allowed it to go hidden for so long and be

22:30 checked into source code was that almost all of the attack code was hidden extremely well in a

22:37 binary file, which made it so that code reviewers- - Some of the test binary elements,

22:42 'cause if you've got a compression file utility, you've got to have compressed files for your unit

22:47 test, right? - Exactly. So it was, basically, these files were checked in and there's just huge binary blobs that you can't actually get your

22:56 eyeballs on to review. We talk about lots of eyeballs make for shallow bugs. Well, if the

23:00 eyeballs can't see the bugs, then you're not gonna find them. And so we talked about removing binary

23:06 files from the source code or making sure that all the binary files that are generated have a

23:11 script that allows them to be generated anytime and things like that. - Is it one of the changes,

23:17 I recently, I can't remember if this was on PyPI or if this is a GitHub thing, but allowing GitHub

23:23 to be the thing that publishes directly, builds the wheels and uploads them to PyPI rather than

23:30 somebody downloading the code, building them and uploading it, which obviously that's a opaque

23:35 step there. - Yeah. So other things that tie more strongly these, whatever release artifacts are

23:43 actually ending up on people's machines to the source code. So that's, I mean, I would call that

23:47 build provenance. There's a whole bunch of different frameworks that that works under,

23:52 but yeah, build provenance, being able to tie in an artifact that's installed in your system back

23:57 to the actual source code so that when you are evaluating that artifact on whether you want to

24:04 install that on your system or deciding whether to upgrade or whatever, you can look at the source

24:09 code instead of looking at this compiled binary. That's something that I really want to focus on

24:13 for PyPI in the future, but yeah, we're not there yet. - Awesome. Yeah. 'Cause when you look at a

24:19 project, you say, well, let me see what the release is on GitHub. If you know that literally

24:23 that was the thing that compiled or got built and then that's what's on PyPI, that's a different

24:29 forensic analysis than somebody's machine. - What it ends up nice, like being nice is that it,

24:36 and this is the tough part is that I feel like a lot of people's behavior, which is to go on

24:41 GitHub and look at the diff between like tags. That's what a lot of people do, but that's not

24:46 actually what you should do. You should be looking at the diff between the artifacts. That's the

24:50 thing that's actually installed in your machine, but that's way harder to do than looking at the

24:54 tags. So adding build- - We just crowdsource it. We're all crowdsourcing it. Like wait for somebody to scream. - In a way we are.

24:59 - I know we are. - In a way we are.

25:03 Just related to this while we're still on this topic, you talked about the, somewhere, there we

25:10 go. There's also big news around CVEs, which are official vulnerability numbering. So they're

25:17 referenced through all those cybersecurity talk and stuff. You can describe it better. So big

25:26 news is that the PSF now, and you alluded to this, is now an official numbering authority. So rather

25:32 than saying there's a problem with Python, who's going to sort of officially call this out and

25:37 write it up and so on, you guys can do that directly now, right?

25:41 - Yeah. So CVEs are basically, it's a set of identifiers and records that show, it's like a

25:48 bunch of metadata about vulnerabilities in software is what it is. And it's only one system.

25:53 There are a bunch of other vulnerability databases, but CVE seems to be the one that everyone uses or

25:58 references. And so what being a CVE numbering authority gives us is it makes it so that

26:05 someone at the PSF can operate the CVE UI and workflow and all of that to say like, "Oh,

26:14 we want to create a new CVE ID on behalf of the Python team or on behalf of the pip team."

26:19 And what that ends up meaning is that because we are part of the process, instead of having to go

26:25 to some other entity, so like Mitre or Red Hat or Microsoft, there's a whole bunch of CNAs. There's

26:31 over a hundred now, I think. Instead of going to someone else that isn't as well-versed in Python

26:39 or our release schedule or any of those things, we get to inject the knowledge that we have about

26:46 Python into all of these records, into all these advisories. And it makes it so that we don't

26:52 actually have to talk to someone else to be able to handle a vulnerability end to end.

26:56 Before, you would potentially have a reporter going to talk to someone else and getting a CVE

27:02 ID, and then they would come talk to us. And by that point, it's hard to make a determination,

27:08 and there's a whole bunch of things that have already happened, and maybe there's

27:10 messes that need to get cleaned up to make sure that it's not confusing.

27:13 So by owning the entire process, we're able to make sure that things are as little confusing

27:19 as possible, like what actually needs to be done for users when we publish these things.

27:23 Yeah, that's great. I want to move off the security angle here, because I know there's

27:29 so much more to talk about. However, you guys, have you considered or ever run any sort of bug

27:35 bounty program? We don't have a bug bounty program right now. I mean, the hard part with

27:39 a bug bounty program is it takes money. So if you would like to see a bug bounty program happening

27:45 at the PSF, get in touch with the PSF. Send an email.

27:49 Yeah, I think incentives are really aligned there. There's a lot of companies that

27:53 have this tooling at the center of their data center. So maybe.

27:57 Yeah, maybe.

27:59 Maybe, maybe we can make it happen. All right, next up, the REPL, or the PyREPL for the Python REPL. What's the deal with this?

28:06 Yeah, so this was a talk that was given by a couple of different core devs. I think this

28:12 included a bunch of people, Pablo, Lukasz, and Lisandro all gave this talk. And it was about,

28:18 hey, this new REPL that's coming in Python 3.13. Here's all the cool stuff that it can do, and

28:26 how it makes the usability so much better for people. And they demoed a whole bunch of the

28:31 new features, which was really exciting. There was lots of applause showing off a few of these, like

28:37 little features. And I think that the other side of it is because this new REPL is written in

28:43 Python and not written in C, it lowers the barrier for contributions and maintenance drastically.

28:50 Before the REPL was super entwined with the parser and all of these other really low level

28:57 details of Python that a lot of people probably didn't want to get involved with if they didn't

29:01 have to, versus this where it's this completely separate and much more easy to contribute to

29:08 piece of software. Yeah. And did this come from the PyPI project? Yes, this was PyPI. And I think

29:15 that there's been some back and forth, contributing back, contributing forward, all of that, which is

29:20 also really great, right? Having one REPL shared between two different implementations. Yeah,

29:25 that's great. Just working better together, more people working on it. I always call it

29:29 PYPY because some people call Python packaging injects, PyPy, but that's also this other thing.

29:36 Anyway. It's a non-zero part of every one of my days, right? I'm sure that is. Because a lot of

29:42 the times, a significant percentage of my work as a security person is being in working groups that

29:47 are not Python related at all. And yeah, there's a lot of PyPys flying around. Yeah. You talk about

29:53 NumPy being on PyPy and you're like, okay, hold on. Hold on. Could be two different things.

30:00 There's a lot going on here. Yeah. So this is really interesting. I haven't really played

30:06 with it much. I honestly don't spend a ton of time in the bare Python REPL. Like if I'm

30:11 REPLing, a lot of times I'm in the JetBrains sort of enhanced REPL that's inside PyCharm,

30:18 something like that. But, and I think partly because there was a lot of challenges with

30:23 the bare Python REPL, right? There's no autocomplete, but worse than that was

30:28 if you've got a five line function and you want to edit it, you've kind of got to go to the top

30:33 part, hit her, like it's, it really was hard to work with blocks of code. There's no color,

30:38 things like that. Yeah. Color is the standard for, you don't have color in your terminal at

30:43 this point. Like even 2020. You've basically given up at that point. If you don't have an emoji and

30:49 you don't have color, I mean. Emojis, color, got to have like the rainbow prompt, maybe like the

30:54 logo of the thing when it starts up. A starship. I didn't even consider the ASCII art and possibly

31:00 the ASCII art in color. No, seriously though, I do think it sounds like a minor deal, but just

31:06 the readability of having highlighting and stuff. Yeah. Syntax highlighting is huge. Syntax

31:11 highlighting is like really huge. That's not a part of the current REPL, I don't think, but like

31:15 it becomes much more possible because this PyREPL exists. Yeah, exactly. Yeah. I think that like

31:23 the biggest thing, yeah, like the whole blocks of code, I just remember the demo of them showing

31:27 like, oh, you have like five lines. You have to hit up, up, up like four times. It's just like,

31:32 oh, if you mess it up, you got to start over. You got to start over and you're just, you're

31:36 just sad. You just contemplate putting it in a file instead of doing this in the REPL. Exactly.

31:41 That's why I'm not in there. I avoid being in there because it's hard. This will be really,

31:45 really great for people that are just starting Python journey. Cause I think that a lot of people

31:49 learning and starting off will use the REPL straight up instead of an IDE. And so like

31:55 having this, there was a big focus on like teachability and documenting it and making it

32:00 work the same. Like if you actually like read the post, like what the discussions were about for

32:05 like everyone is basically totally in favor. They loved it, but they wanted to make sure that this

32:09 was going to be like a consistent experience, specifically like Carol willing had this big

32:14 point about like having a consistent experience being really important for teaching Python

32:19 across different operating systems. So, yeah. And something a little bit,

32:23 a little bit better than up, up, up five times and don't get it out of order. Exactly. Yeah.

32:27 That's cool. Though, I guess one of the, I don't know if this was discussed, but one of the

32:33 challenges of this, I think is it requires, and it's not necessarily bad, but just a challenge

32:37 is I think it requires the new windows terminal rather than say cmd.exe, the older style. So it

32:44 just works out of the box on macOS and on Linux, but on windows, you got to be a little careful

32:48 about how you run it. Is that right? So I actually don't know what the current status of all of this

32:52 is because the time has marched on since these blog posts have happened. And there has been a lot

32:58 of work done on the windows side, the current team, like the team that presented this didn't

33:03 have any windows experience. And so they didn't know really how hard it was going to be. I think

33:09 that there's been a lot of strides in the windows side of things. So I think the situation's better.

33:14 I don't know offhand if cmd.exe is supported or if it's just the new windows terminal, but I,

33:19 I think it's fine. I was sitting in windows terminal. Like people need to be using that

33:23 thing anyway. It's true. It's like opening up on your Mac and just having like the bare white bash,

33:29 I guess it's Z shell these days, but just the completely, you know, non-fixed font.

33:35 Like, what is this thing that you are running? Like, you're like, the terminal is horrible.

33:38 Like, well, that thing is, but you know, you could make it a lot nicer by the way. And,

33:43 you know, it's, it's similar, trade off there, right. In the windows world. So, okay.

33:48 Interesting. Next one is, should we, should we adopt calendar versioning? We're beyond zero

33:57 verse. So that's really good, but there's been a reluctance to have Python four, but we've got

34:04 three, 12 through 13. Are we just going to have 3.1 hundred and 28 or should we come up with

34:11 something else? Right. What is calendar versioning and should we adopt it and how many digits should

34:16 it have? Yeah. So this was, presented on by Hugo, who is the new release manager for Python

34:22 three, 14 and 15, which maybe that's a little presumptive saying those numbers. cause if

34:28 this goes through, that would not be the case anymore. he's going to work himself straight

34:32 out of a job here. What's going on. Yeah. This is, this was, there were definitely jokes

34:37 about like, this is just your attempt to, to get out of being the release manager for these

34:41 releases. but yeah, that, so Hugo proposed this, what, this is kind of like a pre pep

34:49 feeling out of how this situation should be. And like trying to pare down the options, I think was

34:54 Hugo's biggest, biggest question was what should we do it? And should we pare down the options?

34:59 Cause there's a million different ways we can do calendar versioning. and yeah, I think if you

35:03 scroll down, there was like a slide that had just, you know, every single possible calendar

35:08 versioning possibility for Python and all the different languages. but yeah, calendar

35:14 versioning is like really common for programming languages and other things that are similar to

35:18 Python. and so this was basically like, Hey, we have this yearly release cycle that is been

35:26 working for a while and we're probably going to keep doing it. Should we pointing out for people

35:29 who don't know that it used to be 18 months. And so the calendar versioning would get a little

35:34 out of phase or something there, but now, now that it's yearly in the fall, it really lines

35:39 up perfectly. Yeah. And so this kind of assumes that we're going to keep doing the yearly thing,

35:44 which I'm fine with the yearly thing, but yeah, as long as we kept the yearly schedule,

35:48 it would line, like the release year would line up with whatever the, so it would be like the

35:53 ended, the one that was like most agreed upon was like three dot and then a two digit year,

35:59 or what would end up becoming a three digit year when we roll over to a hundred, assuming that

36:03 Python is still used in a hundred years. but yeah, so like that was kind of like the one that

36:08 was most palatable to core devs or people were most excited about. And I think the big reason

36:13 why switching to like a Calver year was interesting is that we have this thing called like support

36:20 lifetime. So like how long is CPython supported? How long do you get security fixes? How long do

36:26 you get bug fixes? and so being able to do the math is easier. Yeah, exactly. Like,

36:32 let me put this out to the audience. Is Python three eight supported or is it not supported?

36:37 I don't know. You got to do, you got to do math. You got to think about it. yeah,

36:41 so three seven just recently dropped support. Right. Which is crazy. Cause that seems like

36:45 a pretty new version of my mind, but it totally makes sense. but if you just knew it's

36:50 supported for how many years, six years, five years, it's five years for security releases,

36:55 I believe. Yeah. So then you're like, it's 2025. So, you know, 2020 out, it becomes a lot easier.

37:01 And there was also say like, do I have the current one, right? If you're not tracking it super

37:06 carefully, like three 11, is that the latest? Like, I don't know. I don't, I only use Python

37:10 every like once a month. What was the 2023? Oh, I see. Well, I mean, that's not the latest one. Okay.

37:15 Yeah. Yeah. So it was just an interesting conversation about figuring out what the

37:18 best potential option was. And then Hugo ended up creating a PEP and I think that's being

37:23 discussed right now. So cool. Why not 2024, why 24? Because that feels, I don't know. It just

37:30 feels like you've just point shifted what you're doing now rather than, than really clear. Cause,

37:37 you know, as a new person coming in, you don't see that and go, it's 24. So it must be 2024.

37:41 And unless you really like put together the calendar, but if it's a dot 2024, you're like,

37:46 I bet that's the year, you know? Right. Yeah. I mean, cause eventually the,

37:50 in the not too distant future, there will be a Python 3.24.

37:54 Exactly. Yeah. We'll see. So there's going to be a pepper on this. You say, in fact,

37:58 it says right here, PEP 604, right? I think it's pep. What is it like?

38:03 Well, you know, that's the, just the yearly announce. You scroll down all the way to the

38:07 bottom. It'll, I think it's like peps. Yeah. There's a lot of drafting. It just says drafting

38:12 a pep. Give that a click. I'm pretty sure there's a number 2026. There we go. Okay. Yeah. Oh,

38:18 so that's going to be a while until they released this pep. Well, so I'm just kidding. The most,

38:23 the most important part of this discussion was that the, the Python version 3.14 B preserved

38:31 Py on, so yeah, cool. It wasn't allowed for three, three 14 to change it.

38:37 Yeah. The only thing that I can think of that you would have the two digits is that there's a lot of

38:43 code and regular expressions and junk out there that checks for that. But you know, if we talk

38:47 about some of the other stuff out there, like that's a pretty minor change, like for example,

38:52 three threaded Python. Yes. Three threaded Python. It's here. It is here. Sort of,

38:57 you know, what actually really surprised me is that when I saw this PEP come through,

39:00 is it seven or two or something like that? It said, we're going to allow free threaded Python,

39:06 which I'm going to have you explain for folks in a moment, but you're going to have to have a special

39:10 build of it. And I thought, oh, well that means if you want to play with it, you're going to have

39:13 to build your own. But I noticed that the installers now give you an option for it.

39:17 Yeah, they do. Yeah. The installers side by side install. Right. Yeah. The, what is it? I think

39:23 there's like a T that gets put onto your actual like. Yes. Python T is what you type instead of

39:29 Python. Yeah. If you want the free threaded one. Yeah. I mean, free threading is here. I mean,

39:34 there's options if you're compiling it yourself, you just enable some options. And I think I go

39:39 over that in the actual blog post too, the options that you actually use to try it out. And yeah,

39:45 free threading essentially is, it's a way to remove the GIL and move to a different like

39:51 reference counting model, object counting model. And which is quite exciting for a lot of people,

39:56 but it will, what it will end up meaning is that a lot of the packages that are written in C or

40:02 that are relying on CPython APIs will have to get either, you know, tweaked a little bit to like,

40:08 use these slightly different C APIs to make it so that they play nicely with having no GIL enabled

40:14 and with the new memory management. Yeah. It's super exciting.

40:18 And just in the ecosystem, basically. Yeah. Just because you have threads doesn't mean you get

40:23 perfect scalability across the cores. Can't remember who wrote this article. Is it Simon

40:29 Willison? Maybe who did some, yeah, I'm pretty sure it was Simon Willison who wrote one that

40:35 said, look, we're going to take an algorithm that can, is kind of embarrassingly parallel

40:39 and parallelize it. And it turned out to be something like 50% gain per core. So it was

40:46 like he had eight cores and it was four times faster with free-threaded Python than without,

40:51 which is still, if you can get your code to run four times faster, that's still really good. Right.

40:56 Yeah. But it's, it's going to have, like you said, I think it's going to have an interesting

41:01 requirement put on all the people building packages. Right. And I know when I hear people

41:07 say, I think maybe you just said like, oh, it's going to be the C extension packages that are

41:12 really going to have to deal with it because they, they'll have to do locks in their thing.

41:17 I think even in the Python code, there's certainly algorithms that have multiple steps that they'll

41:23 get some data here. They'll work with the data. They'll make some changes. Then they'll put the

41:27 data back in the same place. And even that would be subject to a race condition. Right. And I think

41:33 we're, you know, I've in long in the past did a lot of C++ I did a lot of C# and in

41:38 communities like that, people are like always focused. They're like, oh, he's kind of crazy

41:43 about two things, memory and threading. Right. And we just don't do that in Python. We just,

41:48 I think we have just leveraged the fact that the GIL gives us kind of enough coarse grain granularity,

41:56 the execution of our code that it's just not something we hit a lot. And we don't try to do

42:00 a ton of threading because it doesn't work all that well. However, this, this could expose

42:05 lots of stuff. This could put a new focus on that. Yeah, definitely. Yeah. Just having more people

42:12 using threading with Python, that that's going to be huge for finding thread safety issues.

42:17 Yeah. It's, it's just really exciting. I think that, and there's another blog post, a completely

42:24 separate one that talks about like the C API. And there was some mention about like free threading

42:28 and evolving the API so that it's a lot easier to use from a three, a free threading perspective.

42:34 So like there's a ton of work happening in here to make this as easy, a hopefully brief

42:41 kind of split in the ecosystem and then have it converge together. I think that's like the

42:46 overall plan is like, Hey, we got to, we got to have a way that if this is really not working out,

42:51 we can go back. But if it is working, we need a way that we can actually land this thing as the

42:55 default. Right. Right. Right. And the PEP discusses this as like, we're gonna, we're gonna see how it

43:00 goes, which is really interesting. But I think it's not breaking in the sense that you can't

43:08 still run Python three with the thing that you've got. You just might not be able to enable this

43:13 free threading aspect of it for some time. Whereas from two to three, it's like, you cannot

43:20 run this library on three period. There's no scenario which this is going to work because

43:26 it needs to take into account this and it doesn't. And so it's out. So I feel like there's more time

43:32 and space to evolve it. And you could say, well, in this space, you know, in this data science

43:37 section of the world, we use these seven libraries and we're going to work and make them

43:42 compatible so that we can get way better performance or, you know, we're going to work

43:46 to make sure that FastAPI and pedantic support it really well so that we can scale our web servers

43:51 better. Yeah. No, this will be huge for, for like web and, and data. I think that a lot of people

43:56 are excited for this for a really good reason. Yeah. I totally agree. I totally agree. Okay.

44:01 So this is a big deal. It's coming in three 13, but you've got to run Python T for now.

44:06 Yeah. It's a three 13, but it's also available in the pre-releases. The first release candidate

44:11 for three 13 is out. So give it a test. If you haven't given it a test, give it a test.

44:15 Yeah. Very cool. All right. What, what one do we want to talk about next? We got just a couple

44:21 more minutes to cover. We've got, what about Python and mobile? I think that one's, I know

44:28 there's the, the black Swan talk that Keith Russell McGee gave and Carol Willing also sort of

44:35 shouted out. Like there's a couple of places that are really, really important computationally in

44:41 the world that Python kind of isn't, we should have it there. And those number one has got to

44:46 be mobile, mobile and front end for me, mobile and front end are the two. And like a far distant

44:52 behind that is like, could I get a single binary out of my app that I can give to someone? That's

44:58 a different, that also is in there, but it's, it's like not as important as, Hey, I want to,

45:03 I want to build some mobile apps. Can I use PI? You know, I want to learn that with an easy

45:07 language. Chinese, ask me something else. Yeah. Yeah. Right. Like next question.

45:12 Yeah. So this was, this was a, it's almost like a big status update on where Python is in the

45:21 mobile space, which is really exciting because they've made a ton of progress on getting like

45:26 actual tiering of support for these platforms. So if you don't know, Python has a like platform

45:33 support tiers where it's like tier one is like X 86 Linux, right? Like that's a 90% of PyPI

45:40 downloads are, are that like, yeah, probably want to support that one. And then as things like Mac

45:45 OS, you know, X 86 and arm and all of that. Right. And then lower down there's tier two, which is,

45:52 you know, the platforms that they have people that are interested in them. But if those people

45:56 were to go away, then we wouldn't actually have a way to support them. And tier three is like even

46:00 more so. Right. So having tier three support for Python, for both Android and iOS for three 13,

46:07 like that's super exciting. It means that these things are getting actively tested.

46:11 There's like integration testing on real platforms and that there's people that care about it that

46:16 are fixing bugs. And this is exactly what you need to get your platform supported. And so this is all

46:23 being provided by Anaconda funding this project and be aware. Okay. Yeah, that's right. They are,

46:29 you'll be aware and Keith has been on this for a long time, but Anaconda have come along and

46:33 put more time and energy behind it in terms of funding and people as well. I'm not sure,

46:38 but certainly in funding, that's awesome. Yeah. So I think this was, it was both a

46:43 status report and also kind of trying to figure out how these sorts of platforms can get tested

46:48 more easily and like actually not having constant breaking because these platforms are so different

46:55 from, you know, what almost every other core developer is using to develop a Python or a lot

47:01 more limited in terms of capabilities and like lockdown and the security perspective too.

47:05 And they have no regard for backwards compatibility. I'd so frustrating. I, I got,

47:11 I, you know, I have mobile apps for the talk Python courses that are in both iOS and Android

47:17 app stores and I'll get messages like, Hey, dear developer, if we see that you're built against

47:23 three-year-old APIs, if you don't rebuild and republish your app in the next six months,

47:29 we're taking it out. The last one I had to do this for was Google. I'm like three,

47:32 three years. Okay. Can we, no, it can't get any better compatibility than that. Like I just got

47:38 to keep re-uploading the same thing, even if there's no changes. Like, so, you know, that's

47:42 just a different mentality of like, ah, we changed all that. We don't like that anymore.

47:46 Yeah. Luckily I'm, I'm actually not sure how affected Python in particular is by things

47:51 like that. Cause that's like utilizing APIs, like mobile SDK APIs versus like the operating system

47:58 of the phone, which, yeah, right. Like people would build apps with Python and then they would

48:03 be subjected to these emails. And it's not even that I was necessarily using any of those APIs.

48:07 It's just like, we see you're compiled against the wrong version. So try again, you know?

48:11 Yeah, no, the, yeah, the, the difficulties that I've at least from, from this talk have figured

48:16 out is that like these platforms are just a lot more locked down. So like a lot of system calls

48:21 won't be available that the test suite like assumes are available always. And sure.

48:26 It's almost like a circuit Python sort of deal, but not that extreme.

48:30 It's like, yeah, it's like somewhere in the middle and figuring out how to all work together happily

48:35 and develop on this similar code base that has all these different target platforms.

48:40 Yeah, absolutely. Absolutely. Awesome. Well, I'm, I'm really excited. I'm all here for it. If

48:45 three years ago, I think it was when we started working on those mobile apps, if I could have

48:50 used Python in a really solid way, a hundred percent, those apps to be built in Python, but

48:55 just, there's so many, so much tooling and stuff around. Oh, you got to create a signed APK before

49:01 you upload. There's a lot of stuff going on there. And so hopefully they, they get that. That would

49:06 be, be a game changer and just, you know, it's not on, it wasn't here. Almost surprised me that it

49:11 wasn't here, but front end stuff, WebAssembly, PyScript, Pyodide, all those things I think are

49:17 in that same realm. Although they can just kind of ship stuff to the web because there's no gate

49:22 keepers, but still. Yeah. Was that mentioned anywhere during the summit that just didn't make

49:28 a post? No, Wasm was not, there was no topic about Wasm specifically at, at this language summit.

49:36 Yeah, sure. I think there was the previous year. Previous year there was. Yeah.

49:39 Should we make PDB better? Does this matter? Are people using PDB? What do you think?

49:43 Yeah. So this, this was all about, PDB is Python's debugger for people that don't know. If you've

49:49 never used it, it lets you kind of like drop into, set a break point in Python and then drop into

49:55 that exact spot with all the context and everything, which is really. At a lower level. Yeah.

50:00 At a lower level than VS Code or PyCharm. Right. Exactly. Like seeing all these like super

50:05 internals of Python, if that, if that's something that you really need. Right. And so this was a

50:11 talk that was mostly about, okay, we're, we have PDB, but now we have all of these new models,

50:18 like free threading and all of that. And also we're being a little bit held back by backwards

50:24 compatibility. There's like a specific, really specific point where because of backwards

50:30 compatibility reasons and PDB is a part of the Python standard library, it becomes difficult

50:36 to break backwards compatibility, even if it would mean you get a bunch of really good stuff out of

50:40 it. You can't always do that because people are depending on it. And I think that the, yeah,

50:46 the recommendation was maybe we should develop this outside of the standard library so we can,

50:50 you know, break backwards compatibility if it's not necessary and, and make it so that we can

50:56 support multiple versions instead of just having it be per version. And yeah. Yeah. That's, that's

51:01 a good idea. That's exactly what I was thinking. Cause you know, there's the whole dead batteries

51:05 talk like, does this still belong here? I'm not necessarily thinking this should not be in Python,

51:10 but you know, yeah. Something broken out maybe, but take that exact code, break it out, but,

51:16 you know, enhance it kind of independently. Yeah. And I think the concern from, from some people in

51:22 the room was that, Oh, if we break this out onto pipe, AI, then it would potentially mean that it

51:26 would not get the same level of contribution that PDBC is because it's part of Python. Right. Sure.

51:32 And I mean, totally valid in my opinion too, like being a part of Python is a huge, like blessing

51:38 of like, yeah, this is something important. Right. But I, I think that there's, there's other ways to

51:44 signal that that's something important. Like if you look at like my pie, my pie is underneath the

51:48 Python GitHub organization. And so maybe something like that, right. Where it's this tool that is

51:54 very actively used by core developers for development. And it is a little bit more

51:58 official than, you know, just some random person putting something up on pipe. Yeah. This is core

52:03 developers supporting this. And black is that way too, I believe, right? It is. Yeah. So maybe

52:08 something to signal just a little bit more of an official, this is a core developer tool. Here's

52:13 why you should contribute to it instead of just, you know, a random project on pipe guy, which

52:17 definitely wouldn't be in that case. It would not, it would definitely not. All right. How about,

52:22 how about a quick review of maybe some, some of the lightning talks? Yeah. Any of these stand out?

52:29 You know, obviously Rust and Python is seriously a one. Yeah. Emily's talk was, yeah. Emily's got

52:38 a good one. Emily has a really good one because, and this is like, it's, it's almost meta, right?

52:43 Because lightning talks are not submitted ahead of time. You actually have to submit them during

52:49 other people's talks, like to the list that you want to talk about this and then put together

52:54 some slides really quickly. So yeah, these talks are pretty impressive in that way,

52:58 having mere minutes, but the Emily's talk was about, it was kind of like wrapping up a theme

53:05 that was being heard multiple times over the course of the language summit. But obviously

53:09 this is a problem outside of the language summit too, which is that when someone goes to make a

53:14 prototype for a pep, they are given at least today, not a whole lot of support for doing that

53:21 prototype because it's basically like, Oh, we think that this should be developed outside of

53:25 the standard library. Initially, right? Like that's a really common determination that the steering

53:32 council comes to. And so being able to have kind of like a standardized way that people do a pep

53:40 prototype outside of the standard library. So things like creating a repo and like having all

53:45 of this existing infrastructure set up and maybe even hosting it under the Python GitHub organization

53:51 to give it some like air of officiality of like, yeah, this is something like really big is

53:56 happening here. It's not just like someone in a corner writing something right. Like giving some

54:00 more grandiosity to, to the work that's being done and not just kind of saying, Oh, go away.

54:05 Like that is the intention. Right. But that's kind of how it can land sometimes.

54:10 Right. And maybe setting up people for success, at least this is what we're going to expect from

54:14 you. If you go through this process, then you've got, you're further down the pipeline of having

54:18 that conversation for a pep. Yeah, definitely. And like, if you're wanting to write something that is for Python, you know, you probably don't necessarily care

54:27 about like setting up these exact workflows for publishing to PyPI. Like that's just a whole bunch

54:33 of things that are in your way to actually being successful. So having that all be figured out

54:38 already ahead of time for you makes things a lot easier for you.

54:41 Yep. Yep. Yep. Let's, let's finish it out with Yuri Silvanov's presentation, efficient data sharing

54:48 between sub-interpreters. And it's interesting because we talked about free threaded Python,

54:53 but the year before the big news was sub-interpreters and Eric Snow's work. And

54:59 those are not directly competing type of things, but in a sense they're kind of competing.

55:04 Yeah. They're definitely competing for being like the, the model of how to do efficient,

55:10 you know, parallelism in Python. Yeah. Yeah. How do we isolate the stuff

55:13 so that we can avoid the GIL? We take it out and add different algorithms or do we just

55:18 make copies of the interpreter and run them in isolation, but then you have this

55:22 data sharing issue. I can't just share a pointer easily. Right. So what's this about?

55:27 Yeah. So Yuri basically came with, and this was also if you want the extended version,

55:34 Yuri also gave like an actual PyCon talk about this library that he's developed called Memhive.

55:39 What's it called? Memhive.

55:42 Like M-E-M-H-I-V-E. Yeah.

55:44 All right. Awesome. And just for everyone listening just this week, last week,

55:48 recently, all the videos of all the talks are now available on YouTube. So it's been a while

55:53 coming, but you can go watch it now. Exactly. So go watch them all. If you,

55:56 if you missed out on a talk, go watch them. But yeah, this, so this library in particular is,

56:01 it's basically a way using immutable data structures. There's this immutable data

56:07 structure called an H-A-M-T. I actually don't know what it's short for, but it's a hash,

56:13 hash array map tree. There we go. It was in the, I wrote it down. And it's essentially like a way

56:20 to have this tree that can be passed around and shared without like worrying what the other

56:28 processes, sub-interpreters are. They're not processes. The other sub-interpreters are doing

56:32 to the status structure. So it enables a more efficient and safe way of sharing data. That's

56:38 kind of like in a tree structure. And I think one, the demo that he ended up giving was about

56:43 a dictionary-like data structure where, you know, you have a million keys and a bunch of

56:48 sub-interpreter workers working on that data. And they're able to, because it is using this

56:53 immutable data structure, the modifications and changes are all safe, but it's also like super

56:57 scalable and performant. Yeah. Yeah. Yeah. The thing about parallelism and multi-threading is

57:03 if it's immutable, you can have many things that you want reading from the same memory. It's only

57:06 when they start writing, does it matter? So yeah. Yeah. This, this like has a way,

57:11 a mechanism to capture the rights in a way that is safe so that like the current one can see

57:16 what has been written and then the other ones aren't affected because their copy is not changed.

57:22 Okay. That sounds very interesting. We talked about the coming compatibility matrix of free

57:27 threaded Python. This won't have that issue, right? This operates in the every version of Python.

57:33 Yeah. So this, I would assume that this sort of module would be able to say like,

57:38 I am ready for a GIL free world. So that's like the mechanism that I believe CPython has,

57:44 has adopted for saying that your C module is ready for not having a gill. You actually have

57:50 to opt into it. And then that module will, will be allowed to run in a free threaded Python.

57:55 Yeah. It's something I recently learned is there's separate wield builds for free threaded

58:00 Python as well. Yeah. That's, that's interesting. Yeah. It's its own, I don't know exactly the

58:05 phrase for it, but yeah, it's own wheel tag platform target or whatever. Yeah. Yeah. Like

58:11 free threaded gets appended to Mac iOS arm 64 or whatever. Exactly. Yeah. Awesome. All right,

58:18 Seth, this has been great. How about some parting thoughts? Let's close this out with just

58:22 takeaways from, from the whole experience. Yeah. I mean, the language summit is lovely.

58:29 One of the things that's like most important to me is like this whole aspect of storytelling. And

58:33 so that's why I felt really, really happy that I was invited along to be able to tell these stories

58:38 to all of you. And I think that having all of these different narratives all in one place of

58:43 all of these huge themes about what Python is going through all at once, right? Like it's

58:48 really incredible how many different things are happening in Python all at once. And like

58:55 sometimes when you're focusing on just one or just two, you know, you don't have this huge

58:59 context of, wow, Python is changing in like at least 20 different ways all at once. And we're

59:04 somehow doing really, really well. I would say like, yeah, I have no doubt about any of any of

59:09 these huge changes that Python is going through, like to, to take it in the wrong direction. Like

59:14 I'm feeling hopeful and excited about all of them. So it's an exciting time. Yeah, I am as well. And

59:18 it is really tricky to get a picture, a holistic picture of, of the progress. Cause there's a lot

59:24 of different groups doing different things and there's no one person's or one company's job to

59:30 get somebody to come and tell that story. So yeah, thanks for giving us the insight here.

59:34 It's been awesome. Yeah. Thanks for being on the show and I'm sure we'll have you back soon.

59:38 - Yeah. Sounds good. Thanks for having me.

59:40 - Yeah. See ya.

59:40 - This has been another episode of Talk Python to Me. Thank you to our sponsors. Be sure to

59:46 check out what they're offering. It really helps support the show. This episode is sponsored by

59:51 Posit Connect from the makers of Shiny. Publish, share, and deploy all of your data projects that

59:56 you're creating using Python. Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports,

01:00:03 Dashboards, and APIs. Posit Connect supports all of them. Try Posit Connect for free by going to

01:00:09 talkpython.fm/posit. P-O-S-I-T. Want to level up your Python? We have one of the largest catalogs

01:00:16 of Python video courses over at Talk Python. Our content ranges from true beginners to deeply

01:00:21 advanced topics like memory and async. And best of all, there's not a subscription in sight.

01:00:26 Check it out for yourself at training.talkpython.fm. Be sure to subscribe to the show. Open your

01:00:31 favorite podcast app and search for Python. We should be right at the top. You can also find

01:00:36 the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on

01:00:43 talkpython.fm. We're live streaming most of our recordings these days. If you want to be part of

01:00:48 the show and have your comments featured on the air, be sure to subscribe to our YouTube channel

01:00:53 at talkpython.fm/youtube. This is your host, Michael Kennedy. Thanks so much for listening.

01:00:58 I really appreciate it. Now get out there and write some Python code.