#375: Python Language Summit 2022 Transcript

00:00 Every year, the Python core developers and a few other key players in the Python ecosystem meet to discuss the pressing issues and important advancements at an event called the Python Language Summit. While Python is a community known for its openness, this meeting is typically held behind closed doors, mostly for efficiency sake. On this episode will give you a look behind that door. We have Alex Weygood here on this episode to break it down for us and give us a report from inside the Python Language Summit.

00:30 This is Talk Python to me. Episode 375, recorded June 29, 2022.

00:50 Welcome to talk Python to Me. A weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Twitter, where I'm

00:56 @mkennedy, and keep up with the show.

00:58 And listen to past episodes at Talkpython FM and follow the show on Twitter via @talkpython. We've started streaming most of our episodes live on YouTube. Subscribe to our YouTube channel over at Talkpython.FM/YouTube, to get notified about upcoming shows and be part of that episode.

01:16 This episode is sponsored by Reflect.run. If you can browse the web, you can use Reflect Run to create sophisticated tests for your web app. And it's brought to you by Microsoft for startups founders Hub. Get early stage support for your startup and build what you've been dreaming about.

01:35 Transcripts for this and all of our episodes are brought to you by Assembly AI. Do you need a great automatic speech to text API? Get human level accuracy in just a few lines of code? Visit talkpython. Fm/assemblyai. Alex welcome to Talk Python to me.

01:49 Thank you. It's great to be on the show.

01:50 Big fan of the there's so much going on with the Python Language Summit, especially this year. I think there's quite a renaissance of new ideas to sort of look at the foundations and the fundamentals of Python, and a lot of it has to do with speed in different aspects. Maybe that's through threading or through raw performance or reference cutting garbage collection. And so we're going to dive into all those ideas and more by just talking about your coverage of the Python Language Summit 2022 is going to be super fun. But before we get to that, let's get to your story. How did you get into programming in Python and how did you get inside the Language Summit anyway?

02:25 Oh, yeah, sure. So I started programming actually around two years ago, but my first kind of code during the pandemic started off as hobby.

02:35 Still.

02:35 Still. There actually is a hobby had to have something to do while staying indoors.

02:39 Exactly, yeah.

02:40 So Python is my first language and I'm entirely self taught. And yes, once I started, I couldn't stop.

02:46 That's cool. What kind of things were you looking to build? Were you just looking to learn a language or did you have some idea of something you wanted to create?

02:54 So I was doing a journalism masters at the time. And there's a sub community of journal coders, people who use programming languages to gather data, scope the web to find stories, essentially. So I thought that sounded pretty cool.

03:10 Yeah, that sounds very cool.

03:11 Yeah. So started learning Python to help with that and then sort of started developers actually enjoyed Python quite a lot just to authenticate a card game using Py Game, my first project, which was a lot harder than I anticipated, all the.

03:29 First projects are oh, yeah, definitely.

03:32 And then built a bad website using Flask and then eventually started contributing to open source. And that's about where I am now.

03:41 Fantastic. Yeah. That's really cool. It's interesting that you bring up journalism. I had Carolyn stransky on a little while ago, pre dated the Pandemic. Is it? Did it? Yeah. Maybe not, I don't know when the Pandemic was a couple of years ago. Anyway, we talked about Python and it.

03:58 Looks like you just hit before the start.

04:02 Just before it really kicked. Exactly, yeah. We talked about Python and AI in journalism, and there's a ton of neat things that people are doing to sort of automate the act of gathering data and reporting on it.

04:17 Right, yeah, no, it's a really cool space. Directly employed in journalism is my full time job at the moment. It's something I'd love to dip into again at some point, for sure.

04:27 Yeah. Carolyn was talking about things like monitoring certain websites, like the national geography, whatever the foundation there is there that lurks people about earthquakes. And I would bring up details and sort of prefill. So, like, some folks in LA, in the LA Times or something, would get an alert, there's an earthquake here's most of the details, put the details around it and hit publish within ten minutes or whatever. That's pretty cool. Little beep. And then go away. Your article.

04:56 Now, one of my first products I tried to do again biting off much more than I could do was there's. In the UK, we have this body called Historic England, which catalogs England old buildings and heritage assets. And they have this all online, but it's not like in an easily downloadable form, just like, download the CSV of the National heritage list. So I decided I was going to try and scrape this on the website, because the scraping is easily but then the data cleaning is a nightmare because there's no consistent format, and sometimes in the 1950s, horrible.

05:30 Well, it would have been cool if you could have gotten it right and shared it with everyone.

05:34 I got somewhere there, but yeah, way too difficult for one man. I just started learning a few months ago.

05:42 Yeah, of course. It's those kinds of projects that are really good for learning programming. Oh, yeah.

05:48 I learned a ton demographic.

05:50 Yeah, you're like, here's my goal. And then you just start frantically searching for. Like. What are the steps I need. And then how do I make those steps happen in my programming language. Python in this case. And you might not normally care to figure out. How do you parse a CSV file out of disk. But you're going to have to do it now because you're trying to aggregate. Add on to it. Append on to it and so on. So, yes, those kinds of things are great projects. Cool. All right, well, how did you get into the Python Language Summit? From a journalism angle, from the open source angle. What's the story here?

06:20 I was invited in the autumn, I think, to become a triage with CPython. So at that point, I contributed a lot of docs documentation fixes, just something I was pretty good at because of the journalist and masters.

06:34 You actually know how to write.

06:36 Yeah.

06:38 I'd also contributed code to a few modules at that point, few small fixes to, I think, funk tools, enum. Yeah, a few standard led modules.

06:48 So I've been invited by Ken Jin, who's one of the typing module maintenance to become a triager in the autumn so that got me onto the CPython Developers Discord Channel. And then I think it was February or March, there was a discussion, there were a few court houses were asking who they were going to invite to become blogger this year.

07:09 You know, Alex does journalism.

07:11 Yeah.

