Transcript #316: Python 3.11 is here and it's fast (crossover)

00:00 Hey folks, for our final episode of 2022 here on Python Bytes, we're crossing the streams with my other show, Talk Python to Me. I present to you one of the more important episodes over there for the year, the release of Python 3.11 with its new features and 40% performance improvements.

00:16 Thank you for listening to Python Bytes in 2022. Have a great holiday break, and Brian and I will see you next week. Here's that Python 3.11 episode.

00:29 Python 3.11 is here!

00:31 Keeping with the annual release cycle, the Python Core devs have released the latest version of Python, and this one is a big one.

00:37 It has more friendly error messages and is massively faster than 3.10, being between 10 to 60% faster in general, which is a big deal for a year-over-year release of a 30-year-old platform.

00:50 On this episode, we have Eirik Kutryl, Pablo Galindo-Sogado, Mark Shannon, and Brant Booker, all of whom participated in releasing Python this week.

00:58 They're here on Talk Python to tell us all about that process and some of the highlight features.

01:03 This is Talk Python To Me episode 388 recorded October 28th, 2022.

01:08 Welcome to Talk Python To Me, a weekly podcast on Python. This is your host, Michael Kennedy.

01:26 Follow me on Twitter where I'm @mkennedy and keep up with the show 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. Hi everyone. Welcome to Talk Python to Me. It's great to have you all here. Ivrit, Brant, Pablo and Mark. It's going to be super fun to speak with all of you about Python 3.11.

01:57 You know, before we get into it, I guess just real quickly, I know some of you have been on the show before, but not all of you.

02:03 So let's just do a quick introduction about who you are and how you ended up here on the show.

02:09 Yarit, do you want to start first?

02:10 >> Yeah.

02:11 Hi, I'm Yarit Kacharel.

02:12 I'm a Python Core Dev.

02:13 Earlier in the week, we streamed the release of Python 3.11.

02:17 And on the back of that, Michael just invited us all here for a chat.

02:21 >> Fantastic.

02:22 Yeah.

02:23 and we'll talk about that for sure in a second.

02:25 But, Brant, welcome back.

02:27 - Hello, my name is Brant Bucher.

02:28 I have been a core dev for like two years now, and I work with Mark and Yaret on the Faster CPython team at Microsoft.

02:35 - Right on.

02:36 - And I was on the show like a month ago.

02:37 - Yeah, you were talking about the Faster Python stuff, which we'll touch on again.

02:41 - Hello, I'm Pablo Galindo.

02:43 I'm the infamous release manager.

02:45 I release Python 3.11, and you can redirect all your complaints to my email address.

02:51 No, please don't do that.

02:52 So I'm a CPython core dev. I'm also serving this year and last year on the Python steering council.

02:58 And I also released my AI for Python 3.10 and 3.11, which is now the best version of Python.

03:05 I'll load it today. Apart from that, I do a bunch of parser stuff, but now we are not talking about that.

03:10 Yeah, fantastic. Well, welcome. Mark, welcome back.

03:12 Hi there. I'm Alchan. I'm the tech lead of the Fastest CPython team.

03:16 I work with Eric and Brent. I've been a core dev for some number of years, I don't recall.

03:21 You've been spending a couple of years working on this faster CPython thing, and I'm very excited to see some of the fruits of those labors, you know, starting to show up and get in the hands of everyone with this release.

03:32 Yeah.

03:32 It's good to have the stuff out actually in public and in people's hands.

03:35 It's really rewarding to know that stuff you're working on is actually used and used by a lot of people.

03:40 Yeah, that is totally true.

03:41 It's, it's one thing to build software.

03:43 I mean, just by itself, but it's fun, but all of you are working on code that touches so many people.

03:50 Think about there's layers, right?

03:52 One layer is how many people use Python?

03:54 Many millions, millions.

03:56 Does anyone know a reasonable estimate of this number?

03:58 I think some, I don't remember who came with the number, but I think they were estimating like 6 million Python developers, something like that.

04:06 I mean, probably is between zero and a million.

04:09 Let's say, yeah, that's a massive impact, but, and also maybe nervousness about pushing code out to that group.

04:17 But then, you know, those people will build software for others, right?

04:20 if you're using Instagram or using YouTube or other things, right, it's also having massive knock-on effects there. So thanks for putting all this together. Thanks for improving the tools that we all get to use. So yeah, big news. The big news is that Python 3.11 is out. And as Iritz had said, you all live streamed that release. So here we're all together, we're having an awesome chat about about the features and what people can do to take advantage of it and why they might care about new features and want to learn them.

04:53 But there you did a little bit of that.

04:55 But also Pablo, you actually step by step did the release of CPython, mostly live, right?

05:02 Yeah, I did.

05:03 It was except the boring part.

05:05 This is something that I started last year because apparently I didn't have enough things to worry and I decided to make my life even more difficult.

05:15 I'm an expert on that, quite proficient.

05:17 - I'm also an expert, I'm very bad at doing too many things.

05:21 - You could be a release manager, it's the only requirement.

05:23 (laughing)

05:25 So yeah, the idea is that the kind of releasing Python is a process that is quite complicated, it's also quite boring, so it's not like you need to have a galaxy brain kind of thing to do it, but it's just a lot of steps and it's very easy to do it wrong.

05:39 And it's very unglamorous, so I said, "Oh, wow, I'm sure people really would like to see "a very unglamorous process happen in life." And then I said, "Let's do it." And I asked around and I was surprised about how many people enjoy unglamorous processes.

05:53 And then I did the release of Python 3.10 Beta 1, which turned out to be much funnier than I thought because we just broke GitHub.

06:00 That happened live, yes.

06:02 - Was that when you imported all the issues and did that migration or was that separate?

06:08 - You will think that that is a good candidate, but no, That was not the thing that broke GitHub.

06:12 We renamed master to main on the CPython repo and the whole GitHub platform was down.

06:17 What about that?

06:18 - Wow.

06:19 - Yeah, you can see those Ruby workers really struggling with the renaming, all those forks.

06:25 I think we were the, I don't know, someone at GitHub may confirm this, but I think we were the first big project to do the renaming.

06:32 Something went wrong.

06:33 And it was very funny because I literally said, "How funny will it be if now I get a 500?" There you go, a 500 on the screen.

06:40 - Yeah, yeah, it's recorded.

06:42 Someone actually recorded that clip.

06:44 Yeah, yeah, so I said, "Wow, man, this has been "such an exciting thing that I can break such a big project.

06:48 "Let's do it more." So I decided also to stream the 3.10 release itself.

06:54 And I said, "Well, technically, the final release "is even more boring and longer, "so that is actually probably not going to be "even something that someone wants to see." So I said, "Okay, let's not do it alone." So I invited a bunch of friends and core developers so they can actually talk about the things that they worked on the Python 3.10 release.

07:14 And Brand and I were there, so they can probably tell you how they found out.

07:21 But apparently it was something that a lot of people enjoy, because it's not only an opportunity to see how the sausage is made, because I was just explaining all the commands and all the phases and whatnot.

07:31 But when something became very boring, then Brand and I were there to save the day and explain the cool things they work on.

07:39 So, you know, which is a very good opportunity because, you know, when is the last time you could hear the author of the feature that you love talk about the feature that you love.

07:47 That is fantastic. And it happened.

07:48 Right. And not only did it happen, but as they were explaining the feature that they built, the action of it being delivered to the entire world was like all coming together in a pretty awesome way.

08:01 Exactly. And I could only do, just to be fair also, and you know, create what create is do, I could only do that because the first time I did the live thing, I was also doing all the, you know, pushing all the buttons and at the same time doing all the video stuff with I don't know what is the software to the streamer, like whatever.

08:18 And the second time we used the help of the Python Discord team, which are fantastic and they help us a lot.

08:27 They have this fantastic UI where, you know, all the questions that were asked on the chat are shown on the screen and we couldn't use it.

08:35 You know why?

