From de8ed138ad20a1850e9c42d072ff684232ee3dfa Mon Sep 17 00:00:00 2001
From: Nikhil Bhirud <12810336+nbhirud@users.noreply.github.com>
Date: Fri, 13 Sep 2024 17:22:17 -0400
Subject: [PATCH] Delete
 pypodcasts/media/transcript/python-language-summit-2024.txt

Signed-off-by: Nikhil Bhirud <12810336+nbhirud@users.noreply.github.com>
---
 pypodcasts/media/transcript/python-language-summit-2024.txt | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 pypodcasts/media/transcript/python-language-summit-2024.txt

diff --git a/pypodcasts/media/transcript/python-language-summit-2024.txt b/pypodcasts/media/transcript/python-language-summit-2024.txt
deleted file mode 100644
index 2b59b51..0000000
--- a/pypodcasts/media/transcript/python-language-summit-2024.txt
+++ /dev/null
@@ -1 +0,0 @@
- Every year, the court developers meet to discuss and propose the major changes in trends and Python itself. This invite-only conference of about 50 people happens inside Picon in the US. Because it's private, 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. It's a unique look into the zeitgeist of C Python. This is Talk by Thundemi, episode 475, recorded August 22nd, 2024. Welcome to Talk by Thundemi, a weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Macedon, where I'm at M. Kennedy and follow the podcast using at Talk Python. Both accounts over at Fostodon.org and keep up with the show and listen to over nine years of episodes at TalkPython.fm. If you want to be part of our live episodes, you can find the live streams over on YouTube, subscribe to our YouTube channel over at TalkPython.fm, slash YouTube, and get notified about upcoming shows. This episode is sponsored by PositConnect from the Makers of Shiny. Publish, share, and deploy all of your data projects that you're creating using Python. Streamlit, Dash, Shiny, Boke, Fast API, Flask, Quattro, Reports, Dashboards, and APIs. PositConnect supports all of them. Try PositConnect for free by going to TalkByThund.fm, slash Posit, POS IT. And it's also brought to you by us over at TalkPython Training. Did you know that we have over 250 hours of Python courses? Yeah, that's right. Check him out at TalkByThund.fm slash courses. Hey, Seth. Welcome back to TalkByThund. Hey, Michael. Awesome to have you here. I'm really excited to get a look into the zeitgeist of the core devs and the people building Python for us through the Python language summit. Yeah, let's do it. Let's do it. So we're going to talk about the 2024 language summit that happens in Pittsburgh. It's like an embedded mini conference inside of Python, which is smart rather than trying to travel all over. But before we get into that and all those things, I know you've been on the show not too long ago, but for those who may have missed your introductions, you know, who are you? What do you do for Python these days? I'm Seth Larson. And I've been working at the Python Software Foundation for a little over a year now as the security developer and residents. And so that means that I do a lot of stuff related to security, just for the entire Python ecosystem that's C Python, PIP, packaging ecosystem, like outwardly facing things for PyPI, maybe not as much the internals. I leave that for Mike Fiedler, the PyPI Safety and Security Engineer. And I maintain a lot of open source projects specifically in like the HTTP and internet space. So like requests, you're lip three, trust or things like that. Oh, awesome. Yeah, thanks for everything you're doing there. How's the role working out? I know this is one of you were the first person in this role, like officially, right? Is that true? That is true. Yeah, I was the first security oriented hire at the PSF. It's been going really great. I mean, I feel like we've made a lot of improvements. And there's a lot of exciting stuff that I'm working on today. And I don't know, I think one of the things that also got highlighted because this role exists, it just means that more people at the PSF and in C Python core team and just in the Python ecosystem in general are talking more about security. And like that's just as important as the stuff that I'm doing day to day is that it's just there's just more awareness of what's happening in security. Yeah. So I have two polar opposite thoughts here. One is I'm really surprised how few significant issues there are in Python, C Python, you know, the interpreter, the runtime, the standard library, all that. It's really rare that you get a red lights flashing. Oh my gosh, go patch your systems now. Sometimes really minor things like this audit trail is not completely followed under this condition, but that's not a, the pageer goes off in the, you know, because you got, it's now a race. That's one thing. So that's awesome, right? That the other is Pipei, typo squatting, all the stuff that makes Python extra good, the half million packages and other shady things people do. And we're going to talk about this in the broader sense, not Pipei, but, you know, in the open source space of like, well, what if what if somebody took over a GitHub account for a little while or something? Yeah. So in that, that's not on fire, but that's, there are battles being waged actively there. I would say, right? 100%. So it's a contrast, right? There, I can speak with confidence that there is malware on Pipei right now as we speak. But like, yeah, so that's, that's the case, right? I think it really has to do with C Python is an incredibly mature project in like every sense of the word, like governance, security, design, all of these things, right? And like, there's just a huge amount of people and resources being being working on C Python at any one moment. And like, contrast that to the, you said half million, you know, I tend to focus on the like 95% of downloads by totality, right? Because there's a lot of projects on Pipei that maybe don't have the supply chain criticality of others, right? But yeah, absolutely. 100%. And when you, I think when you hone in on that smaller window of projects, it ends up being a much better picture than that. I think I'd say I think it's 100% good picture, honestly. There are legitimate bugs that people have to deal with, like, you know, maybe there's a Django release that says we didn't validate the CRF token in this particular form. So you should update your Django, right? And that's, that's just a legit bug. That's not people attempting to do bad things. Yeah, I mean, I can't even take really any credit for how secure and mature C Python is. I'm such a late addition in the life of C Python. And like, Pipei projects. And so it really is the community. I think it is just there's so much investment in so much love and care happening in all these projects that it does speak volumes. But that, I mean, that doesn't mean that we need to think that things need to be perfect or that it's necessarily a bad thing to have a vulnerability in a project because there's projects that are even more mature than C Python that have vulnerabilities all the time. It's totally normal. I think the important thing is just like knowing what to do when that happens. And that's where I come in. Yeah, I don't want to blabber this because the, you know, the security angle, wow, interesting to me and central to what you're up to is not the topic. But I do think it's interesting that the White House recently came out. I think it was the White House. It said we recommend Python and a couple of other languages. We basically, we recommend memory safe languages, which did you see that post? You must have, right? I certainly did. And I actually had a big part of recommending that to the White House. So when the, no kidding, I had no idea. Yeah. Yeah. So the PSF, we responded to the request for information that Sissa put out or the office of the cyber director put out, I think a year and change ago. And in that post, we recommended C Python and Python in general as a memory safe language. And went into all the details about like, yes, it's written in C, but like the language itself, what people will actually be programming in is Python. And we also emphasized how Python is a bridge into memory unsafe languages. And because of all the focus on performance lately, it's actually like sometimes in some cases more performant to keep the code written in Python as opposed to writing in C. And so we emphasize a whole bunch of stuff. And so I think that that had a small percentage of the reason why that was recommended. But it put it on the radar and positioned it correctly maybe. Exactly. Awesome. Well, congratulations. I was just going to say that's kind of interesting, but I'll join more to it than that. There's a lot happening behind the scenes. Yeah, yeah, yeah. Yeah, there is. All right. Shall we talk about this language summit thing? Let's do it. I want to do it. So let's just, I mean, I gave it sort of a vague intro. You wrote a nice blog post about it here on the Python blog. Just give us a sense of what the language summit, what is it for? Is there something that is like an open space I can go to or not? No, I'm so sorry. So it is a specific space for Python core developers to use. And so I think the whole goal of this is to get a bunch of core developers in a room together to discuss things and to kind of get some recommendations, some ideas flowing, maybe without necessarily like having the full formed thought, right? Because like putting something out there, like completely radically changing the direction of Python, that's a lot to put that out just publicly, whatever. And so this is like a place to collaborate for core developers and some special guests, because they're not everyone that's there as a core developer, but it is invite. So you have to like apply it to go and say why you want to go. And then yeah, so it's just folks who were, keep member, fit was Sebastian Ramirez or same call owner, something around the typing thing. I remember some of those folks might have been at one of them because they're like, wait, we can't change typing to be more performant where to completely ignore the runtime stuff, because we have all these frameworks. Right, right, right. Yeah, but the language summit, it's a whole bunch of different like submitted topics, people will talk and then there's discussion and some outcome. Maybe there's no outcome. Maybe there's like next steps. Maybe we solve some problems within the time and the meeting. And yeah, my job there was to actually like take down all the notes and write about it and like publish these blog posts because one of the one of the reasons why this is allowed to be like an invite only meeting is that there is someone who is basically taking notes and blogging about everything that gets discussed and like what happened during the discussion so that the community can learn about what actually happened without necessarily, you know, getting the rawness of it, I guess. Yeah, there's a rule careful balance. You got to strike between allowing the freedom to say whatever without public scrutiny. But at the same time, you don't learn to be like, well, the Python cabal met. They've decided exactly. They don't like you're idea or whatever. Exactly. Yeah, it's cool. So I'll point people, obviously, it's going to be in the show notes. When people write up, it's like a meta post, I guess. Would you say that? It talks about, you know, sort of landing page. landing page, exactly four or one, two, three, four, five, six, seven, eight, nine. And then nine topics and presentations that were covered. And then the lightning talks, which is also almost like another sub meta section. So there's a lot to explore here. And there's nice write-ups on each of these. So where should we start? And we want to kind of wrap up the conversation we were just having because that was actually a little bit of a topic at the language summit, right? Yeah, security was definitely a topic at the language summit. This was somewhat in the recent light, like the light of XZ, when XZ had happened, Pablo, one of the release managers for C Python 310 and 311, I believe, brought this topic. And it was basically discussing Python's contribution and release and all of that model in the light of XZ. So XZ, I'll just go over really quickly. Yeah, yeah. I'm sure it's- Tell people about XZ. Yeah, I'm sure a lot of people have heard of it. At this fight, but- It was such a long game deal. It was crazy. So yeah, what is- What is the scary part? What is XCU Tills and then what is the XCU Tills security issue? Yeah, so XCU Tills is a library written in C for basically processing archives of the XZ format, which is just a compression format, like GZip, like any other compression format, Zotfully, broadly, all of those. And so this library was maintained by a single person, big surprise, and was relatively little known right before all of this happened, I would say. It was probably just adding features, fixing bugs, everyone's gonna make a release and all of that. And what ended up happening is this project was identified as a project that had very few maintainers and also through a series of reasons had a linkage to SSH. And so when it ended up happening- Happening. Yep. And so SSH was- You couldn't get into SSH. Yep. And SSHD, then bad things were gonna happen. Yeah, so the whole end goal of this entire operation was to get access to open SSH through linking, basically. And so what ended up happening is a bunch of fake sock puppet accounts showed up after this lone maintainer indicated that they were having a little bit of trouble maintaining the project and like meeting user demands. Like these sock puppet accounts show up like days before they were actually used and all kind of in similar fashion, right? And basically are pressuring this maintainer to either make them feel like they're not doing a good job or to try to add a new maintainer, in this case, Geotan, is the pseudonym that this account used. And what ended up happening is over a year of like legitimate positive contribution from this account. This account was added as a like equivalent to a release manager, right? Like someone who is approving PRs and merging things and is capable of accessing the actual archives when releases happen. And then a good chunk of time passes after that. And there's a couple of little changes added that on their own are not an attack, but it was preparing for an attack where essentially a small change was added into the release archives that was not a part of the source tree that activated the entire attack chain. And then when this started to like be pulled in downstream into things like, you know, Fedora, early versions of Red Hat, this never went into any stable builds, but it was all the prerelaces. This ended up getting onto people's machines and then was eventually discovered because of a very small performance difference when logging into SSH. And that was somebody who wasn't even looking, forgot the person's name, but they worked at Microsoft and they were just they got the Azure team or something and they they just were like, why did this slow down a little bit? That's weird. And they're like, wait a minute. What is this doing in here? Yeah, it was on the verge. And you know, what a long game. One person, one account came along and was just, you know, I'm going to hear to help you. I'm just going to make, I'm going to try to just become your best friend contributor. And then another one is just abusing like mentally abusing the people like, why don't you just quit? Why don't you get some more support? And then like, who? Well, let me reach out to some people who are helping me out recently. And it turns out these are like two sides of the same coin. Yep, exactly. Yeah, shady. Okay, luckily that got caught because, you know, there's a lot of servers in the world that can be SSH into and like, well, we got public private key encryption. You can't break through that stuff. Long as you know these passwords, like you're going to be fine, unless you're not. So I received a lovely email on the day that this happened. Report to the security response team for Python because we of course use the XU Tills libraries because Python supports XC format as well. And I there was a there was a lovely few seconds where I'm like, oh, this is either going to be a fine day for me or a really bad day. And it ended up being a fine day. So that's good. Are we going to be canceling all our plans for next year? Yeah, yeah. I'm not going to have lots of questions to answer from like a concerned customers users, but I was fine. Yeah, yeah. I find this kind of stuff is a lot like, everything's fine. You relax. It just works going good. Life's going good. And then something's on fire just out of the blue and you have this, you know, it takes your breath away, mommy. Like, which is out of play to us is too. As well because if it does, everything just changed. Fun fun fun fun fun. Yeah, I really glad I didn't. This portion of talk Python is brought to you by Posit, the makers of shiny, formerly our studio and especially shiny for Python. Let me ask you a question. Are you building awesome things? Of course you are. You're a developer or a data scientist. That's what we do. And you should check out Posit Connect. Posit Connect is a way for you to publish, share, and deploy all the data products that you're building using Python. People ask me the same question all the time. Michael, I have some cool data science project or notebook that I built. How do I share it with my users, stakeholders, teammates? I need to learn fast API or flask or maybe view or react. Hold on now. Those are cool technologies and I'm sure you benefit from them. But maybe stay focused on the data project. Let Posit Connect handle that side of things. With Posit Connect, you can rapidly and securely deploy the things you build in Python. Streamlit, dash, shiny, bokeh, fast API, flask, corto, ports, dashboards, and APIs. Posit Connect supports all of them. In Posit Connect comes with all the bells and whistles to satisfy IT and other enterprise requirements. Make deployment the easiest step in your workflow with Posit Connect. For limited time, you can try Posit Connect for free for three months by going to talkbython.fm slash Posit. That's talkbython.fm slash POSIT. The link is in your podcast player's show notes. Thank you to the team at Posit for supporting Talk Bython. One of the talks was Python security model after this issue, the XC YouTube's backdoor. Tell us about that. Yeah, so this entire talk was essentially just over viewing like, hey, is this possible for C Python to be impacted by such an attack? I mean, the answer is yes. It really is because if you have accounts that are willing to put years of effort into contributing good code to C Python, like that, that is enough to become a Core Developer likely. And if you're a Core Developer, it means you can merge PRs. It means if you get two Core Developer accounts promoted to this level of authorization, you can merge your own PRs with review. Right? Like, we're the big focus on this talk was like, okay, how can we prevent this? And if we, in the ways that we can't prevent it, how can we be ready? And kind of like a discussing whether or not we're ready at this point. And I think the big consensus was that if we were to discover something like this, that had already been merged into Python or had been released in Python, that we would be okay to be able to get it to get the word out. Like that sort of infrastructure already exists. And we're not too worried about that. Like we're a CNA. We can create a CV really quickly. We can get the announcements out really quickly. We can get releases out really quickly. So like in that way, the reactive sense were okay. In the proactive sense, which is the more important one, but it's also the harder one. We, Yeah, because when nation states hire people to say the next three years of your job, it's almost like a team. Like a spa. Yeah. For three people. Exactly. It's like the CIA or MI6 or something. You know, on the code side, you know? To be honest with you, it doesn't even need to necessarily be like nation state level stuff for this to happen. That's true. Because vulnerabilities in popular pieces of software are very, very lucrative. You can sell them. And people make a lot of money on selling vulnerabilities projects. But so why not grow your own, right? Yeah. Yeah. So go ahead. One of the things I think is great. There's a really long release cycle. Right. And like a stage rule out. So I don't know how many people jump in and install alpha one of some Python. But it's pretty limited and it's not going to make it. No, no, of course. I know as he raised you. However, I don't see that shipping on, you know, a Boontus update channel or Docker's whole different deal. Like let's not even go there. But on the main Docker images, you know? Yeah. Yeah. I mean, the slow rollout is definitely a big part of it. Right. Like a lot of people get their Python not direct from the source. They get it from a like a distribution or they get it from, you know, if they, you know, like Amazon Linux with Python or whatever, right? Like it's a distribution of Python or brew install or brew install Python. Yeah. So a lot of people are not living on the edge. And I think that that helps in a way. Obviously, people that are living on the edge, maybe they're the more valuable targets. But I mean, I'm not going to be the one to encourage that. Yeah. I don't think that I think the biggest defenses against this. And this was what was what discussed there was trying to push things to be in the open. And actually, in a way, open source is uniquely able to respond. Right. Right. Right. Right. Defended against for these sorts of attacks. Because if this were to happen in Windows, for example, like, would we have had the almost immediate like being able to debug what the actual attack was? How long this would have been going on? What patches were bad, right? Like that sort of visibility into the source code is something that was really important in being able to actually track this thing down. And so like having test files and binary files not checked into source code and instead generated. So one of the parts of this attack that allowed it to go hidden for so long and be checked into source code was that almost all of the attack code was hidden extremely well in a binary file, which made it so that code reviews. Some of the test binary elements. Because if you got a compression file utility, you got to have compressed files for your unit test, right? Mm-hmm. Exactly. So it was basically these files were checked in. And there's just huge binary blobs that you can't actually get your eyeballs on to review. We talk about like lots of eyeballs make for shallow bugs. Well, if the eyeballs can't see the bugs, then you're not going to find them. And so we talked about like removing binary files from the source code or making sure that all the binary files that are generated have like a script that allows them to be generated any time and things like that. So is it one of the changes? I recently I can't remember if this was on IPI or if this is a GitHub thing, but allowing GitHub to be the thing that publishes directly builds the wheels and uploads them to PyPI rather than somebody downloading the code, building them and uploading it, which obviously that's an opaque step there. Yeah, so other things that tie more strongly these, whatever release artifacts are actually ending on Pond People's Machines to the source code. So that's, I mean, I would call that build provenance. There's a whole bunch of different frameworks that that works under, but yeah, build provenance being able to tie in an artifact that's installed in your system back to the actual source code so that when you are evaluating that artifact on whether you want to install that on your system or deciding whether to upgrade or whatever, you can look at the source code instead of getting this compiled binary. That's something that I really want to focus on for like PyPI in the future, but yeah, we're not there yet. Awesome. Yeah. Yeah. When you look at a project, you say, well, let me see what the release is on GitHub. If you know that literally that was the thing that compiled or got built and then that's what's on PyPI, that's a different forensic analysis then. Exactly. Well, it's somebody's machine. What it ends up nice like being nice is that it, and this is the tough part, is that I feel like a lot of people's behavior, which is to go on GitHub and look at the diff between like tags. That's what a lot of people do, but that's not actually what you should do. You should be looking at the diff between artifacts. That's the thing that's actually installed on your machine, but that's way harder to do than looking at the diff tags. Exactly. Exactly. We just crowdsource it. We're all crowdsourcing it like way for no way we are. I know. We're just related to this. We're still on this topic. You talked about the somewhere. There we go. There's also big news around CVEs, which are official vulnerability numbering. So they're referenced through all those cybersecurity talk and stuff. You should write better. But so, big news is that the PSF now, and you alluded to this, is now an official numbering authority. So rather than saying there's a problem with Python, who's going to officially call this out and write it up and so on. You guys can do that directly now, right? Yeah. CVEs are basically, it's a set of identifiers and records that show what's like a bunch of metadata about vulnerabilities in software is what it is. And it's only one system. There are a bunch of other vulnerability databases, but CVE seems to be the one that everyone uses or references. And so what being a CVE numbering authority gives us is it makes it so that someone at the PSF can operate the CVE UI and workflow and all of that to say, like, oh, we want to create a new CVE ID on behalf of the Python team or on behalf of the PIP team. And what that ends up meeting is that because we are part of the process instead of having to go to some other entity. So like Miter or Red Hat or Microsoft, there's a whole bunch of CNAs. There's a bunch, there's over 100 now, I think. Instead of going to someone else that isn't as well versed in Python or our release schedule or any of those things, right? We get to inject the knowledge that we have about Python into all of these records, into all these advisories. And it makes it so that we don't actually have to talk to someone else to be able to handle a vulnerability and to end. Right. So like before you would potentially have a reporter going to talk to someone else and getting a CVE ID and then they would come talk to us. And by that point, like, it was, it's hard to like make a determination and there's a whole bunch of things have already happened and maybe there's messes that need to get cleaned up to make sure that it's not confusing. So by owning the entire process, we're able to make sure that things are as little confusing as possible, like what actually needs to be done for users when we publish these things. Yeah, that's great. I want to move off the security angle here because I know there's so much more to talk about. However, I'll help it. You guys do it, have you considered or ever run any sort of bug bounty program? We don't have a bug bounty program right now. I mean, the hard part with a bug bounty program is it takes money. So if you would like to see a bug bounty program happening at the PSF, get in touch with the PSF, it's on the you know. Yeah, I think incentives are really lying there. There's a lot of companies that have these tooling at the center of their data center. So maybe, maybe, maybe, maybe we can make it happen. All right. Next up, the REPL or the Pyreple for the Python Pyreple. What's the deal with this? Yeah, so this was a talk that was given by a couple of different core devs. I think this included a bunch of people, Pablo, the caution, Los Andros, all gave this talk. And it was about, hey, this new REPL that's coming in Python 3.13. Here's all the cool stuff that it can do and how it makes the usability so much better for people. And they demoed a whole bunch of the new features, which was really exciting. There was lots of applause showing off a few of these like little features. And I think that the the other side of it is like, because this new REPL is written in Python and not written in C, it lowers the barrier for contributions and maintenance drastically. Before the REPL was like super entwined with like the parser and all of these other really low level details of Python that a lot of people probably didn't want to get involved with if they didn't have to. Versus this where it's this completely separate and much more easy to contribute to pieces software. Yeah. And did this come from the PyPy? PyPy project. Yes, this was PyPy. And I think that there's been some some back and forth contributing back contributing forward all of that, which is also really great, right? Having one REPL shared between two different implementations. Yeah, that's great. Just working working better together. More people working on it. I always caught PyPy because it's a people call Python package. It injects PyPy. That's also the other thing. So anyway. It's a not too part of every one of my days, right? I'm sure that I because a lot of the times, you know, a significant percentage of my work as a security person is being in working groups that are not Python related at all. And yeah, there's a lot of PyPy is flying around. Yeah, you talk about numpy being on PyPy and you're like, okay, hold on. Could be two different things. There's a lot going on here. So yeah, so this is really interesting. I haven't really played with it much. I honestly don't spend a ton of time in the bear Python REPL. Like if I'm a REPL and a lot of times I'm in the jet brains, sort of enhanced REPL that's inside PyCharm. Something like that. But and I think partly because there was a lot of challenges with the bear Python REPL, right? There's no auto complete. But worse than that was if you've got a five line function and you want to edit it, you kind of got to go out to the top heart, hit her. It really was hard to work with blocks of code. There's no color, things like that. Yeah, colors the standard for you don't have color in your terminal at this point, like even 20, basically, you've given up at that point. If you haven't emoji and you don't have color, I mean, emoji is cooler. You've got to have like the rainbow prompt, maybe like the E logo of the thing that starts up. A starship. I didn't even consider the asky art. And possibly the asky art in color. No, seriously though, I do think it sounds like a minor deal, but just the readability of having highlighting and stuff. Yeah, syntax highlighting is huge. Syntax highlighting is like really huge. That's not a part of the current REPL I don't think, but like it becomes much more possible because this pyruple exists. Yeah, exactly. Yeah, I think that like the biggest thing, yeah, like the whole blocks of code, I just remember the demo of them showing like, oh, you have like five lines you have to hit up up like four times hit, and it's just like, oh, you mess it up, you got to start over. You go start over it. And you're just sad. You just contemplate putting it in a file instead of doing this in the REPL. Exactly. That's why I'm not in there. I avoid being in there because it's hard. This is going to be really, really great for people that are just starting Python journey. Because I think that a lot of people learning and starting off will use the REPL straight up instead of an IDE. And so like having this, there was a big focus on like teachability and documenting it and making it work the same. Like if you actually like read the post, like what the discussions were about for like everyone is basically totally in favor. They loved it. But they wanted to make sure that this was going to be like a consistent experience. Specifically, like Carol Willing had this big point about like having a consistent experience being really important for teaching Python across different operating systems. Yeah, and something a little bit a little bit better than up up up five times to don't get out of work. Exactly. Yeah, that's cool. So I guess one of the, I don't know if this was discussed, but one of the challenges of this I think is it requires and it's not necessarily bad, but just a challenge is I think it requires the new Windows terminal rather than say cmd.exe the older style. Just work out of the box on macOS and on the next, but on Windows you got to be a little careful about how you run it. Is that right? So I actually don't know what the current status of all of this is because the time has marched on since these blog posts have happened. And yeah, it has been a lot of work done on the Windows side. The current team, like the team that presented this didn't have any Windows experience. And so they didn't know really how hard it was going to be. I think that there's been a lot of strides in the Windows side of things. So I think the situation's better. I don't know offhand if cmd. That exe is supported or if it's just the new Windows terminal, but I think it's fine. It was in Windows terminal. People need to be using that thing anyway. It's true. It's like opening up on your Mac and just having the bare white bash. I guess it's these all these days, but just the completely non-fix font. What is this thing that you are running? The terminal is horrible. Well, that thing is, but you could make it a lot nicer by the way. And you know, it's similar trade off there. Right. And Windows world. So, okay. Interesting. Next one is should we adopt calendar versioning? We're beyond zero version. So that's really good. But there's been a reluctance to have Python 4. We've got 3, 12, 3, 13. Are we just going to have 3.128? Or should we come up with something else? What is calendar versioning? And should we adopt it? And how many digits should it have? Yeah. So this was presented on by Hugo, who is the new release manager for Python 3, 14 and 15, which maybe that's a little presumptive saying those numbers. Because if this goes through that would not be the case anymore. He's going to work himself straight out of a job here. What's going on? Right. Yeah. Yeah. Yeah. This is this was there were definitely jokes about like this is just your attempt to to get out of being the release manager for these releases. But yeah, so Hugo proposed this. Well, this is kind of like a pre-pepp feeling out of how this situation should be. And like trying to pair down the options, I think was Hugo's biggest, biggest question. What should we do it? And should we pair down the options? Because there's a million different ways we can do calendar versioning. And yeah, I think if you scroll down there was like a slide that had just, you know, every single possible calendar versioning. Possibility for Python and all the different languages. But yeah, calendar versionings like really common for programming languages and other things that are similar to Python. And so this was basically like, hey, we have this yearly release cycle that has been working for a while and we're probably going to keep doing it. Should we? It's worth pointing out for people who don't know that it used to be 18 months. And so the calendar versioning would get a little out of phase or something there. But now that's yearly in the fall, it really lines up perfectly. Yeah. And so this kind of assumes that we're going to keep doing the yearly thing, which I'm fine with the yearly thing. But yeah, as long as we kept the yearly schedule, it would line like the release year would line up with whatever the so it would be like the ended the one that was like most agreed upon was like three dot and then a two digit year or what would end up becoming a three digit year when we roll over to 100 assuming that Python's still used them, you know, 100 years. But yeah, so like that was kind of like the one that was most palatable to to core devs or people were most excited about. And I think the big reason why switching to like a calver year was interesting is that we have this thing called like support lifetime. So like how long is see Python supported? How long do you get security fixes? How long do you get bug fixes? Right. Let me. Yeah, exactly. Like let me put this out to the audience. Is Python 3, 8 supported? Or is it not supported? I don't know. You got to do you got to do math? I got to think about it. Yeah. So 3, 7 just recently dropped support, right? Which is crazy because that seems like a pretty new version of my mind. But I totally make sense. But if you just knew it's supported for how many years, six years, five years, it's five years for security releases, I believe. Yeah. So then you're like 2025. So, you know, 2020 out. The one that becomes a lot easier. And there was also say like, do I have the current one, right? If you're not tracking it super carefully, like 3, 11 is that the latest? Like I don't know. I don't know. I only use Python every like once a month. Well, it's a 2023. Oh, I see. Well, maybe that's not the latest one. Okay. Yeah. So it was just an interesting conversation about figuring out what the best potential option was. And then Hugo ended up creating a pep. And I think that's being discussed right now. So cool. Why not 2024? Why 24? Because that feels, I don't know. It just feels like you've just point shifted what you're doing now. Rather than then really clear, because you know, as a new person coming in, you don't see that go. It's 24. So it must be 2024. And unless you really like put together the calendar, but if it's a dot 2024, you're like, I bet that's the year, you know, right? Yeah. I mean, because eventually that in the not too distant future, there will be a Python 3.24. Exactly. Yeah, we'll see. So there's going to be a pep around this, you say. In fact, it says right here, pep 604, right? I think it's pep. What is it like? Wait, no, that's just the yearly enough. You scroll down all the way to the bottom. It'll, I think it's peps. Yeah, there's a lot of drafting. It just says drafting a pep. Give that a click. I'm pretty sure there's a number 2026. There you go. Okay. Yeah. Oh, so that's going to be a while. So they released this pep. Well, so the most the most important part of this discussion was that the the Python version 3.14 be be preserved. Python. Yeah. Cool. It wasn't allowed for 3 3 14 to change it. Yeah. The only thing that I can think of that you would have the two digits is that there's a lot of code and regular expressions and junk out there that checks for that. But you know, if we talk about some of the other stuff out there, like that's a pretty minor change. Like for example, free thread of Python. Yes, free threaded Python. It's here. It is here. Sort of. Yeah. You know what actually really surprised me is when I saw this pep come through. Was it 702 or something like that? It said, we're going to allow free threaded Python, which I'm going to have you explain for folks in a moment. But you're going to have to have a special build of it. And I thought, oh, well, that means if you want to play with it, you're going to have to build your own. But I noticed that the installers now give you an option for it. Yeah, they do. Yeah. The other side by side install. Right. Yeah. The what is it? I think there's like a T that gets put on to your actual like, yes, Python T is what you type instead of Python. Yeah. If you want the free threaded one. Yeah. Yeah. I mean, free threading is here. I mean, there's options. If you're compiling yourself, you just enable some options. And I think I go over that in the actual blog post, too, the options that you actually use to try it out. And yeah, free threading essentially is it's a way to remove the gill and move to a different like reference counting model, object counting model. Which is quite exciting for a lot of people. But it will end up meaning is that a lot of the packages that are written in C or that are relying on C Python APIs will have to get either tweaked a little bit to like use these slightly different C APIs to make it so that they play nicely with having no gill enabled and with the new memory management. Yeah. It's super exciting. It changes from the ecosystem basically. Yeah. Just because you have threads doesn't mean you get perfect scalability across the course. Can't remember who wrote this article Simon Wilson maybe who did a some yeah, a pretty sure Simon Wilson wrote one that said, look, we're going to take an algorithm that can is kind of embarrassingly parallel and parallelize it. And it turned out to be something like 50% gain per core. So it was like he had eight cores and it was four times faster with free threaded Python and without just still if you can get your code to run four times faster, that's still really good, right? Yeah. But it's it's going to have like you said, I think it's going to have an interesting requirement put on all the people building packages, right? Yeah. I know when I hear it, people say, I think maybe you just said, like, oh, it's going to be the C extension packages that are really going to have to deal with it because they they'll have to do locks in their thing. I think even in the Python code, there's certainly algorithms that have multiple steps that they'll get some data here. They'll work with the data. They'll make some changes. Then they'll put the data back in the same place. And even that would be subject to a race condition. Yeah. Right? And I think we're, you know, I've in long in the past did a lot of C++. I did a lot of C sharp. And in communities like that, people are like always focused. They're like always kind of crazy about two things memory and threading. And we just don't do that in Python. We just I think we have just leveraged the fact that the gill gives us kind of enough coarse-growing granularity of the execution of our code that is just not something we hit a lot. And we don't try to do a ton of threading because it doesn't work all how well. However, this could expose lots of stuff. This could put a new focus on that. Yeah. Yeah. Just having more people using threading with Python that that's going to be huge for finding thread safety issues. Yeah. It's it's just really exciting. I think that and there's another blog post a police upper one that talks about like the C API. And there was some mention about like free threading and evolving the API so that it's a lot easier to use from a free free threading perspective. So like there's a ton of work happening in here to make this as easy a hopefully brief kind of split in the ecosystem and then have it converge together. I think that's like the overall plan is like, okay, we got to we got to have a way that if this is really not working out, we can go back. But if it is working, we need a way that we can actually land this thing as the default. Right. Right. And the pep discusses this is like, we're going to we're going to see how it goes. Yep. Which is really interesting. But I think it's not breaking in the sense that you can't still run Python 3 with the thing that you've got. You just might not be able to enable this free threading aspect of it for some time. Whereas from two to three, it's like, you cannot run this library on three period. There's no scenario which this is going to work because it needs to take into account this and it doesn't. And so it's out. So I feel like there's more time and space to evolve it. And you could say, well, in this space, you know, in this data science section of the world, we use these seven libraries. And we're going to work and make them compatible so that we can get way better performance or, you know, we're going to work to make sure that fast API and pandemic support it really well so that we can scale our web servers better. Yeah. Yeah. No, this will be huge for, for like web and data. I think that a lot of people are excited for this for really good. Yeah. Yeah. I totally agree. I totally agree. Okay. So this is a big deal. It's coming in 313. But you've got to run Python T for now. Yeah. It's 313. But it's also available in the pre-releases. The first release candidate for 313 is out. So give it a test. If you haven't given it a test, give it a test. Yeah. Very cool. All right. What? What one do we want to talk about next? We got just a couple of minutes to cover. We've got what about Python and mobile? I think that one's I know there's the the black swan talk that Keith Russell McGee gave and Carol Willing also sort of shouted out like there's a couple of places that are really, really important computationally in the world that Python kind of isn't we should have it there. And those number one is gotta be mobile. Yeah. Mobile and front end for me mobile and front end are the two. And like a far distant behind that is like could I get a single binary out of my app that I can give to someone that's a different that also is in there. But it's it's like not as important as hey, I want to I want to build some mobile apps. Can I use pi you know, I want to learn with an easy language. I need to find out like and ask me something else. Yeah. Yeah. Right. Like next question. Yeah. So this was this was a it's almost like a a big status update on where Python is in the mobile space, which is really exciting because they've made a ton of progress on getting like actual tearing of support for these platforms. So if you don't know Python, has a like platform support tiers where it's like tier one is like x86 Linux, right? Like that's a you know 90% of pipe API downloads are are that like yeah, well, you want to support that one. And then as things like macOS, you know, x86 and arm and all of that, right? And then lower down there's tier two, which is, you know, the platforms that they have people that are interested in them. But if those people were to go away, then we wouldn't actually have a way to support them. And tier three is like even more so, right? So having tier three support for Python for both Android and iOS for 313, like that's super exciting. It means that these things are getting actively tested. There's like integration testing on real platforms and that there's people that care about it that are fixing bugs. And this is exactly what you need to get your platform supported. And so this is all being provided by anaconda funding this project and beware. Okay. Yeah. That's right. They are you know, beware and Keith has been on this for a long time. But anaconda have come along and but more time and energy behind it in terms of funding and people's well, I'm not sure, but certainly in funding. That's awesome. Yeah. So I think this was it was both a status support and also kind of trying to figure out how these sorts of platforms can get tested more easily. And like actually not having constant breaking because these platforms are so different from, you know, what almost every other core developer is using to develop Python are a lot more limited in terms of capabilities and like lock down in the security perspective too. And they have no regard for backwards compatibility. I'd so frustrating. I got I you know, I have mobile apps for the talk Python courses that are both iOS and Android's app stores. And I'll get messages like, hey, dear developer, if we see that you're built against three-year-old APIs, if you don't rebuild and republish your app in the next six months, we're taking it out. The last one I did this for was Google. I'm like three, three years, okay. Can we know, can't get any better compatibility than that? Like I just got to keep re uploading the same thing even if there's no changes. Like so you know, that's just a different mentality. I'm like, ah, we changed all that. We don't like that anymore. Yeah. Luckily, I'm actually not sure how affected Python in particular is by things like that because that's like utilizing APIs like mobile SDK APIs versus like the operating system of the phone, which yeah, right. Like people would build apps with Python and then they would be subjected to these emails. And it's not even that I was naturally using any of those APIs. It's just like we see your compiled against the wrong version. So try again, you know, yeah. No, the yeah, the the difficulties that I've at least from from this talk have figured out is that like these platforms are just a lot more lockdown. So like a lot of system calls won't be available that the test suite like assumes are available always. Sure. It's almost like a circuit Python sort of deal. But exactly. Yeah, it's like, it's like somewhere in the middle and figuring out how to all work together happily and develop on this similar code base that has all these different target platforms. Yeah, absolutely, absolutely awesome. Well, I'm I'm really excited. I'm all here for it. If three years ago, I think it was when we started working on those mobile apps, if I could have used Python in a really solid way, 100% those apps may be built on Python. But just there's so many so much tooling and stuff around now, you got to create a signed APK before you upload is there's a lot of stuff going on there. And so hopefully they they get that that would be we game changer. And just, you know, it's not on it wasn't here almost surprising me that it wasn't here, but front and stuff, WebAssembly, Pyserscripts, Pyodide, all those things, I think are in that same realm, although they can just kind of ship stuff to the web because there's no gatekeepers, but still. Yeah. Was that mentioned anywhere during the the summit that just didn't make a post? No, wasm was not there was no topic about wasm specifically at at this language somehow. Yeah, sure. I think there was the previous year. Previous year there was. Yeah. Should we make PDB better this matter? Are people using PDB? What do you think? Yeah. So this this was all about PDB is Python's debugger for people that don't know. If you've never used it, it let's see it kind of like drop into set a break point in Python and then drop into that exact spot with all the context and everything, which is really at a lower level. Yeah, at a lower level than a VS code or PyJarm. Right. Exactly. Yeah. Seeing all these like super internals of Python, if that if that's something that you really need. Right. And so this was a talk that was mostly about, okay, we're we have PDB, but now we have all of these new models like free threading and all of that. And also we're being a little bit held back by backwards compatibility. There's like a specific really specific point where because of backwards compatibility reasons and PDB is a part of the Python standard library, it becomes difficult to break backwards compatibility even if it would mean you get a bunch of really good stuff out of it. You can't always do that because people are depending on it. And I think that the yeah, the recommendation was maybe we should develop this outside of the standard library so we can you know, you know, yeah, break backwards compatibility if it's not necessary and and make it so that we can support multiple versions instead of just having it be per version. Yeah. Yeah, that's that's a good idea. That's exactly what I was thinking because you know, there's the whole dead batteries talk like did this still belong here? I'm not necessarily thinking this should not be in Python, but you know, yeah, something broken out maybe, but take that exact code break it out, but you know, enhance it kind of independently. Yeah. And I think the concern from some people in the room was that, oh, if we break this out onto PyPI, then it would potentially mean that it would not get the same level of contribution that PDB sees because it's part of Python, right? Sure. And I mean, totally valid in my opinion too, like being a part of Python is a huge like blessing of like, yeah, this is something important, right? But I think that there's there's other ways to signal that it's something important. Like if you look at like my pie, my pie is underneath the Python GitHub organization. And so maybe something like that, right, where it's this tool that is very actively used by core developers for development. And it is a little bit more official than, you know, just some random person putting something up on PyPI. This is core developers supporting this. And black is that way too, I believe, right? It is. Yeah. So maybe something to signal just a little bit more of an official, this is a core developer tool. Here's why you should contribute to it instead of just, you know, a random project on PyPI, which definitely wouldn't be in that case. It would not. It would definitely not. All right, how about a quick review, maybe some of the lightning talks. Yeah. Any of these stand out, you know, obviously, Rust and Python is seriously a one. Yeah, Emily's talk was, yeah, as I say, Emily's got a good one. Emily has a really good one because, and this is like, it's, it's almost meta, right? Because lightning talks are not submitted ahead of time. You actually have to submit them during other people's talks, like to the list that you want to talk about this. And then put together some slides really quickly. So yeah, these talks are pretty impressive in that way. Having mere minutes. But the Emily's talk was about, it was kind of like wrapping up a theme that was being heard multiple times over the course of the language summit. But obviously, this is a problem outside of the language summit too, which is that when someone goes to make a prototype for a pep, they are given at least today not a whole lot of support for doing that prototype because it's basically like, oh, we think that this should be developed outside of the standard library initially, right? Like that's a really common determination that the String Council comes to. And so being able to have kind of like a standardized way that people do a pep prototype outside of the standard library. So things like creating a repo and like having all of this existing infrastructure set up and maybe even hosting it under the Python GitHub organization to give it some like air of officiality of like, yeah, this is something like really big is happening here. It's not just like someone in a corner writing something, right? Like giving some more grandiosity to to the work that's being done and not just kind of saying, oh, go away. Like that is a pension, right? But that's kind of how it can land sometimes. Right. And maybe setting up people for success at least, this is what we're going to expect from you. If you go through this process, then you've got your further down the pipeline of having 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 about like setting up these exact workflows for publishing to a pipe. Yeah, like that's just a whole bunch of things that are in your way to actually being successful. So having that all be figured out already ahead of time for you makes things a lot easier for you. Yeah. Yeah. Yeah. Let's finish that with Yuri. Sure. So the novice presentation efficient data sharing between subinterpreters. And it's interesting because we talked about free threaded Python. But the year before the big news was subinterpreters and Eric Snow's work and those are not directly competing type of things. But in a sense, they're kind of competing. Yeah, they're definitely competing for being like the model of how to do efficient, you know, parallelism in Python. Yeah. How do we isolate the stuff so that we can avoid the guilt? We take it out and add different algorithms. Or do we just make copies of the interpreter and run them in isolation? But then you have this data sharing issue. I can't just share a pointer easily, right? So what's this about? Yeah. So Yuri basically came with, and this was also if you want the extended version, Yuri also gave like an actual Python talk about this library that he's developed called Memhive. Yeah. What's it called? Memhive. Like many of my HIV. Yeah. All right. Awesome. And just for everyone listening, just this week, last week, recently, all the videos of all the talks are now available on YouTube. So it's been a while coming, but you can go watch it now. Exactly. So go watch them all. If you missed out on a talk, go watch them. But yeah, this so this library in particular is, it's basically a way using immutable data structures. There's this immutable data structure called an HAMT. I actually don't know what it's short for, but it's a send, a hash array map tree. There we go. It was in the, I wrote it down. And it's essentially like a way to have this tree that can be passed around and shared without like worrying what the other processes subinterpreters are, they're not processes. The other subinterpreters are doing to this data structure. So it enables a more efficient and safe way of sharing data that's kind of like in a tree structure. And I think one, the demo that you ended up giving was about a dictionary like data structure where you have a million keys and a bunch of subinterpreter workers working on that data. And they're able to, because it is using this immutable data structure, the modifications and changes are all safe, but it's also like super scalable and performant. Yeah. Yeah. The thing about parallelism and multi-threading is if it's immutable, you could have many things as you want reading from the same memory. It's only when they start writing. Does it matter? So exactly. Yeah. This, this, like, has a way a mechanism to capture the rights in a way that is safe so that like the current one can see what has been written. And then the other ones aren't affected because their copy is not changed. Okay. That sounds very interesting. We talked about the coming compatibility matrix of free threaded Python. This won't have that issue, right? This operates in the every version of Python. Yeah. So this, I would assume that this sort of module would be able to say like I am ready for a GIL-free world. So that's like the mechanism that I believe C Python has adopted for saying that your C module is ready for not having a GIL. You actually have to opt into it and then that module will will be allowed to run in free threaded Python. Yeah. It's something I recently learned is there's separate wheeled builds for free threaded Python as well. Yeah. That's interesting. Yeah. It's its own, I don't know exactly the phrase for it, but yeah, it's own wheel tag platform target or whatever. Yeah. Free threaded gets appended to macOS ARM64 or whatever. Exactly. Yeah. Awesome. All right. Seth, this has been great. How about some parting thoughts? Let's close this out. It was just takeaways from the whole experience. Yeah. I mean, the language summit is lovely. One of the things that's most important to me is this whole aspect of storytelling. And so that's why I felt really, really happy that I was invited along to be able to tell these stories to all of you. And I think that having all of these different narratives all in one place of all of these huge themes about what Python is going through all it wants. It's really incredible how many different things are happening in Python all at once. And sometimes when you're focusing on just one or just two, you don't have this huge context of, wow, Python is changing in at least 20 different ways all at once. And we're somehow doing really, really well. I would say I have no doubt about any of these huge changes that Python is going through to take in the wrong direction. Like I'm feeling hopeful and excited about all of them. So it's an exciting time. Yeah. I am as well. And it is really tricky to get a picture, a holistic picture of the progress, because there's a lot of different groups doing different things. And there's no one person's or one company's job to get somebody to come and tell that story. So yeah, thanks for giving us the insight here. It's been awesome. Yeah. Thanks for being on the show and I'm sure we'll have you back soon. Yeah. Sounds good. Thanks. See you. This has been another episode of Talk Python to me. Thank you to our sponsors. We're sure to check out what they're offering. It really helps support the show. This episode is sponsored by Posit Connect from the makers of shiny. Publish, share, and deploy all of your data projects that you're creating using Python, Streamlit, Dash, Shiny, Boke, Fast API, Flask, Corto, Reports, Dashboards, and APIs. Posit Connect supports all of them. Try Posit Connect for free by going to talkpython.fm, slash, Posit, POS, IT. When you level up your Python, we have one of the largest catalogs of Python video courses over at Talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription insight. Check it out for yourself at training.talkpython.fm. Be sure to subscribe to the show, open your favorite podcast app, and search for Python. We should be right at the top. You can also find the iTunes feed at slash iTunes, the Google Play feed at slash play, and the direct RSS feed at slash RSS on Talk Python.fm. We're live streaming. Most of our recordings these days, if you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm slash YouTube. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code.
\ No newline at end of file