07:13 I got this Masters. I mean, could maybe I do it? And I said yes, which is very flattering.

07:19 Yeah, fantastic.

07:20 Great.

07:21 And I really appreciate it. So it's Ukash Mariota and Sentel. This year, the organizer in Language Summit So massive thanks to them for inviting me to be lucky this year. I appreciate it.

07:33 Yes, that's great. You must have been also at PyCon then, I'm guessing, because if you're at the Language Summit, you're at PyCon. Yeah. What was your experience? There was a good time.

07:41 Yeah, I had a blast. It was great. Yeah.

07:44 Awesome to meet all these people I've been doing open source stuff with online for several months. Yeah, it was really cool.

07:51 I really appreciate these conferences because there's people I work with or talk to in different ways through GitHub, through Twitter, through the podcast, but you don't really get to see them in person because they're halfway around the world until you show up and have a beer together or hang out together.

08:09 The talks are fantastic. But yeah, that was definitely a best for me.

08:13 Yeah, that's the same for me, actually. That's the thing that I dig the most. All right, let's talk about the Language Summit.

08:18 Sure.

08:19 So maybe tell people really quickly, what is the Language Summit?

08:22 Sure. The Language Summit is an event every year. It's just like a day or two days before PyCon itself starts. Most of Python is available to just like, anybody who's interested in Python. The Library Summit is generally only available to developers and special guests, so it's a bit exclusive. That's not because they want to be secretive about what's happening in there, more so that it can just be a sort of frank conversation between trends, I think sort of makes sense.

08:53 Yeah. It's where the business of planning out Python gets done.

08:57 Right, yeah, exactly.

08:59 It's not the only place we have our PEPs and we have other places where conversation happens, but it seems like one of the places where some of the ideas of the PEPs are discussed and there's a quick feedback loop amongst a lot of the core developers.

09:13 Yeah, exactly. It's just get everybody together, all in one small room, talk Python for the whole day and then see what comes out of it.

09:21 Awesome. How many people show up there? How many core developers and other folks?

09:25 Around 30 this year, I think. So mostly core developers, a few triages and a few special guests. So Zac Hedgehogs. I think some hypothesis was there. Sam holds in some pydantic. So, yeah, a few open source maintainers outside the Cordev team as well, right? Yeah.

09:46 Pydantic. Interesting. Obviously a great library. It's interesting to me because a lot of its meaningful functionality is in the way that it breaks with the tradition of Python.

10:00 Now all of a sudden don't just mean something, but they are the core way in which that library works, whereas most of the time it's a suggestion or a hint, as the name would suggest.

10:09 Sure, yes. And in a way, it's quite coercieve as well, so you don't have to.

10:13 Like yeah, for sure. So he's a good guest to have because he's both got a popular project and one that's kind of an outlier to some degree.

10:21 It's huge, isn't it?

10:23 Yeah, it sure is. We've got SQL Model by Sebastian Ramirez, which is basically take Pydantic models on top of SQLAlchemy. And you've got Beanie from Roman Wright. And there's some other ones that are just, like, sort of using Pydantic as their layer, which is really cool. So, obviously the reason we're chatting today is this year's summit was covered by Alex Way. Good. That's awesome.

10:47 That's me.

10:48 Nicely done. And so when I saw this article, or series of articles, I guess you might say, come out, I thought it was really fantastic because, like I said, I think there's just so much that's exciting going on here. No, it's not. Well, we're going to change the language a little bit here and there, but there's stuff that everyone's going to get.

11:08 Yeah, absolutely. So I thought what we could do for our conversation is just go in order and just sort of chat through them. You can give me a sense of what it was like to be in the room, what are some of the main ideas of each of these, and we'll just chat about them. So the first one was a very exciting project by Sam Gross, who I think works for Meta. I think he does part of the sender stuff. Yeah. And this is python without the GIL or no Gil.

11:36 I don't think he's on the Cinder team, but yeah, he's working.

11:39 Right, okay, cool. Yeah, there's other stuff from Cinder we'll get to later, but yes, Python without the GiL or his no Gil story, there's been from a historical perspective, we've had attempts to remove the GIL or change the performance characteristics of the GIL and so on. Maybe let me just set the stage a little bit with this GIL or Global Interpreter Lock for people listening when I heard this, the Global Interpreter Lock means you can only run one statement of Python at a time, even if it's happening in multiple threads. I thought, okay, well, this must be some odd constraint put on the language so that things like threading are easier for people. But as I learn more about it, the real purpose of the GIL has nothing to do with threading per se. It has to do with memory management.

12:28 The way memory management happens in Python, at least in the primary first pass sentence is it's reference counted. So everything number, strings, classes, dictionaries, they all have a refcount. And if that ref count ever reaches zero, it gets deleted as long as there are no cycles. And the problem is, if you're going to change that number on the object, normally you would have to do that in a thread safe way. You will lock it, but that turns out to slow single threaded Python down a lot when it's unneeded. And so the Global Interpreter Lock is there to meant to basically allow for that reference counting to happen quickly in the single threaded case. And that made fantastic sense 30 years ago. Now that we're sitting here with our 16 and 32 core CPU, all of a sudden we might want to run more than one thread and get stuff done. You know what I mean? Yeah, that's the history of the GIL. And so there were other things like Larry hasting he was there, right?

13:22 Yeah. Just to interject for a second, it's really fun to see sort of how long the project has been to try to remove the GIL. You can go back ten years ago, and as I talk about David BSV on weird things going on with the GIL in 2010, and then I was writing this after the summit, looking through the archives past language summit blockers.

13:45 I think there's three successive years running where there's presentations about the latest project to remove the Go. But like this time it actually seems like it could happen.

13:54 It could happen, yes, it certainly could. Sam Gross's work seems to be the most likely candidate. And all the other attempts, their challenges have been, yes, you might remove the GIL and you might make the parallel computing faster, but you're going to make single threaded Python so much slower that we don't want to accept it. Right. If you could say well, you can use all the cores on your machine, but now everything runs half as fast as that's. Not a huge benefit to a lot of people.