08:36 Because Facebook, or now Meta, decided to break DNS globally.

08:40 What an incredible feat, just in time.

08:44 I think one--

08:44 - So what I'm learning is if we need some sort of like big cloud global outage, you all just need to live stream--

08:50 - Just call Pablo, yes.

08:52 Just exactly, exactly.

08:53 Just please hire me today.

08:55 So yes, now we're like two big outages on Python release.

09:00 You know, there is only a line that passes through two points but I, you know, it was a good statistic already.

09:08 So we said, what else can we break?

09:12 So there you go.

09:13 We decided to do the 3.11 release again, then Mark was there as well, which increases the probability of things being broken by a lot. (laughs)

09:21 Sorry, Mark, I had to do the joke.

09:23 He also fixes them, so it's fine.

09:25 And nothing broke, so kudos to Mark.

09:28 Everything thanks to that.

09:29 And we did the release, so we did the same thing.

09:32 We explained the whole thing, so people could see from the authors themselves like why all the features are very cool, and I did the non-boring parts of the release.

09:41 And then we have a bit of some dramas in backstage because my JubyKey that I used to sign release broke and I freak out quite a lot, but I thankfully have a backup JubyKey.

09:52 So nobody had, yeah, yeah.

09:54 So crazy, because if I didn't have that, then I will have to stop the whole thing.

09:59 But we didn't have to, it was just backstage.

10:02 So yeah, quite exciting.

10:03 Nothing broke except my JubyKey.

10:05 I suppose that's the third thing that broke.

10:06 It's not a global, you know, software, but I still mourn it is here.

10:10 - Yeah, it served you well, but now it's, it gave its life for Python 3.11.

10:16 - Too much power, like 3.11 was too powerful.

10:18 It just broke.

10:19 (laughing)

10:21 - This is a dangerous job that you got.

10:23 - Yeah, yeah, yeah.

10:24 - But you've handed it off, right?

10:25 This is your last time, last main release.

10:29 - Yeah, yeah, I need to do the security and bug fix releases, but I don't need to do the ones that you need to chase people down and ask for cherry picking.

10:38 There was a bunch of things of the release that were quite boring.

10:40 Like, normally we release the previous version, like before the final version, there is something called the release candidate, which is, you know, like the last version that people need to try out before we do the final release.

10:51 And ideally, that is the last version that we publish.

10:54 Normally, it means that you publish from that commit.

10:57 But this was not the case.

10:59 This is the first release that had 130-something commits on top of that.

11:03 And I had to painstakingly cherry pick, and it was not fun, but I did that before the release.

11:08 like two hours because you need to fix conflicts and things like that. Yeah, very, very boring.

11:13 But yeah, I started the stream with that already launched. So it was fine.

11:17 Yeah, fantastic. Now, before we get into all the features, and I want to maybe just talk a little bit about some of the tools for actually doing the release, and maybe start with you is what does 3.11 mean for you all? Getting this out, what does that mean for the Python community from your perspective?

11:36 Well, 3.11 is a huge release.

11:39 There's a lot packed into it compared to the last few releases.

11:43 There are no features, there's the performance work, it's just massive changes internally.

11:48 It's just a huge release.

11:50 Personally, I've started working on exception groups about two years ago.

11:55 For me, it almost feels like finishing another PhD or something.

11:59 It's a massive effort and here it is, it's done.

12:03 It was a big day Monday.

12:05 I had a bottle of champagne ready for the stream.

12:07 It was a celebration.

12:09 Yeah, it was.

12:09 Brent, how about you?

12:10 I'm really excited about 3.11 because I think there's something for everyone.

12:14 And I think you'd be hard pressed to find someone who doesn't want their code to run faster and who doesn't want better error messages, and then you have all these other improvements on top of that.

12:23 It's really nice to see both these like new features, which are something that we get in most Python releases, but also just the stuff that's there for everyone else who just wants to upgrade Python and just have a better experience all around.

12:35 Yeah.

12:35 I totally agree with that.

12:36 It's cool to see people's responses to that too, because responses have been really, really positive, which is another thing that I liked about the live stream.

12:43 Cause we did, you know, live Q and a and we had the chat and everything going on.

12:47 And when you're starting at the same code base for like a year, you're like, okay, I'm pretty sure that what we've done here is really, really cool.

12:53 But you know, like, is it actually as awesome as I think it is?

12:56 You know, have I just been staring at it for too long and release it to the world and people are even more stoked about it than you are.

13:02 And that's a really good feeling.

13:03 Yeah, it is.

13:04 Awesome.

13:05 Mark?

13:06 Yeah, well, I guess I started on trying to get Python faster 15 years ago, I guess, early PhD time.

13:12 Yeah, with HotPy, right?

13:13 Yeah, yeah.

13:14 So it was a long, long, this has been a long time coming.

13:16 So yeah, it's amazing to have it actually out and starting to see the speed ups.

13:20 And obviously we're keeping working on it.

13:22 So it's pretty good.

13:24 Yeah, fantastic.

13:25 You must be really proud because like you said, you have been proposing this for a really long time.

13:30 You've had a lot of ideas and finally you've got a group of people working on it and you - You're all on the same team with Mark and Guido.

13:37 - Yes.

13:38 - And just making legitimate, serious progress here.

13:42 So you must be really proud to just sort of see this actually go out the door.

13:46 - Yes, definitely.

13:47 - Especially in main, I thought too, it's really nice that we're able to, you know, deliver this for everyone.

13:53 - Yeah.

13:54 For me, I see basically three things, like kind of like you said, Brent, I see that obviously there's these new features like exception groups, which are lovely and make the language better, but it also gets friendlier for, especially for beginners, but for everyone, of course, with the better error messages and better reporting and tracebacks, and it gets faster.

14:13 And so, I mean, and all the axes that seem to matter, it's really fantastic.

14:18 Okay, so let's dive in.

14:20 I just, Pablo, let's go back just a little bit to the release process, 'cause people got to watch you do it, but they didn't actually, you know, see exactly what you're typing on your screen the whole time.

14:31 It was more of about a, like an event of it.

14:32 sometimes your screen was up, sometimes it wasn't.

14:34 But there's an official PEP that talks about, like, here's the recipe for doing this, right?

14:39 - That is correct, it's PEP 101, doing Python releases.

14:43 And that is a curious document, it's a peculiar document, talks about how it's done, but it's like, it's kind of weird.

14:49 So the document is up to date, like you can actually search PEP 101, and it will show you the thing.

14:56 So what is there is the actual process.

14:59 It's just, it also contains these weird sentences, Like if you search for it, there is a bunch of places that says, "Stop, stop, stop, stop, stop." Quite funny.

15:08 And that was, if I recall correctly, Larry Hastings.

15:11 He wrote those things.

15:14 And the idea is that he could search for those places and he knows that at that stage he needs to wait for something to happen or something.

15:21 And we left it there.

15:22 So there's a bunch of like weird artifacts.

15:26 And you know, it's full of bullet points because at some stages you need to do some things and some others and things like that.

15:32 And you know, he says, okay, if you're running a beta release, then you need to do this bunch of things.

15:35 And if you're running an alpha release, you need to do this bunch of things.

15:38 And I have done the--

15:40 I have done a state machine that goes through the whole thing, because, like, if you actually write this down, it's quite--you know, the--

15:47 how is this called?

15:48 The maintainability index of this process is insane.

15:51 It just rejects your thing.

15:53 It just--don't merge it.

15:55 Right, and I said, like, yeah, I'm not doing this reading.

15:58 So one thing I did, which is the thing that I was using at the stream, my first work as a release manager is to say, "I'm not going to do this by hand." And that is the vision.

16:08 And then I did this script that is on github/python/releasetools.

16:13 And it's my attempt at automating this process as much as possible, which unfortunately, you know, it still requires a bunch of manual steps because, like, that's life and things happen.

16:24 But it's quite automatic.

16:26 like at least things that are not like final releases.