14:20 Yeah, and especially because of the fact that the GIL's been, after so long, vast majority of paths and coaches with only one third.

14:29 Well, it could make patent code faster, but only if you rewrote all of your code, which is true.

14:36 The other major problem or challenge that is there is how does it work with the C extensions that are so important to making Python work well, right. NumPy and all those types of things. Right. So Larry Hastings was there and he worked on the Gillectomy Me, which I think is still the best name of all these projects. The Gilectomy The removal of the gil. Yes. But it sounds like he thinks that Sam's project is already farther than his.

15:05 This portion of Talk Python to me is brought to you by Reflect Run. Reflect is the fastest way to create end to end tests for your web app. Most of us have encountered flaky, unreliable tests over the years. For a lot of us, testing our code is painful, but it doesn't have to be. Reflect was created by developers who are tired of dealing with constant problems inherent in codebased testing tools for web apps. Reflect is an automated no code testing tool that enables you to shave countless hours off your end to end testing timeline. If you can browse the web, you can create sophisticated tests with Reflect. Navigate to your site within Reflects simulated browser and perform the actions you want to test. Reflect will autogenerate selectors and do the painstaking work of test creation and maintenance for you in minutes. Instead of creating and maintaining a separate code base for your tests, you can manage all of your tests within Reflect. Features include visual validation, efficient for debugging and eliminating weights. Cross browser testing run tests across all modern browsers, including Safari, Chrome, Firefox and Edge, and email and SMS validation. The best way to appreciate what Reflect can do for you is to see it in action. They put together a nice six minute video you can watch at Talk Python FM/Reflectvideo. That's Reflectvideo. I encourage you to watch it and see how straightforward and composable their tool is to use. Once you're ready to try it out, sign up at Talk Python FM Reflect. It as a special offer for Talk Python listeners. You'll get a free T shirt when you sign up through this link. That's Talk Python.FM/reflect to see how easy web testing can be. The links in your show notes. Thank you to Reflect Run for supporting the show.

16:45 Maybe tell us a bit about what Sam was proposing there.

16:48 So, yeah, Sam has got this fork of CPython where he has removed the Gil, and it all works. I think that's still a few rough edges, but all basically works. Essentially so now he is looking to if you want to, you can try that right now. You can go and download Sams for no Gil and most Python programs will run fine on it. That's it right there.

17:12 Show notes.

17:12 Yeah.

17:13 People can check out the GitHub repo and it's just a fork of CPython and then go from there, right?

17:19 Yes. And now Sam is hoping to essentially create a separate mode of CPython that you can enable with the compiler flag, which would enable no gil. So together this changes merged into CPython main branch.

17:33 So that would mean you would have to build CPython separately in order to get a version of cycling when no deal would work. So it wouldn't be like you be able to just open up the app and go like import a deal. It wouldn't be quite that easy.

17:47 Right. It is a bit of a hassle that it's literally a separate compilation stepper, binary and so on. But maybe the CPython distribution, if this really works out well, could be shipped with that. Like it could be a set of Python or Python Three or whatever you type. It could be Python Ng or something like that. Some extra command you can run. But at least it would be nice, at least if you didn't have to literally go find a different installer and try to avoid the name clashes of what Python means.

18:21 Yeah, for sure. And this has a change from his original proposal to his original proposal was for a runtime flag. So that would mean that you would be able to I don't know, I don't know how exactly it would work, but do something like important no GIL yeah.

18:34 And reading your right up here, it sounded like Sam has come to a conclusion that there's too many differences for a runtime flag to make sense. And it's got to be a compiled type of thing.

18:44 Exactly. So yeah, that was his proposal.

18:47 How was the reception?

18:48 There were a lot of questions for sam. I think a few of the other proposal presentations finished under time later on in the summit. And then we went back and asked some more questions to Sam because some questions.

19:03 Yeah.

19:03 So I think I think everybody in the room definitely knew.

19:07 It's crazy. If you look at the viewing figures for these blogs, the blog on no Gil is off the charts in terms of how many people have clicked on it and read it.

19:18 Okay, so the last time I checked, it was like 40,000 people that read the No Gil article and the next highest was 5000 people.

19:26 Wow.

19:27 There was a huge amount of interest in this feature. And the people in the room knew that there was a huge amount of interest in this feature. So I think there's a lot of interest in making this work. If it can make to work, sure. But there's just a lot of complications about how to get that. So there were a lot of people asking what exactly the plan is here, because this huge project that I've been working on for months and months, and how do you emerge that into CPython You obviously can't have one PR where you have tens of thousands of lines of code changed a little.

19:58 How do you split that up?

20:01 I think Sam was looking for a kind of preapproval before submitting a pet.

20:10 Taking the temperature of the room to see if it was welcome or unwelcome. Right.

20:14 I think the general mood was cautious, if that makes sense.

20:18 Yeah.

20:18 Like, yes, we need to plan before we give us that was the kind of okay.

20:24 There was some feedback, like from Barry Warsaw and Tamara Streaker about the impact it might have on third party libraries. I think Carol Willing also talked about that because especially these C layers or these native code layers are super common in the data science space, especially. So some conversation about that. Right.

20:44 Yeah. I think there's a lot of concern about with some features needed language, for example, typing was added a few releases back. I'm very involved with the typing community. I'm a massive fan of typing name, too.

20:57 Fan, not involved.

21:01 It's kind of got a little bit of a bad name for itself in some ways because there's a lot there's some people who go to maintain demand that type things be added or whatever. Right. And that's not really fair on the maintenance because everybody's volunteer doing it for free.

21:15 It is getting easier because one of the complaints not complaints, one of the hold ups used to be, well, my library is for python Two and Three, and I'm not going to maintain two versions, and so on and so on. Right. The typing wouldn't work in python two. At least now we're generally past that hold up, but still. Yeah, it's effort that the person might not want to put out there.

21:36 I'm a typeched maintainer.

21:38 Typing tell people about typeched is pretty cool.

21:41 Oh, sure. So typeshed is the repository of steps for the Standard library and also a bunch of third party steps. So if you type Shed is like the only version of the Standard Library that might buy notes or Pyrite or Pi type or any other type check. They don't actually know what's going on in real standard library at all.

22:04 Right.

22:04 They only know this bundle of stubs in Type Shed.

22:12 These are not PY files. These are Pyifiles.

22:15 Yes.

22:16 And if you look at them, the implementation is super straight information. I don't know.

22:23 The implementation of all these is super interesting because all the functions are and the default values are but what you have is you have function name, variable name type, return value type, or class field type. Field type. Field type. Right.

22:40 Yeah. It's like a Python file with like yeah.

22:43 I suspect some people don't even know that this is a thing you can do to improve the understanding of editors and stuff. Right. In mypy, a static type check.

22:50 Will use this information to inform the error that's flagging on your file if you use it to check a file. So if you import appters in your Python project, then and you install Types AppDev, then mypy will use the type in some Type Shed to understand. Okay. This app does instance has an app name of Typestore.

23:13 Do you know what the editors do? Like, does PyCharm already have this information? Does VS Code already have this information from other scenes?

23:22 VS Code? Does use type shed completely. PyCharm, I think. Mostly uses type shed now.

23:29 It was kind of used to have their own way.

23:31 Yeah. I think it was a bit of a journey for them to move to Type Shed. I'm not sure if they're 100% do yet.

23:38 Okay, very interesting. We're talking about the CPython stuff and Mr. hypermagnetic ask will C python ever become Rust python? They also point out that Type hints save lives is great. But back to the first question. Did that come up? Did rust ever come up? My first thought is at the pretty far bridge, but did it come up?

23:59 There is already Rust Python. I think you can go and use that if you want. Sure. I think it's quite a long way from becoming the default and becoming the leading version of the reference implementation.

24:11 Yeah. Okay. We can come back to that a little bit because it'll circle its way back a little bit.

24:16 Yeah.

24:16 All right, we're halfway through the show and we've got one of our items done. Fantastic.

24:20 Yes.

24:22 We'll pick up through the next one is Per Interpreter Gill, which actually has been a little bit around from Pep684, and it's still in draft mode from Eric Snow. And so this also goes back to dealing with the GIL, and it tries to, instead of remove it, say, well, you know, what the gil does is it makes you have single threaded code. So what we're going to do is if you want to run a thread, you just start a new subinterpreter in the same process. And sure, it has a gil, but it's meaningless because there's only one thread per interpreter. And so it's a way to kind of sidestep that problem. Right.

25:00 Yeah. It's kind of funny. So first talk because like, yeah, let's get rid of the gil. And then Eric comes along and says, what if we had lots of gil?

25:08 The problem is the gil is shared.

25:10 Yeah.

25:10 Although we got to rename it if there's a Perinterpreter gil.

25:14 Yeah. It's not global.

25:15 It should just be a Perinterpreter ill the GPU. The global doesn't make sense anymore.

25:20 A pill.

25:22 Yeah, a pill. Yeah. That sounds a little bad. But it's interesting to point out, like you pointed out in your article here, that back in 1997 posted something saying massive changes for separate thread state management, all per thread global are moved to a struck which is manipulated separately, basically trying to do the same thing. And it turns out though, that through another picture that you've got laid out here, there's actually a lot of global state shared across threads and different things. Right. That's the problem.

25:55 I think, if I understand it correctly. I mean, eric emails as well.

26:00 I have had them on the show before, so I'll link to that episode as well.

26:03 I think it is possible now to run multiple interprets in the same process, but it just doesn't work very well.

26:18 Okay.

26:19 Yeah. So it sounds like he's been working on this for a long time. I think you opened with a funny quote. Hopefully the speaker began, this is the last time I give a talk on this subject. He's been working on it since 2014.

26:32 Yeah, I think at the time he gave a talk, he was hoping to get it in for 3.11. That didn't quite make it.

26:39 Yeah, exactly. So maybe it'll be 312 because 311 is already frozen and it's still in draft mode. Okay, so that's a good one. People can check that out. There's a tension between many of these projects in that the optimizations one are making might be complicating the work the others are doing.

26:58 Yeah.

26:58 And that's also true for the next one here, which actually I think is the biggest news of Python 311 improvements. Yeah. Performance improvements for 311.

27:07 I feel like it's a shame that so many more people read the no gil one than this one. Actually, in a way, I've been watching a few bits before I know how much work has been going into this and I think it's really impressive.

27:20 Yeah.

27:20 So essentially the top line news from this is python 3.11 is going to be about 25% faster than Python 3.10.

27:30 So this is mainly a result of implementing a Pep by Mark Shannon. Not sure I can remember the number of the peps.

27:37 It's known as the Shannon Plan. I'm making Python five times faster over five years or something like that by doing this 1.25 x per year, which they did it this year. That's incredible.

27:48 The main junk of this is that there are loads of small optimizations that are gone into this, but a lot of them have to do with implementing what's called the specializing adaptive interpreter.

27:58 Okay, what does that mean? What is that?

28:01 So this is essentially an interpreter that monitors your program as it's running and stops if you got an inefficient byte code that can do lots of different things. So like, maybe it's an add by code that could plausibly I almost certainly get some details along here.

28:22 Maybe it could add two lists together or add two ins together.

28:26 It's just like a generic ad by code and then the specializing adaptive interpreter will spot oh, hang on. OK, we're in a tight loop here only into being added here. We can replace this by code with a more specialized one. She'll do the same thing faster.

28:42 Yeah, because there's probably a lot of checks and different types of bits of indirection to let it add strings and lists and so on. But if you know it's numbers then just do the number thing without the checks.