16:28 So Alphas and release candidates and now that we are in backfix releases, it mostly runs automatically, except that, you know, in the final release, everything fails because there's the final release for you.

16:40 And then you need to fix things manually.

16:42 So I think you saw me, you know, executing a bunch of those fixes.

16:46 At some point, I added division by zero just to know that something was hit and that was seen on the screen because like, and people were like, division by zero, why do you need that to release Python?

16:56 I don't know.

16:57 That's very complicated.

16:58 I could have asserted false.

17:00 Come on, anything would have worked.

17:01 No, no, we divide by zero.

17:03 I'm a physicist, so that's what I do.

17:04 Okay, okay.

17:05 I'm a computer scientist.

17:06 You studied black holes, right?

17:08 Yeah, yeah.

17:09 You were looking for some sort of like infinite sort of thing there, divide by zero.

17:13 Yeah.

17:13 I'm too tired for today.

17:15 Let's just collapse the universe, divide it by zero.

17:17 But Python was too friendly.

17:19 Instead of collapsing the universe, it sold me an exception.

17:21 You know, quite nice.

17:23 Only in 3.11. No, no, I'm joking.

17:25 Anyway, so yes, yes, you can follow this PEP and, you know, just enjoy the whole process on its glory, or you can see the script.

17:32 But yeah, it's quite verbose.

17:33 You can see that there's lots of places when everything can go wrong and you can panic.

17:38 Now we know one more, finally your JubyKey can break.

17:41 So that's something that can happen as well.

17:43 But like, you know, it's quite annoying.

17:45 And that's the main job of the release manager, go through this annoying process.

17:49 So, yeah.

17:50 - Yeah, I see that there's some parts in here.

17:52 You should have a few more stops.

17:53 I should say, stop, stop, stop.

17:55 Make sure GitHub still works.

17:56 Stop, stop, stop.

17:57 Make sure Azure still works.

17:58 Stop, stop, stop.

17:59 - Yeah, don't cry.

18:00 Don't cry at this stage.

18:01 Everybody's looking at you.

18:03 But yeah, the one thing that is known in this pub is that you also are in charge in theory of this extreme abstract mandate, which is that you are in charge of the stability of the release, whatever that means.

18:15 That translates more in chasing people because they broke things.

18:18 Another unfortunate event that we are trying to also fix a bit for the releases is that most people turn to the release manager to solve problems.

18:27 So they say, hey, this person says that we should do X, while this other person says that we should do Y.

18:33 We need someone to decide.

18:34 Let's reach to the release manager, but the release manager is this guy on the corner.

18:39 Like he doesn't know shit.

18:40 So I like, you know, he's not the best person to fetch it, but everybody was like, what do you think, Pablo?

18:45 So we merged this, and like, I don't know, man, this is some enum things.

18:48 Like, I don't know about this.

18:50 I have no context whatsoever.

18:51 - Your only concern is, will it still build and ship?

18:54 - Exactly, it's like, yeah, what about these 2,000 lines?

18:58 Of course, it's all this tiny bag.

18:59 It's like, well, maybe let's not merge that.

19:01 But yeah, we are trying to also redirect all of this to the steering council, which also, I am in the steering council, so apparently I'm not going to get rid of these questions.

19:10 I'm joking, I enjoy all these questions, but as a release manager, I don't.

19:13 So the key here is that the release managers should not take unilateral decisions on the evolution of these things, because it's just the release manager.

19:19 So the reason the steering council is five people--

19:21 - But you are the one who delivers the code.

19:23 You could kind of, you could sneak a feature in there.

19:26 - No, no, no, I don't decide important things.

19:28 I just execute and chase people and I'm this annoying guy that says, you wrote this, fix it.

19:32 But like then, if there is some important decisions to be taken, you know, that's the steering council job, which is five people, because you know, one person shouldn't decide these things.

19:41 It's like, and this happens, like sometimes I say, hey, there is this PR when people are asking, what should we do?

19:47 And then this is my opinion as the member of the steering council and the other four members maybe they say, well, actually that's not a good opinion.

19:53 So what about this?

19:54 You know, we ended up in a much better place because it was five people, five persons doing a decision instead of one, but yeah.

20:01 - This portion of Talk Python to Me is brought to you by Microsoft for Startups Founders Hub.

20:08 Starting a business is hard.

20:09 By some estimates, over 90% of startups will go out of business in just their first year.

20:15 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.

20:24 Microsoft for Startups Founders Hub was born.

20:26 Founders Hub provides all founders at any stage with free resources to solve their startup challenges.

20:33 The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections, and much more.

20:42 Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor-backed or third-party validated to participate.

20:51 Founders Hub is truly open to all.

20:54 So what do you get if you join them?

20:56 You speed up your development with free access to GitHub and Microsoft Cloud computing resources and the ability to unlock more credits over time.

21:04 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.

21:14 Through Microsoft for Startups Founders Hub, becoming a founder is no longer about who you know.

21:19 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.

21:33 You'll be able to book a one-on-one meeting with the mentors, many of whom are former founders themselves.

21:38 Make your idea a reality today with the critical support you'll get from Founders Hub.

21:43 To join the program, just visit talkpython.fm/foundertub, all one word, the link's in your show notes.

21:49 Thank you to Microsoft for supporting the show.

21:51 Amazing, okay, so if people wanna follow along with the process, they can check out PEP 101.

21:57 Let's keep over here, you also talked about the Python buildbot that people can check out, but I think maybe we wanna jump into our first feature.

22:05 As Erit said, there's a ton of features and things in here, but there's also maybe some top-level ones that'll be really important for a lot of folks, And you really want to tell us about your work.

22:15 You mentioned before the exception groups and exception star.

22:18 This is kind of a major new feature that we added.

22:20 And the idea is that sometimes you'll have a situation where you did several things and maybe more than one of them raised an exception, and now you need to report that there was more than one error in whatever you did and what you did could have been a bunch of asynchronous tasks, which is that that was the use case that motivated this whole thing.

22:40 But there are also situations where you just iterate over a few things and repeat them and accumulate exceptions, and you want to report all of them.

22:50 And the PEP lists a bunch of examples of where this can happen.

22:55 So people, typically what they do is they'll take a list of exceptions, wrap it in another exception, multi-error, some other wrapper, and throw that, and then you have to catch it.

23:06 And then you have to iterate over the list and look at the exceptions, But you don't have a method to handle the exceptions.

23:12 Like you have to try except like catch these, but not catch it.

23:15 Right.

23:16 Right.

23:16 Because then you accept, you might have like, except socket error, or you might have an except like file not found type of thing, but if those both happen, neither of those would run in Python 3.10.

23:28 Right.

23:28 Cause it's some kind of weird wrapper and it's not a socket exception.

23:31 It's not a file exception, but it kind of contains both.

23:34 And so in a sense, both run, I don't know.

23:36 And then if you catch the wrapper, even you do something with some of the exceptions, you better not forget to raise the rest because you're not handling them.

23:43 So, yeah, there are a lot of problems when you try to work around this.

23:47 And like what happened with Trio.

23:49 So Trio had multi-error, would raise this wrapper and it was, it had to do a lot of complicated acrobatics just to have some error handling.

23:58 So the motivation was, yeah, we have task groups in Python 3.11, which are kind of like trio nurseries, kind of a structured collection of asynchronous tasks.

24:09 And task groups were on the cards.

24:12 They started, like Yuri Serebanov, who was kind of maintaining asyncio in the beginning, he wrote a lot of asyncio.

24:18 He wanted to add task groups since 2017, 2018, something like that.

24:23 And what was holding it up was error handling.

24:26 There was no good way to handle errors.

24:29 So now we have Accept*, which is, which generalizes except and works with groups. So you can say except star socket error and then it will just extract all the socket errors from the group and give you those and automatically re-erase everything else. That's basically the idea. This is pretty interesting.