28:51 Exactly. So that's known as quickening. So like as the program is running, specializing adaptive interpreter quickens the code and replaces by code with a more specialized one.

29:04 This portion of Talk python to me is brought to you by Microsoft for Startups Founders Hub, starting a business is hard. By some estimates, over 90% of startups will go out of business in just their first year. With that in mind, Microsoft for Startups set out to understand what startups need to be successful and to create a digital platform to help them overcome those challenges. Microsoft for startups founders Hub was born. Founders Hub provides all founders at any stage with free resources to solve their startup challenges. The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections and much more. Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor backed or third party validated to participate. Founders Hub is truly open to all. So what do you get if you join them? You speed up your development with free access to GitHub and Microsoft cloud computing resources and the ability to unlock more credits over time. To help your startup innovate, Founders Hub is partnering with innovative companies like OpenAI, a global leader in AI research and development to provide exclusive benefits and discounts through Microsoft for Startups Founders Hub, becoming a founder is no longer about who you know. You'll have access to their mentorship network, giving you a pool of hundreds of mentors across a range of disciplines and areas like idea validation, fundraising, management and coaching, sales and marketing, as well as specific technical stress points. You'll be able to book a one on one meeting with the mentors, many of whom are former founders themselves. Make your idea a reality today with a critical support you'll get from foundershub to join the program, just visit talk python FM Foundershub all one word the links in your show notes. Thank you to Microsoft for supporting the show.

30:55 Have you heard of Grant Booker's specialist project?

30:59 No.

30:59 So if you look that up on GitHub, it's a project that he published a few weeks ago, I think, and it's really cool. You can see it's like visualizes the way Python3.11 will quicken your code that it's running. So I'll send you a custom.

31:18 Points out that they've been following the faster CPython repository and yeah, I'll link to that as well. Mark Shannon and other stuff, the ideas for making CPython faster over time and different things.

31:31 Very cool.

31:32 Yeah. So that does like the idea of.

31:34 Help with all visualizing. It's specializing adaptive interpreter. Okay.

31:39 Yeah.

31:39 Very interesting. So this is the thing, pivots specialist is a thing you can do, and then it'll show you like, a print out of the code where it's actually found improvements.

31:50 Exactly. So it will show you where it's quicken your code and where it's been unable to quicken your code.

31:56 Okay.

31:57 I think the green bits here specialist has quickened those bits of code, but the other bits, it's been like, yeah, don't know what to do here. Got to leave it.

32:05 Couldn't do anything.

32:06 Yes.

32:06 So for people listening, if you just pull up the specialist, get a repository, which I will put in the show notes, a bunch of pictures and colorized code showing you where Python 311 one was able to make it faster and where it wasn't. This is super cool. I never heard of this.

32:21 Yes. And this is the project by Brent Booker, who has been one of the major collaborators on the Faster CPython project.

32:29 Right.

32:29 Coming from the top.

32:30 Yes. What also is neat is this is not just for 311. 311 is the first step.

32:36 312 is going to be it's pretty.

32:38 Well funded, too, right. Like, Microsoft has, I think, a team of six people, possibly working with Guido and Mark, and then also Bloomberg has contributed some resources or some help. Yeah, it's really got a lot of speed here, a lot of inertia behind.

32:54 It, I guess I should say up speed.

32:56 Absolutely. All right. This one actually, I think this is the big news. I know that it probably didn't make the biggest splash of the headlines, but.

33:03 I think it's going to, because this is going to make everybody's codes faster. It's not like one small micro optimization. It's across the board.

33:11 Right. The threading stuff is very exciting and interesting, but I'm going to go out on a limb and say, I think a lot of people think they need it, or they think they want it more than they actually need it. So, for example, if you're running a Web site with APIs and stuff, g unicorn or micro WSGI or whatever, they all spin out a bunch of worker processes, and you can have several worker processes per core, meaning you're already, like, saturating every core of the CPU.

33:39 So in those scenarios, it's nice, but it doesn't help that much in terms of a lot of stuff. You don't really need the threading. On the data science side, you might, but at the same time, you're doing the computation and see. Or you can use Async and Await if it's eye bound. There's a lot of ways where this problem is actually already solved. It just doesn't feel like it's solved. And so this one, though, this fixes, this makes multi threaded code faster, single threaded code faster. It just makes all the code faster, which is great. This could be a given it a run for the money when the listener asked earlier about Rust being the reference implementation for CPython. Well, what is it then? Rpython? I don't know. Maybe CPython isn't the name for the reference implementation for Python. This one here, Python in the browser could put some pressure to move in that direction. Right. So this one has to do with WebAssembly. Tell us about this.

34:28 For a while now, there's been a project called Pyiodide. It's like a third party project which has been monkey patching, essentially CPython to get a version of running in the browser Piodide to spend spaces for several cool projects which are also just starting to take off. Now I feel like we've sort of reached this critical point where it's all finally starting to fit together and make sense. And over the last two years, Christian Heims core developer and contributor Ethan Smith had been working to upstream loads of these changes that Pyodide has been making. To see Python itself should mean that Pyodide doesn't need to monkey packs CPython. There's so much anymore. And Python does actually will just work in the browser, which would be huge.

35:18 Yeah, that's fantastic. There were a bunch of changes made to make this possible, and I can't remember where in the article you said, but yeah, over 60 PR and a GitHub issue, right?

35:29 That's warm. You just like to see the numbers.

35:32 Consider supporting M scripting webassembly as a build target, and guess what? That's not a thing. Now you can actually go in and say --with enscripton-target=browser, to compile CPython. And that's a big deal. I think it's going to make it possible to use Python where you would have otherwise used JavaScript for sure.

35:54 So I think this is possibly one of the biggest gripes that anybody using Python web development has. I don't have to use JavaScript.