24:46 We have try, do your thing and then except star, you know, one error type, except star, another error type, except star, a set of errors potentially. So what happens if I'm in this situation and say the first error type and maybe something from the third error catch clause is thrown in one of these task groups, exception groups. Each exception in the group will be handled by at most one of the clauses. So the first clause that matches its type will consume it and each clause executes once. So if there are more than one errors of that type, then what gets kind of bound in the except star for error as E, what gets bound to E is a group of for errors.

25:28 So you get all the for errors in a group, execute that clause and then move on to the next clause with whatever is not handled yet. Interesting. So it might run two of the clauses. And whereas in traditional exception handling, it goes from top to bottom and it looks for an inheritance type of match and the first one that matches, that's it. But in this case with the star, You could get multiple ones. I guess the star to me when I look at this, the star is reminiscent of args star where you have unpacking. Yeah, yeah, exactly. It's not exactly unpacking, but it was it was kind of the intention to make it look a bit like unpacking. Nice. Yeah, this looks like a really cool feature. You talked about the task groups and trio and those things. So when I saw this concurrent errors obviously come to mind because if I try to both write something to a a database and call a web service asynchronously and I start both of those and they both crash or you know multiple ones crash, which error do you want? The database error or do you want the API error?

26:26 You probably want to know about both of them, right?

26:28 So that's a real natural reason to bring these together.

26:31 But maybe you'd also list out some of the other reasons that you might run into this.

26:36 Maybe give people some other ideas.

26:37 So the example of in the socket model, we have the create connection function.

26:41 And that function, I was showing it in the stream, it iterates over all the Configurations that you could try to connect with them and depending on what's going on on the other side Hopefully one of the works, but if none of them work You have to report errors and what we do in Python 3.10 is we just raised the last exception So you don't know what happened really you already know right the last attempt failed You don't even know how many attempts were made to connect to how many configurations did we try?

27:08 So that was a long-standing open problem kind of can we do better than just report the last error?

27:14 And then we closed it and we just added it for, to then give me a demo for in a group.

27:18 - Another place that comes to mind is, maybe you all are familiar with some of these retry libraries like retry, but yeah, I think there's others as well, where you put a decorator onto some function, you say, try this multiple times.

27:31 And if it fails, do like some sort of exponential backoff, 'cause maybe the server's overloaded, right?

27:36 Those types of things would be really great.

27:38 Like if it retries all the times it's supposed to, and it fails, it'd be good to get all the errors, just the last one or the first one or whatever it decided it was going to give you.

27:47 Yeah. It's the kind of thing.

27:48 Yeah. Nice. Okay. Well, congratulations on getting that feature out. That's great.

27:53 All right. What do we got next here? I think also related to this, I wanted to talk about this PEP 678.

28:00 That's a very small and simple feature that Zach had for Dodds Road, this pep. He was trying out Exception groups, he was the first user, even before the PR was merged, he was trying it out.

28:13 He was trying to integrate it with the hypothesis library. So there, you write a test, and the library executes it many times with different inputs, and you get failures in some of the inputs, and you want to report all of them. So Zach had an exception group, kind of an exception wrapper, kind of like Trio Multi, or he had his own version that he built in his library and he could associate each exception he attached to it which input generated this error, which is very important, you need to tell people what the input was and what happened with it.

28:45 And he couldn't do that in a convenient way with exception groups.

28:50 So we added this to base exception, this is not a group feature, it's any exception you can add strings.

28:57 You call add note, give it a string, and you can call it as many times as you want and add notes to the exceptions, and they will appear in the default traceback that the interpreter prints.

29:08 So that's all it is, it's a very simple feature, but it was received surprisingly well, people kind of like it, that you can enrich an exception after you catch it.

29:18 So you have the information that, you know, the error message and the type, you decide that when you raise the exception, but then sometimes when you catch it, There's some more information, some context, like what was I trying to do when this error happened?

29:30 Sure. Yeah, because often you'll see, except some type, some exception type, you'll deal with what you can, but you can't really handle it there.

29:37 So you got to raise it again.

29:38 And this is a place to add more information without completely wrapping it, right?

29:43 Right, exactly.

29:44 A lot of people have to chain it, say this raised from that.

29:48 So there will be situations where maybe you won't need to do that.

29:52 Yeah, I'd love to see that go away.

29:53 I sort of template libraries and stuff in the web all the time.

29:57 I see like there's all these different errors and you got to hunt through a bunch of stuff to figure out what happened.

30:02 Yeah, also think about, for instance, like I think this is super useful actually for end users even.

30:07 Like, think about that you're doing some query to the database, right?

30:11 And then, I don't know, it may fail for six million reasons and then you want to add what you're asking for, right?

30:17 So you add your query or your user or whatever because probably the exception that the Postgres thingy that is underneath is not going to contain your actual thing.

30:27 So this actually may save you hours, right?

30:30 Because in many enterprise environments, you don't even have easy access to that, sorry, to prod.

30:36 So you cannot just go there and see what's going on.

30:39 So it would be super cool that you say, "Oh, if something fails, you know, I was trying to do this with this data and like with these things." So like, if it fails now, you can know what's going on and you don't even need to log in, which is, I think it's a quite good thing.

30:52 - Yeah, yeah, it's a great idea.

30:54 Or if you know, look, here's probably why this happened as a library developer, you're like, look, this is the error, but here's a note, this is probably 'cause you didn't initialize the connection before you called this.

31:05 So make sure, you know, like, another area where I see this could be useful is I want to raise, like the example you have in the docs is type error, but it could also, you know, it could be value error or some other built-in low-level type.

31:19 You know, like, really, this is just, I wanna raise that error, But it doesn't have a place for me to put additional information.

31:25 And so I want to kind of enrich that with more.

31:27 And so not just catch, add the data and then raise it again, but actually I want to use a base error type that doesn't let me put more details in it and then just raise that, right.

31:35 That would also work.

31:36 I think so.

31:37 I mean, I think the intention was, there was some discussions about using notes in the interpreter and I pushed back on it because I said, this, this is owned by the application, the interpretation, you know, because people can wipe out the notes, they can change the order, they can do what they want.

31:51 It's, it's, it's the applications, at least the way I see it.

31:54 The cation owns it.

31:55 You put whatever context you want to put.

31:57 Is there only one note when I say add note, does that set the note or can I have a list of notes?

32:03 It's a list of notes.

32:04 Okay.

32:04 Got it.

32:04 Yeah.

32:05 And you can wipe it out if you want.

32:06 You can, it's, it's just a list.

32:08 It's attached to the exception.

32:10 You can do what you want with it.

32:11 Really?

32:11 Yeah.

32:11 Okay.

32:12 Yeah.

32:13 It's a great, it's a really great feature.

32:14 I mean, it's, I'm sure it was way less work than except star, but it's also going to be really valuable.

32:20 I think.

32:20 It's very simple, but it's yeah.

32:22 Yeah.

32:22 Brent or Mark, you guys got any thought about this before we move on to the next?

32:25 I think it's really cool.

32:26 I like it.

32:27 Great work here.

32:28 Indeed.

32:28 I think it is as well.

32:30 Actually, I'm really excited about it.

32:31 I want to talk about, let's, let's talk about faster Python for a little bit.

32:35 So Mark, I had you and Guido on back on, wow.

32:39 Almost to the day a year ago.

32:41 We're off by November 1st, 2021.

32:44 So quite not, not that long ago.

32:48 Let's talk a little bit about the work that you're doing there.

32:50 I guess the headline is that Python 3.11 is 10 to 60, 10 to 50% faster than previous sort of on a reasonable range of applications.

33:01 Is that the story?

33:02 Yeah, somewhere between minus a few percent and plus a hundred, but it varies a huge amount.

33:08 I mean, I mean, if you've got some application that basically spends all its time in NumPy or something like that, you're not really going to speed up at all.

33:16 But if it's pure Python, you'd expect it to be a good 40, 50% faster.

33:21 So, but it depends.

33:22 Right.

33:23 That's a good point because a lot of people do make Python faster by writing C or Rust or other languages.