36:02 Yeah. People will say sometimes to me that I'm being mean or inconsiderate or something when I say that we might not want to write in JavaScript. Why are you hating on JavaScript? I think the frustration that a lot of people feel in the software industry is not that they necessarily hate JavaScript, that JavaScript is the only option. Like there's almost nowhere else in programming we go, there's one language and one run time, and that's it. That's all you get to use, period. Right. On the desktop, on embedded on the web, on server side web, you can pick tens of languages at least, right? And you pick the one that works well for you and the one you like.

36:42 Except for in the browser, everyone is forced to do this one language, which is frustrating. And so as Python developers, where we like Python, it would be great if we could continue to use the language that we prefer for things like this, right?

36:56 Yeah.

36:56 And now you can. There's a few challenges with this. One is that the WebAssembly binaries are a bit large, not huge. They're not huge, but they're like five or ten megs instead of 50k. So that's a bit of a challenge. But there are places where this is already highly valuable. So, for example, if you're doing like an ElectronJS app, you could write that largely in Python using this stuff already. And it doesn't matter because you already download an entire copy of Chrome.

37:25 What's another ten megs? Is it 200 or 205? I don't care. It's the same.

37:30 Yeah, I think Simon Willison might have done that a few weeks ago.

37:34 Okay. I created an electron JS app with pyscript.

37:38 Yeah, I think so.

37:39 I have to look into that. That sounds really fantastic. Let's see. So this is cool because Pyodide is great, but it's like this sort of project maintain alongside CPython. And this is saying the core developers and the team behind Python are allowing you to just compile a limited version directly. Right. So Pyodide, I could say build on top of this one and not have to maintain their own copy.

38:03 Exactly. Yeah. So we do need to be careful here.

38:06 And scripture and Web assembly are not fully supported by CPython yet. There was a lot of concern about that at the summit. Like, if we say it's supported now, then it's a big statement to put out there. So definitely not fully supported.

38:19 Yeah. Okay, good to point that out. And there's plenty of things that are not supported because they're probably not just they're not ready. Some things that will never, ever be supported, like Tk inter support is probably never coming to the browser, you know what I mean? Or other things that are not permitted by the browsers. Sandboxing rules and so on.

38:39 Anything that can be run in the browser needs to be extremely security conscious because nobody expects to have arbitrary code execute.

38:47 It sounds very suspicious, like you're going to let me run binary code in the browser, but it's subjected to exactly the same rules as JavaScript, and JavaScript gets compiled to binary code and then run anyway. It just feels better that it's like, oh, here's a script. It's like, no, it's the same thing. So very cool. I do want to just point out, give a quick shout out to Pi script, which you also did in your article. This is super exciting. This takes it and makes it way, way more real. This is where you really do put Python in the browser.

39:14 This is built on top of Pyodide, just enables you to embed Python inside an HTML file. And it just works.

39:24 Yeah, it works pretty well.

39:25 Opening tag, Py script inside an HTML file and don't need to download anything. Pretty incredible.

39:32 You can also say source equals app.py in your browser. And as long as that can be delivered as a static file, it'll pull that up and run. I just quick follow up on this. This is a different one.

39:45 I'll roll it. But I do want to point out that I don't know if people noticed. I did a video called Python pyscript WebAssembly, and then I actually created an offline progressive web app with it. So once you've installed this app, it no longer has to download that larger binary. So if you look at the code, it's like super simple. You can get this cool little offline app and it is like launch time down to 1 second, maybe one and a half seconds. And it's just so bizarre to write Python for JavaScript events. So you can say, like on click equals here's a Python function and all sorts of stuff. People can check that out. I'll leave that in the show notes. This is a really big deal, this WebAssembly stuff that's coming in. It's coming from these different angles. It's coming from Pyodide, from Py Script, from the core developers compiling to WebAssembly. All of those things are pretty fantastic.

40:38 It's really cool to see so many people collaborate on the same thing at once from seven different parts of the community.

40:43 It's true. It's happening. There's two parts where that's happening right in this Gil thing and in the WebAssembly side of things. They're not necessarily coordinating, but they're all working on the same problem. And surely we'll get some good outcomes from that. All right, let's talk about the Cinder one next. So this one does come also from Meta more instagram, I suppose, directly. But this comes from the Cinder project, and this has to do with some of the optimizations. You want to tell us about this one?

41:11 These are essentially Async specific optimizations. So Cinder is a formance oriented talk of CPython. So the Instagram team essentially were like, we really love Python, but it's a bit too slow for our web servers. We're going to have the whole thing written in Python. So they forked it and implemented.

41:31 There's a ton of different optimizations implemented in Cinder.

41:35 Many changes. Yeah, if you check out the Cinder project, there's just a whole list of all these different things. Some of them have to do with JIT, some of them have to do with mortal objects, and some have to do with other things as well.

41:49 Yeah, asyncio lazy import. Yeah. Loads stuff going on. Yeah. With all the attention recently on making Python faster, the center team is hopeful that they will be able to get some of their optimizations merged into the main drafts of CPython situation. So this presentation was specifically about some of the Async specific optimizations that they have been implementing in their fork. So essentially the issue is to do with eagerly awaited coroutines. So if you have coroutine, then generally if you have a coroutine function, you'll call that function that will create this coroutine object. That coroutine object doesn't do much until you await it and then make sure you get a result back. But that can be inefficient in some situations, because if the task being done in the coroutine can just sort of finish immediately, then there's no reason to create that coaching object.

42:46 Right. And to schedule it and to do all the stuff on the loop and then wait for it. All of that is just overhead, right.

42:52 What's done in the center fork is they detect when a task can be immediately finished and don't bother creating the coroutine object in that case.

43:03 So let me see If I can come up with an example for people that might make it concrete complicated. Yeah, no, it is, but I think once you get those feel for it's, no problem. It's not that bad. Probably bad to implement, but not bad to understand.

43:15 So imagine you have an async function that's going to call an API, but you might have an in memory Cache that says, have I already looked this up for this particular argument? Right, so your code could say, if this value is in the cache, just return that value, otherwise await. httpx get that first case where you call something that's in the cache by default in Python now, it's going to still schedule that on the loop and it's going to make it run on the loop and wait for all that to happen in this inefficient way. So the optimization is like run it as a regular function until you hit in a wait and then go through that process. Something like that, right? I think so that's my understanding. People can send me messages and let me know I got it wrong. But I think that's the basic ideas, there are scenarios where in my case, if it's in the cache, it doesn't ever really need to be treated async coroutine, ever. You just get the value back like a regular function, but if it goes past that, then it does need to be one. And that's the distinction, I think.

44:14 Okay, cool.

44:15 So there's actually A lot of improvements in performance things coming from the Cinder project. There's this one, but there was also the lazy imports, right. Pep690 and that one.

44:25 And so on discuss.python.org, there's been I think the discussion has reached over 100 comments now on lazy imports. So if you have views, that is where to send them.

44:37 Absolutely.

44:37 That's a whole different proposal where we should introduce an API to enable or disable lazy imports. So with lazy imports enabled at the moment, all imports in Python are eager. So if you type in Import Functionals on top of a file, it will execute the entire Func tools module and then put A reference to that module in your file for you. Whereas with lazy imports enabled, it would see the import functional statement, like, me, I'm going to do anything with that, and then wouldn't actually import the module until the first time function was referenced later on down the file.

45:13 Right. Because the problem is there's a cost for doing an import. It's not like a hash include, which might be a compile time thing. There's an actual runtime cost for every import.

45:23 The Pep Eight says all the imports go at the top to keep them orderly. But if there's many apps that might or might not use some import, depending on what part of it runs right.

45:35 Yeah.

45:35 And so if you could delay that expense only if you use it, that would be great.

45:40 And that's going to have a major impact on startup time for Python CLI apps.

45:44 Yeah. Especially the one that we were talking about. Is this async optimization? So that's the one that was actually covered, but it's just as one of the things coming out of cinder, which is cool. And then I think maybe this path forward for mortal objects, is that also coming out of cinder? Sounds like it.

46:02 No, that's another one.

46:03 Similar, but not the same.

46:04 This is linked to the current up to Gil talk, essentially.

46:10 Okay.

46:11 This is one of those proposals that's kind of very much in the weeds of how CPython is implemented. So it's a proposal to introduce what's known as immortal objects. So an immortal object is well, an object never dies, generally, in Python, as we're talking about earlier, objects have reference count, and if that reference count reaches zero, then the garbage collector comes along eventually and deletes it, freeing up memory that was holding the object. So this Pep proposes introducing a class of objects where the restaurant account would never reach zero, meaning that the object would never be cleaned up by the garbage collector and would never die. So this would have the advantage.

46:53 Yeah, because why are you bothering to, like, check and check on these objects that you know will never, ever have any sort of reason to go away? Right.

47:02 So, like, there's the non singleton, for example. It would be quite right to have a program that doesn't use none at.

47:07 Least once, or the number five, which is pre allocated. Right. As well as the number 200, like the first negative five, and the top 255 or something like that.

47:19 But nonetheless, Python will doggedly keep a reference count for these objects and track where they are. Yeah. So for a lot of these pre allocated object numbers, internal strings, the empty Tuble, I think, is also singleton, the non singleton, these would all become immortal objects if this PEP is accepted. And that would, I think, in the short term, make Python a little bit slower, probably. So I think a naive implementation makes it slower by around 6%, but with Mitigation, you can make it so that almost impacted marginal. But then if you do implement objects, it makes things like a power attempt to gil easier. It might also simply find no deal, I think.

48:07 Yeah, probably. Because once you know something's immortal and probably also immutable, then you can share it all you want.

48:15 Yeah, exactly. So you don't have to worry about it.

48:17 Yes. Some of that state that's really hard to create one per interpreter is like, well, it doesn't change. So here it is. You don't have to check it either.

48:25 It just kind of makes sense when you think about it. In a way, I think, why would you cancel all these options?

48:32 Exactly.

48:34 True and false are never going to be gone, so just forget it. Leak that memory or whatever. Right? Yeah. All right, let's see what else we got to cover here. Maybe the issues in PR backlog.

48:45 Sure.

48:47 Okay. Yeah. This is a pretty interesting aspect because it has to do with the developer and residence in Łukasz Langa and all the improvements that having somebody dedicated to that role has brought. Right.

48:58 There are a lot of open issues and open TRS on this talk is actually kind of taking a step back and looking philosophically about it and saying, well, what is an issue for why there's all these issues? Some of them haven't had activity on them for five years or whatever.

49:17 Why is that issue still open? What is that doing for us? Really?

49:21 Yeah. And also, I guess, really quick shout out. This is from Catrell. Let's talk. So I think it's like two perspectives, right? You see the person who, when they open their phone, at the bottom, it has 26,214 unread messages versus inbox zero.

49:39 It's like, well, if we can't close this issue and we can't deal with it within five years, it's just friction.

49:47 That's one side of the argument, I suspect, is it's friction. The other people are called this is history, historical friction. What do we do about it?

49:53 Sahi Spotaker, one of the most terrific super developers who contributed multiple Python, like I say, you're saying, well, sometimes I do come back to wishes after five years.

50:06 I am planning on working on it, but I'm working on a lot of things. I have hundreds of local branches and I'm working on loads of things at once. And sometimes I forget about something for five years and then come back to it, which is totally fair. It is fair, but I don't think one person isn't going to fix all of those issues when you've got how many is it now?

50:27 Over 6500 open issues on the CPython repo.

50:31 I don't know how I actually fall on this. On one hand, I totally get that you want to keep it around. On the other, if it was something really important, it would probably resurface again anyway, you know what I mean?

50:43 No, I completely get that. I think at the moment, my personal opinions, we do have too many open issues at the moment, and a lot of them just aren't ever going to have either aren't going to get fixed, or like, if they are going to get fixed, it's not because of the issue being open. Like somebody else will just come along.