33:29 And at that point, like it's out of your hands, right?

33:31 Yeah.

33:32 So I mean, we're looking hopefully for 3.12 to start looking at the sort of interface between Python and C code.

33:38 So we should speed up code even though there's quite a lot of C code.

33:41 We won't spend up the time spent in the C code in doing the actual work in the C code, but there's still quite a lot of sort of marshaling of data that happens and hopefully we'll streamline that.

33:50 But it's the existence of C extensions is sort of in some ways limits our opportunity to speed things up, but it's also, you know, why Python is so proper in the first place or one of the main reasons.

34:00 So definitely need to acknowledge it.

34:02 Yeah, absolutely.

34:03 So, Brent, I'll definitely have you talk about the specializing interpreters, but Mark, maybe give us a rundown of some of the things from your plan that made it in here.

34:11 I know some were aimed for 3.10, but they didn't make it until here, right?

34:15 Yeah, so the whole thing, that original plan I put up, that was more of a just to get the discussion going sort of thing.

34:21 And it's basically more or less a year off.

34:24 So if you just shift everything one forward.

34:26 I mean, there was a lot of discussion on speeding up the interpreter in the first iteration, and then looking more to the data structures in the second thing.

34:34 It's much more jumbled than that.

34:35 We're doing sort of a bit of everything.

34:37 So obviously, I was planning on expanding a smaller team.

34:40 So things are being a bit shuffled.

34:42 So yeah, there's this specializing interpreter. Obviously, that's kind of key. There's also quite a lot of stuff we've done with data structures I mean we shrunk the python object. So we've been I mean the python object, you know has been shrinking for years I mean i've got some numbers here So like in 2.7 and 3.2, I like an object with just four attributes would take 352 bytes on a 64-bit machine and for 3.11 we've got it down to 112 and for 3.12 it would be 96.

35:09 Well, before you get too excited, there's only 32 in C++, so you know, we've got a bit of way to go.

35:14 Yeah, but you know, it's going in the right direction for sure.

35:18 And you know, I'm sure some people out there listening just say like, "Okay, well, it's half the size roughly, and it's going to be less than that." So, yay, we can use less memory.

35:26 But maybe you could talk a little bit about how that affects things like L1, L2, L3 cache hits and other sort of, like, it's more important than just, "I need less RAM," right?

35:37 Yes, there's two things that happen. Things are faster because the hardware is just happier.

35:43 If you pack everything together, it's in a high-level cache, so you're not getting these long pauses as you hit main memory. And the other thing is just the data structures, because there's less of them, there's less indirection. So, for example, to load an attribute, we've got it down for basically in older versions of Python, it was effectively five memory reads, and they were dependent memory reads. You have to read one before the next one, and so on. Go to the class, go to the object, find its dictionary, then find the pointer that's in the dictionary and then go to that, right? Yeah, yeah, very much that. And that's down to more or less two now. So, I mean, obviously there's still interpretive overhead on that. So, it's not quite that much faster, but it's getting there. So, yeah, there's a data structure. And then the frames, the Python frames, every time you call a Python function, we used to just allocate a heap object for the frame and all the stuff would go in there.

36:36 And now they're all basically in a big contiguous sort of block of memory.

36:40 So it's just bumping a pointer rather than allocating, which is also faster.

36:44 And frames are just smaller anyway because of the zero cost exceptions, which I think we mentioned on the release thing.

36:52 But yeah, this is...

36:53 Well, let's tell people about zero cost exceptions.

36:55 Okay, well, zero cost...

36:57 You shouldn't have to pay for errors if you're not raising errors, right?

36:59 Yeah, that's the idea. And that's why they're called zero cost.

37:02 But zero cost is in quotes in this, and the reason for that is that's just, that's the name it has got.

37:07 They're definitely not zero cost. The idea is that they're pretty low cost if you don't have an exception, but they tend to be even more expensive if you do get an exception because you have to do more lookup.

37:17 The important thing here is that just there was lots of runtime information we need to maintain, and we don't now. So that again shrinks the frames and just makes calls faster because calls in Python were notoriously slow. So that's one thing we've sped up significantly.

37:31 Yeah. So the idea was in previous releases of Python, if you just enter a try block, even if it was successful, there was a little bit of overhead to set up the mechanisms of potentially handling the errors and the information you needed. Right?

37:44 Yeah. And this wasn't just the overhead.

37:47 You defer more of that, right?

37:48 Yeah, I mean, it's actually not so much that overhead as the just the space you had to put that data in had to be allocated every time you made a call in case there was an exception.

37:58 And then we had to, it was massively over allocated to the amount of space anyone ever needed.

38:02 So just that was the big sort of advantage.

38:04 Nice. Yeah, this is fantastic.

38:06 You don't want to discourage people from putting proper error handling in their code.

38:11 What do you think? I see your name on this feature here in GitHub.

38:16 What are your thoughts on it?

38:17 Yeah, I think it's cool. I mean, I was kind of, you know, it was a nice touch that Mark implemented it between when I wrote the prototype for exception groups and when the PEP was approved.

38:29 So, that kind of went a bit. But it was good. I got intimately acquainted with zero cost exceptions through that exercise.

38:40 Well, it's zero cost for some people.

38:43 Yeah, I tease Mark a lot about that.

38:47 No, I think it's a cool feature and I mean, I followed up on that.

38:51 We now have, after we removed that, we still had a, I was talking about this on Monday, we had a jump over the exception handler and then I told Mark, wait a minute, there's a jump, it's not zero.

39:02 You have to jump over the exception handler if there's no exception.

39:06 So now we have, we did, we identify exception handlers as called blocks And before we lay out the code of the function, we put all the code blocks in the end.

39:15 So now if there's no exception, there isn't even an exception handler to jump over.

39:20 That would be in 3.12.

39:21 So excellent.

39:23 You mean zero cost even faster.

39:25 So now it's smaller.

39:27 Yeah.

39:28 It's asymptotically approaching zero.

39:31 Yeah.

39:31 So, but it's kind of nice that we have this notion of cold blocks and hot blocks and we can maybe do other things with it.

39:38 Kind of nice that all the, all the happy, but the fast code is kind of in the beginning of the functions, bytecode block.

39:46 And, you know, in terms of caches and all that, you don't have to, I think it would, it will bring a few benefits beyond just not having to jump.

39:53 Yeah.

39:53 No, this is excellent.

39:54 it's a really great feature and pretty straightforward.

39:56 All right.

39:57 Brent, tell us about the specializing adaptive interpreter.

40:00 That's a big deal.

40:01 You and I spoke about that about six weeks ago, I think.

40:04 Yeah.

40:04 Yeah.

40:05 Basically the headline is the bytecode changes while it's running to adapt to your code, which is really neat.

40:10 So it's kind of finding places where we can do the same thing, but using less work by like cheating a little bit.

40:17 But cheating in a way that is not visible at all.

40:21 A good example is something like a global load or a load from the builtin.

40:27 So if I'm looking up like the len function, that requires two dictionary lookups.

40:32 Every time I want to look at the land function anywhere, I first need to check the global namespace and that's going to be a failed lookup.

40:37 Then I need to check the built-ins dictionary and that's going to be a successful lookup.

40:40 So every time I want to use land or range or list or any of those built-ins, that's the cost that I have to pay.

40:47 But people don't change the global namespace that often.

40:50 And people change the built-ins namespace even less often, or at least they shouldn't be changing it very often.

40:55 I'm going to make false true and true false.

40:58 So let's see what that does.

41:00 And so you can make these observations where it's like, okay, well, if the set of keys in the global namespace hasn't changed since last time this bytecode instruction ran, then I know that that lookup is going to fail because if it failed last time, and the keys are the same, then it's going to fail this time as well.

41:15 So we can just skip that.

41:16 And same for the built-ins dictionary.

41:19 You know, if we know that the keys in that dictionary haven't changed, that actually means that the internal layout of the dictionary is the same.

41:26 and we don't even need to look up len in the built-ins dictionary.

41:30 We can reach directly to the last location where it was before and give you that instead.

41:35 And so that's cool.

41:36 You'll often see in a lot of code, as like a older code, is a kind of a micro-optimization.

41:41 Whenever someone was using a built-in in like a very hot Python loop, sometimes you'd see them like do this kind of quark trick where they make it a local variable by saying like len equals len or something like that as part of the functions arguments.

41:54 So that you turn it into a fast local load. And what we've essentially done is, you know, made ugly acts like that totally unnecessary.

42:02 Yeah, which is really good.

42:03 You do that behind the scenes transparently. Yeah.

42:05 Exactly. And so that's, that's just, you know, one example, we've done tons of specializations for all sorts of things ranging from calls to attribute lookups, to attribute stores, etc.

42:15 So yeah, it's a, it's a really, really powerful thing.

42:18 What was it? 5, 6, 9?

42:22 Yeah, Mark wrote it.

42:23 It was 6, 5, 9.

42:24 6, 5, 9. Almost there, yeah.

42:26 Yeah, so this interpreter is Mark's baby.

42:29 He could tell you much more about it than I could.

42:30 Yeah, I just want to give you a chance to give a shout out about Specialist.

42:33 Yeah, yeah. So this is why I was on your show a couple weeks ago.

42:36 So looking at bytecode disassemblies is not fun.

42:39 And so one thing that's kind of cool is, you know, if you upgrade to Python 3.11, you run your code, you saw it got, you know, 10, 20, 30% faster.

42:46 you might be wondering like, okay, where did it get faster? Like, what is faster about my code?

42:51 And so specialist is basically a package that I made, it's pip installable, it only works on 3.11.

42:58 And basically, if you run your code using specialist instead of Python, so you just type specialist, my project dot py or whatever, it will open a web browser and show you your code, but color highlighted to show you where the interpreter was able to specialize your code where it wasn't, and that's really neat.

43:16 So you can see like, oh, actually, you know, these are the attribute loads that got faster.

43:19 These are the places where my global loads are being cached, that sort of thing.

43:23 - Yeah, that's awesome.

43:24 Yeah, this is a really cool project.

43:25 And it has some proactive features, not just informational aspects, I think anyway.

43:30 You know, if you run a profiler, it'll show you where your code's spending time, but it doesn't mean you should go change everything to make it faster.

43:38 You should look at like, oh, this loop, or this one function is like the thing that maybe we should think about slightly changing the algorithm or the way we do a loop or something.

43:47 And it's a little bit similar here because the specializing adaptive interpreter only specializes some things, like it doesn't specialize floats interacting with ints or those types of things, or I think division as well.

44:00 And so there's certain ways you might be able to slightly change inside of a really hot loop, you know, make something a float ahead of time if you know it's going to be involved in floating point operations, right?

44:09 Yeah, the idea is that this is show us how we can fix things so that you don't need to mess with your code.

44:16 I see. So this is in the future. Okay. Yeah, awesome.

44:20 I would not necessarily encourage people to start tuning individual bytecode instructions in their code due to our implementation details.

44:27 Otherwise you will end coding in C.

44:29 You mean I need to take all those decimal points back out of my code? No, just kidding.

44:33 Yeah, I want to get every single bytecode instruction green.

44:36 (laughing)

44:36 Some things will never specialize, and that's just an artifact of programs.

44:40 But if we can specialize enough, and we typically do, one line may be 20 bytecode instructions.

44:45 If four of them get specialized successfully and two of them don't, generally that will still be faster.

44:51 - Do you know what you should do for April Fool?

44:54 Like you should do a Python plugin that shows you the percentage of specialized instructions in your code, and people can fix the percentage.

45:02 So they can say, "Fail my test suite if my code is not specialized more than 50%.

45:07 If you despecialize it, it's like a performance regression.

45:11 Drop it.

45:13 Yeah, it's like a coverage thing.

45:15 I was kind of thinking about this, so Paolo can tell you more about this, but his cool new tracebacks, the whole reason Specialists is able to do these cool column level highlighting of your source code is because we do have that fine-grained position information under the hood.

45:30 We kind of just piggybacked on that feature in order to give you that.

45:34 But I was kind of thinking another, another thing, another April Fools project could be, you know, column level coverage information.

45:41 So to get to 100% coverage, you have to cover every single column.

45:44 Exactly.

45:45 Yeah.

45:45 I feel like people might take that too seriously.

45:47 Even the white space, all this white space is not covered.

45:49 Yeah, you think you're intense by having branch coverage turned on just wait till you have column coverage turned on.

45:55 Yeah, you can only cover two white spaces per line.

45:57 So you got to call that a lot.

45:59 All right.

46:00 I think that's a perfect segue over to one of the most tangible contributions from Pablo here.

46:06 Maybe tell us about this new fine-grained error locations and tracebacks.

46:10 This is fantastic.

46:11 This will save people being in debuggers or rewriting their code with tons of print statements to figure out what's going on, I think.

46:17 Yeah, thank you very much.

46:19 We put a lot of effort into this.

46:20 So this is, I don't even remember my PEP.

46:24 So I don't know, it's PEP something something.

46:26 And it has a horrendous name.

46:27 -657 and let's see. -657, thanks.

46:31 That's include fine grained error locations and tracebacks.

46:34 Yeah, the worst name.

46:36 I think I was talking with Mark in the Python Core Developer Spring and he was saying like, what it means like fine grained?

46:42 Like, you know, like is this very fine grained?

46:45 So I think we are renaming the PEP to fancy tracebacks.

46:48 I think that's much better.

46:50 Anyway, so this is a project I worked together with Batuhanta Skya and Omar Askar.

46:55 So kudos to them as well, because they participated equally on this.

46:59 And the idea is that we were like, we started this project to make, you know, to improve the error messages in the interpreter and the general experience, not only for, you know, people, because when people talk about this, they normally refer to people starting to learn Python.

47:14 But like, to be honest, most of these things also affect people that are experts.

47:18 Like, I always say that when I implemented the suggestions, I was the first one benefiting from them, because like, I make a lot of typos.

47:25 and it says, "Oh, you mean this." So the idea that we have is that most of the time, the lack of, you know, the interpreter shows you kind of the position when the error happens, but it's quite limited because most of the time, people tend to have, due to Python flexible syntax, a huge amount of complexity even in a single line.

47:44 In the pub, there is a bunch of examples, like you access a bunch of keys in a dictionary and some of them doesn't work or is not there or is none or something like that.

47:52 And then it fails.

47:54 or sometimes you have like several function calls or several additions, and you know, it's quite difficult.

48:00 And most of the time, fixing these things involve going into a debugger like PDB and then trying to inspect every single object and say, okay, this dictionary doesn't have this key at this level, and like, you know, that sucks.

48:12 It's not, because like, debuggers are cool, but like, it's cool or not to use them, right?

48:18 And you know, we thought, what can we do here?

48:21 And we arrived to this idea, actually, also to mention everyone involved.

48:26 This was originally inspired by some kind of prototype that Carl from the PyPy team made very long ago, when he saw like a kind of minimal version of this.

48:37 And then I said, "Okay, can we do this?" And what we do now is that we propagate, because the parser, our super cool PEC parser, knows position of all the tokens and things like that.

48:48 So we are propagating that information through the interpreter, and we store this information now in code objects.

48:55 So a side effect of this PEP actually is that code objects are slightly bigger, although, you know, because code objects don't tend to be a huge percentage of your application, it doesn't really matter that much.

49:05 Maybe PYC files are a bit bigger, but you know, you have a lot of disk space, I'm sure.

49:10 And the idea is that, you know, we store this information in code objects, so when you raise an exception, we say, "Oh, what is the instruction that is right this exception.

49:19 And then once we know which is the instruction that raised the exception, then we go and say, okay, what is the position information that generated this instruction?

49:27 And because we propagated it, we know.