50:58 And be like, it's on GitHub now. You could apply a tag to it, like close due to old age or something, and just close them. They can be reopened. People could go, Well, I really want to see all the ones that were closed due to old age plus the ones that are open. Just create a search that shows that.

51:15 View Sunday is really bored and I really want to fix Tk entered feature request 20 years ago.

51:28 Yeah, for sure. Okay. It's an interesting conversation and discussion and what to think about, but it's not something that directly affects people. Like, that's the perfect kind of thing that's handled at this meeting. Right? Because it's really about those folks.

51:40 Yeah.

51:41 All right, the final one, the F string Grammar. We got f-strings in Python Three Six, and it's one of the most popular languages added recently. Language features. Everyone loves it. I've heard people upgrading to three six and throwing away old versions just so they can write f-strings, which is great. But it turns out that the actual parser for f-strings is kind of insane. I had no idea what was about that.

52:03 I think it's how many lines of code?

52:06 1400 lines of custom C parser code just for Fstring that's separate from the regular parser.

52:14 This whole file is just manually handwritten C code to pass f-strings. And Pablo bought out this crazy slide on that. Took this talk by Pablo Lunda sargardo. He is a core developer, staying council member, and lease manager for Python 310 and three point eleven. So this is his big project.

52:37 Put up this crazy slide showing the dance that the interpreter has to go through whenever it encounters F string.

52:46 It sounds really tricky to figure out because you've got all the captured variables. You got to figure out how to pass those over. Then it goes to the parser and it's like, oh, jeez. Okay.

52:54 Yeah.

52:55 So what is the idea is to make this part of the regular parser, just move this over to bring it into the parser and all those kinds of things. Okay.

53:03 Yeah. So since Python 3.9, Python has had a generated password, so you just write all the grammar rules down in this file according to a mini language for the grammar. And then the program will generate a very large C file passing Python tools. So it's a much nicer way of doing things. It's much less error prone to generate all the C code instead of writing it all out. So Pablo's big idea is let's just move all this passing into the grammar, do it all at the same time. It's that much cleaner, much to maintain. And it also has some exciting things for users. It will mean that the coded team will be able to do some big work on improving error messages. For example, fair strings. It's probably quite hard to do because if you touch one corner of this file, could have a chain reaction to the rest of it and cost $10. And nobody wants that.

54:05 Yeah, that's great. That's one of the other areas of focus there has been lately on improving error messages. That's good.

54:10 Yes.

54:11 310 had improvements, just in general, for error messages.

54:14 Yeah.

54:14 Maybe that also comes from the Peg Parser. Right? Like, maybe that's related. Like, the Peg Parser already has better error messages, and you can get this into the Peg Parser. It'll just bring along better error messages more easily.

54:24 So the Peg password is smarter than the old password.

54:27 So, like, the old parser couldn't look back when it encountered the Syntax Error, essentially. So if it encountered the Syntax Error, it would just kind of blow up its hands and die on you, whereas the new passer is able to track the Syntax era and then kind of look around context and then give you a better message using that context. That's great.

54:48 Yes, sure. I think that pretty much covers it. Anything else you want to mention to people about the Language Summit? You wrote it up pretty well, I think, but there's something else on there.

54:57 python.blogspot.com. It's the address, if you want to read that.

55:02 Yeah, for sure. I'll put the article in the show notes.

55:04 I think we pretty much covered this thing. We've covered a lot.

55:06 Right on. Yeah, we have covered a lot, Alex. That's great. All right, well, thanks for all of this and all your work on the other things as well. Before you get out of here, let me ask you the final two questions. If you're going to write some Python code, be it 312 or something new, older, what editor are you using?

55:21 Actually using Idle quite a lot these days.

55:24 Right on.

55:24 This PyCharm for a while, I've tried out VS Code several times. I've never really got on with it. I'm not quite sure why. Yeah, I loved all the features by PyCharm Had, but nowadays I'm just enjoying something that just starts out really quickly.

55:36 And it's just really simple and simple. All right, cool. And then notable PyPI package or library to give a shout out to. We kind of do that in a medicine with TypeScript or type shed, rather.

55:48 Yeah, I'm allowed to shout out my own.

55:51 You can shout on everyone you want.

55:53 Absolutely.

55:54 I'll just give another shout out to Specialist, I think. I think that's really cool.

55:59 Yeah, Specialist is neat. I'm glad I learned about that today. That's cool. All right, well done.

56:03 I can see Magnanimous by shouting at somebody else's project.

56:07 There you go. All right, well, thanks for doing the write up. Thanks for taking good notes and sharing it with everyone. Because while it makes total sense that the Language Summit is this closed door story where people can have open conversations and just keep it amongst the core developers, I know everyone in the community really appreciates having a sense of what's coming. Where the focus is, what people are worried about and so on. So thanks for getting that out in the light for us.

56:33 Yeah, no worries. It was fun to do conversation.

56:36 Yeah, you bet. Thanks.

56:37 Awesome. Thanks.

56:38 Bye.

56:39 This has been another episode of Talk Python to me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show.

56:48 If you can browse the web, you can create sophisticated tests with Reflect. Navigate to your site within Reflects simulated browser and perform actions you want to test. Let Reflect handle the painstaking work of test creation and maintenance. Sign up and get a free

57:01 T-Shirt at 'Talkpython.fm' reflect starting a business is hard. Microsoft for Startups Founders Hub provides all founders at any stage with free resources and connections to solve startup challenges. Apply for free today at Talkpython.FM/Foundershub want to 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 in site. Check it out for yourself at training. Talk python.FM. Be sure to subscribe to the show, open your favorite podcast app and search for Python.

57:41 We should be right at the top.

57:42 You can also find the itunes feed at /itunes, the Google Play feed at /Play, and the Direct rss feed at Rss on talkpython.fm

57:52 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 talk python.com 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.

58:30 You.