49:29 And then we can say, okay, here is kind of like the lines, the columns that this instruction spans.

49:35 So that kind of allows us to underline the specific location.

49:39 But we go a bit further.

49:40 I'm sorry, sorry, go ahead, Michael.

49:41 - I was gonna say, this is super valuable.

49:43 The example you have in the PEP is you have a dictionary, you say bracket of key A, and then the thing that comes back is another dictionary. So you say bracket B and then another dictionary, bracket C, and then bracket D. And if you're on 310, the error is just like, if one of those is none, say none type is object, object is not subscriptable, or maybe, you know, does not contain that key or some weird thing like that. But is it A, B, C, or D? You have no idea. You're in a debugger printing them out separately or something, but now it just goes, nope, it's the C one. That's It's the third subscript one.

50:17 And that's just, just jump right to it.

50:19 Oh, okay.

50:19 Yeah. Also this error, non-type is not subscript.

50:22 It's kind of like, thanks for the info.

50:25 Like, it's like, you know, water is wet.

50:27 Okay, thanks.

50:28 It's not super useful.

50:30 Yeah, exactly.

50:31 So tell me when it's going to rain.

50:32 Anyway, we did like the first version of this and then we realized that there was some kind of like, you know, it was cool.

50:39 Like most people really like it, but like, especially for instance, with the example with the dictionary that has many dictionaries inside.

50:46 There was some confusion because, like, you know, it underlines the whole thing.

50:49 And then, you know, the order of operations, and, you know, also with complex mathematical expressions, like, you do A plus B plus C, and the last addition fails, it needs to underline A plus B plus C, because what happened is that it first added A plus B, and that gives you something that then you added to Z.

51:06 And what happened is that the last addition failed, but that includes A plus B, so you need to underline the whole thing.

51:11 If you know the order of operations, and I just underline A plus B plus C, you know that what will fail is the last one, because that's the last one that is executed.

51:20 But it is still confusing because, you know, specifically also with the dictionary, people were saying, "Yeah, okay, but like, "you're underlining three keys here, "which is the one that failed." I mean, you know, you can learn by experience that it's the last one, but it's kind of like, it was not a great experience.

51:33 So we went a step farther.

51:35 So what we do is that once we know the kind of range in the line that shows the problem, we reparse that chunk of expression, and then we know, okay, so we know now that this expression has this AST, and then we analyze the AST, and then we say, okay, is this AST something that we can further improve the error message?

51:54 Like, for instance, is this AST a bunch of key access in a dictionary, or a bunch of attribute access, or a bunch of function calls, or maybe binary operations?

52:03 And if it's the case, then we use a specialized, like, you know, underlying, I don't know, or a tilde, or a squiggle, or whatever it's called.

52:11 And you know, the dictionary ones have this different one that marks which key access it was known, the same thing for binary operations and things like that.

52:19 So we do this extra step at the end that does a bunch of extra work, but it tries to improve even upon the, kind of just underlining the line, just so we can offer even more rich information.

52:31 And I'm quite happy, I'm very pleased about this.

52:34 Sorry, Mark, but I think it's the best feature of 3.11.

52:38 - Yeah, this is probably the second stream when I said this, but it's true, totally true, 100% true.

52:44 So I'm very excited about this.

52:45 I literally use this every day.

52:46 Today I was deploying Python 3.11, well, this week, sorry.

52:50 I was deploying Python 3.11 at Bloomer, and something went wrong, and literally, this thing saved my day.

52:55 This saved me to just log in to some forsaken machine and understanding what's going on.

52:59 What about that?

53:00 So super cool, very happy.

53:01 I hope that everybody that uses this and is happy, reach to us and say, "I am happy." because normally people reach to us when they are not happy.

53:10 And they say, "Mmm, evil core developers, "you break everything." But instead of that, you should reach to us and say, "Nice, I did this cool thing." - You should tweet at Pablo or something, though.

53:20 Don't open issues saying you're happy.

53:22 - Exactly, exactly.

53:23 (laughs)

53:24 - Just, exactly, just tweet a couple tildes, a few carats, and a smiley face at him.

53:28 - Exactly, tweet at happy@python.org, which I will take that, and the email address.

53:33 - Awesome.

53:34 - It is that.

53:34 We improve it a bit further.

53:36 One of the things that happens is that sometimes if the whole line is wrong, because this example you have there, if you...

53:42 - Sorry, for the ones listening... - The one I had before, yeah.

53:44 We have here some... We are seeing some output, but it doesn't matter.

53:47 Don't worry, I will describe it.

53:49 So, for instance, you're calling a function, and that's the whole thing that is in the line.

53:53 We used to underline the whole thing.

53:55 So we'll say, "Okay, even if the whole line is failing," so there's no, like, a part of the line is failing, the whole thing is failing, we used to underline that, and that apparently is still on the pip.

54:05 Maybe I should change that because it's not like that anymore.

54:08 Because someone suggested, I mean, come on, like if the whole line is failing, underline the whole line, it's actually not that useful, and you know, you're spending vertical space, so you need to scroll a lot.

54:19 And at the beginning I say, "Yeah, but it's inconsistent, I don't like it." And I pushed back a bit, but like then, you know, more people say, "Pablo, you're wrong." And then I say, "Okay, okay, I'm wrong." We improve this further, so you say, "But don't take this as advice.

54:34 Don't tell me that I'm wrong collectively, please.

54:37 But right, so now if the whole line is underlined, we don't underline it because it doesn't really add any new information, right?

54:45 So only if a part of the line contains the error and not the whole line.

54:49 So this means that we are not going to consume a lot of vertical space for no reason.

54:54 And the last thing I wanted to say is that, there is some people somewhere in the universe that may care about that extra disk space on their PYC files, or they just really, really hate squiggles.

55:06 I don't know if that is even physically possible, but you know, there are very different and diverse set of people.

55:12 You are one of those.

55:13 There is a collection of different ways you can deactivate this feature.

55:17 There is an environment variable with a super long name, and there is -x option when you launch the interpreter.

55:23 So you can say Python -x something something.

55:26 I don't know how it's called.

55:27 I think it's called null debug ranges.

55:29 What about that? What an incredible naming.

55:32 And then you set null back ranges to one, and it deactivates the feature.

55:36 Incredible. Like magic. It's gone.

55:39 And you can reclaim your PYC files, and you can even generate PYC files without this information if when you're compiling PYC files, you set this evil variant variable.

55:48 But don't do that, listeners.

55:50 Don't do that. It's evil. Don't do that.

55:51 Just use it. It's great.

55:53 Yeah.

55:53 There's another kind of type of errors that I think we're going to get is about edge cases where the compiler doesn't get the line numbers right because all these kind of fine-grained locations, it's all new and we're still ironing out.

56:09 - At a front feature, there is a front feature, I think, that you put a bunch of things with the front feature, it just complains on a random place.

56:15 - Yeah, today I found that one.

56:18 But I've been looking at the compiler and the line number, location information, and it's a bit off here and there.

56:24 And we have received bug reports from other people as well.

56:27 The range here doesn't look right, the range here looks too broad.

56:31 So yeah, we're going to be ironing that out for I guess for 3.12.

56:36 Yeah, it's really nice when people are using betas and release candidates though, because we were able to catch a lot of those before the release.

56:42 Because there were a couple people, I forget exactly the name of the project, but they were working on like a code animation tool where it animates your code while it's running.

56:50 And they were using these new ranges to identify AST nodes and stuff.

56:53 And so they did this thing, I guess, where they like run their tool in the entire standard library, make sure it's correct.

56:59 And so we got a bunch of bug reports that basically say, Oh, you know, this column information is off for this weird multi-line attribute access or something.

57:06 If you recall, I think you fix an error.

57:09 That was super weird, because he was like a method access, like, you know, my instance of food.

57:15 And if the method access has like some like bowel or something like that, it was wrong.

57:20 And if you added some extra letter, it was fine.

57:23 Yeah, it was like if you split your method access across two lines, if you do like x.method or x.method or x.method on three lines or two lines or something, the way we trace those lines, we always trace the method when we're actually loading the method, even if it's on a different line as like where the actual method load started.

57:45 And then we were doing some weird math to like figure out where the dot is. So we would try to put it on the same line as the dot.

57:51 So we would just like subtract one from the length of the name.

57:54 So there was all sorts of crazy stuff.

57:56 - And that came from the grave because we fixed that.

57:58 And then it was wrong again, because we were like miscalculating the name.

58:02 It's just so mad that that is.

58:04 - Oh my goodness.

58:05 - Yeah, so all sorts of fun stuff like that.

58:07 - Yeah, amazing.

58:08 Well, yeah, this is definitely one of the highlight features for sure, and also the performance work that you're all doing.

58:14 All right, we're getting very, very short on time.

58:16 So I think maybe a super, super lightning round here.

58:19 Let me just say we also got TomaLib support built in.

58:22 We've got the async I/O task groups, a la trio nurseries.

58:26 We've got new features for atomic grouping and regular expressions.

58:31 A self type, a lot of type things have been added.

58:34 So we've got the self type, variatric, generics, literal strings, which is very interesting.

58:40 Lukas did a talk about that on the release live stream.

58:43 Stuff for type dict and data class transformations.

58:46 So great stuff.

58:48 Now, let's just really quickly round out, what's the Python 3.11 story for PyScript, Pyodide?

58:55 Is there, do you have anyone out there know?

58:57 - I don't know, I suppose it works.

58:59 - I think WebAssembly is now a tier two or tier three supported platform, right?

59:04 - So he has been making a lot of improvements to the build process, which is not easy.

59:08 So kudos to Christian Himes, if you're listening, you're great.

59:12 I suppose that PyScript can, through Pyodide, Jesus, how many layers is this?

59:18 So, Pylite through this can leverage all these improvements because I don't know how the whole layer tower thing is working, but Pylite has a bunch of patches that you need to modify CPython so it builds nicely on WebAssembly platforms.

59:33 I don't know the details on that.

59:35 I just know that some of them are okay-ish, some of them are not okay and quite difficult to maintain.

59:39 And Christian Hines has been making a lot of great effort to change here and there and put a lot of macros and if-else and things like that.

59:48 So CPython kind of builds easier.

59:51 This probably translates that PyLite, I hope, kind of can consume this build in an easier way with less patches, and I suppose that translates into PyScript, like just using the PyLite thing easier.

01:00:04 But yeah, I don't think that there is a huge amount of improvements more than, you know, we are working towards official support, as Bram was mentioning.

01:00:13 We have this next year system, it's super cool.

01:00:15 - That has like a unrelated fun fact.

01:00:18 Mike Drapu, one of the early developers of it is actually managing our team at Microsoft.

01:00:23 - Oh, it's funny how the circle comes to the background.

01:00:26 Indeed.

01:00:27 - How the darn tables.

01:00:28 - That's right.

01:00:31 All right, we are out of time, but super exciting.

01:00:35 I wish we had some champagne and Pablo, we didn't even bring hats to celebrate Python 3.11, but I know everyone out there is extremely excited.

01:00:42 - People cannot see, but I have a Python 3.11 T-shirt.

01:00:44 - Yes, yeah, it's a great new logo for 3.11 and stuff.

01:00:48 Not for in general, but just for the release, it's awesome.

01:00:50 All right, before we get out of here, let me just ask you one final question and then we'll call it a show.

01:00:55 Notable PyPI package, something you want to give a shout out to.

01:00:58 We'll go top to bottom in the picture here, Pablo.

01:01:00 - Notable PyPI package.

01:01:02 Well, I'm going to say memory, use memory.

01:01:07 The one and only Python memory profiler.

01:01:09 Solve your problems on production today with memory.

01:01:13 - That and the underlying errors, I think it'd be all good.

01:01:15 - Exactly, yeah.

01:01:16 - All right.

01:01:17 - A combination, eh?

01:01:17 (laughing)

01:01:18 - Arit, how are you?

01:01:19 - Well, I've had some interaction with the author of Bytecode recently, 'cause I was looking at things to do in the testing and in the interpreter that are kind of like that.

01:01:28 So this is a library you can kind of, from Python, write Bytecode.

01:01:31 And it's pretty neat. - Oh, wow.

01:01:33 - And it's struggling with zero cost exceptions, but it's what it is.

01:01:38 - It's like inline assembly, but for Python.

01:01:41 - Yeah, it's like from a Python script, you can kind of write bit of byte code and get it to, I don't know, do another interesting stuff.

01:01:49 That's awesome.

01:01:49 Brent, how about you?

01:01:50 Well, I'm partial towards specialists, but if I had to choose something else, I, speaking of speed, I really like the scaling profiler.

01:01:57 I've been using it a lot of my own projects and it's, it's awesome.

01:02:01 I don't know how it's memory profiling compares to memory.

01:02:03 I'm sure memory is better, but scaling is really nice for measuring the performance across both Python and C code, which is cool.

01:02:10 Excellent.

01:02:11 Mark?

01:02:12 It's not actually a pipey eye package.

01:02:13 I was going to say the CIS module, which is like, it was a pretty much the most fundamental module going.

01:02:17 There's all sorts of fun things in there.

01:02:20 You can change the recursion limit and see you can model it.

01:02:23 If you're interested in how Python works, it's actually quite a sort of fun thing to play with.

01:02:27 So.

01:02:27 Thank you all for all the hard work.

01:02:29 And I know there are many people who did a ton of work as well, who are not.

01:02:32 On the show here, but you can represent them as well.

01:02:35 So thanks all for being here.

01:02:37 Final call to action.

01:02:38 People want to get started at three 11.

01:02:39 What do you tell them?

01:02:40 Is it ready for them to get going?

01:02:42 What do you think?

01:02:43 It's awesome.

01:02:44 It's awesome.

01:02:44 And also now 3.11 comes with a bunch of wheels for all your packages because there has been a lot of good work in the people of, you know, third-party libraries.

01:02:54 And now that, you know, people are using CI build wheel, 3.11 was released with wheels for NumPy and Pandas and a bunch of other things that previously was failing massively because nobody could compile them on their crappy laptop.

01:03:06 But now you don't need that.

01:03:07 You can just download them and it works.

01:03:09 So just use 3.11.

01:03:10 And there is no reason.

01:03:11 Yeah.

01:03:11 That's actually just boring.

01:03:12 That would be a reason if you're boring and you don't want to use 3.11, then don't use it.

01:03:16 It didn't break anything.

01:03:17 Not even a package, much less GitHub.

01:03:19 Right.

01:03:20 And we need more benchmarks.

01:03:22 So that's true.

01:03:24 Yeah, absolutely.

01:03:25 That's how people can help us make things faster.

01:03:27 It's more benchmarks.

01:03:28 So, yeah, we have a, there's a sort of standard Python performance suite, but it's kind of a bunch of toy programs and so on.

01:03:34 So if you've got something that might make a nice sort of benchmark, you know, sort of some self-contained, but sort of realistic program, then yeah, that's no.

01:03:42 All right, cool.

01:03:43 Well, thanks again.

01:03:44 Great work on it.

01:03:44 Cam gear lock out in the audience says, yay.

01:03:47 See, I build wheel.

01:03:47 Yeah, absolutely.

01:03:48 Great stuff.

01:03:49 So thanks again, everyone.

01:03:51 I'm super excited to start using three 11 myself.

01:03:54 So thank you, Michael, for inviting us.

01:03:55 Yeah, it's great to have you here.

01:03:56 Thank you.

01:03:57 Thank you.

01:03:57 Bye all.

01:03:58 I hope you enjoyed this crossover talk Python episode.

01:04:02 If you did, please consider subscribing to Talk Python to Me if you don't already do so.

01:04:06 On behalf of myself and Brian Okken, thanks for being part of Python Bytes.

01:04:10 Bye now.