WEBVTT 00:00:00.040 --> 00:00:04.740 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. 00:00:05.140 --> 00:00:09.760 This is episode 455, recorded October 27th, 2025. 00:00:10.480 --> 00:00:11.380 And I'm Brian Okken. 00:00:11.660 --> 00:00:12.220 I'm Michael Kennedy. 00:00:13.020 --> 00:00:16.680 And this episode is sponsored by the wonderful people at Python Bytes. 00:00:17.240 --> 00:00:19.960 Actually, both and everybody here. 00:00:20.500 --> 00:00:25.840 So please check out the work we do for a little bit of money. 00:00:26.020 --> 00:00:29.320 We've got Talk Python training with tons of wonderful courses. 00:00:29.720 --> 00:00:32.119 And his new book, of course, Michael's new book. 00:00:32.980 --> 00:00:38.080 And then also, if you want to check out pytest, there's the complete pytest course. 00:00:38.240 --> 00:00:41.180 Or you can take the pytest course at Talk Python Training. 00:00:41.860 --> 00:00:44.500 And as always, thank you to our Patreon supporters. 00:00:45.180 --> 00:00:45.820 You guys rock. 00:00:47.140 --> 00:00:50.240 We don't shout you out all the time, but we always appreciate you. 00:00:50.940 --> 00:00:56.720 If you'd like to submit a topic idea or some feedback for us or just say hi, 00:00:57.240 --> 00:01:00.740 Check out the show notes at pythonbytes.fm. 00:01:00.960 --> 00:01:04.019 There's links to our socials. 00:01:04.180 --> 00:01:10.320 We've got the show, and both Michael and I are on Bluesky and Fosstodon, 00:01:10.620 --> 00:01:13.380 but that's really Mastodon, so wherever you're at there. 00:01:14.080 --> 00:01:15.940 If you're listening to this and you're like, 00:01:16.050 --> 00:01:18.480 what, sounds like they're recording live somewhere. 00:01:18.690 --> 00:01:19.340 We can see it. 00:01:19.560 --> 00:01:22.080 Yes, we are recording and streaming, 00:01:22.120 --> 00:01:27.920 but you can watch all the back episodes or participate in the chat if you want to. 00:01:28.280 --> 00:01:34.480 Check out pythonbytes.fm/live with all the details there and a link to when we're going to record next. 00:01:36.960 --> 00:01:39.080 Before we get started, one last thing. 00:01:39.840 --> 00:01:43.980 We do send out a newsletter that's getting better and better as we go along, 00:01:44.320 --> 00:01:47.360 thanks to both Michael and I working on it a little bit. 00:01:47.640 --> 00:01:50.560 So there's a newsletter we send out with all the links. 00:01:51.130 --> 00:01:52.580 So you don't have to take notes. 00:01:53.200 --> 00:01:54.440 We'll send you out an email. 00:01:55.070 --> 00:02:00.480 So sign up for the newsletter and we'll send you those links and extra details too. 00:02:00.760 --> 00:02:01.740 It's a great resource. 00:02:02.670 --> 00:02:04.300 Yeah, I think people really appreciate it, Brian. 00:02:04.640 --> 00:02:09.780 You know, if you look at when you send out the email and then book back in the campaign 00:02:09.979 --> 00:02:13.560 and how many people actually open to the thing that we send out or click on it, 00:02:13.760 --> 00:02:16.180 those are really close to 100%, which is ridiculous. 00:02:16.200 --> 00:02:20.000 So that's a really good sign that other people might also like it. 00:02:20.120 --> 00:02:22.980 Yeah, I think that people are using it in place of taking notes. 00:02:23.240 --> 00:02:26.660 And also, if you're in a car or something, you don't want to try to remember. 00:02:26.860 --> 00:02:27.480 You don't have to. 00:02:27.760 --> 00:02:28.880 So awesome. 00:02:29.480 --> 00:02:32.880 All right, Michael, what do you got for us right away? 00:02:33.220 --> 00:02:35.900 Well, let me see what I can do here. 00:02:37.160 --> 00:02:39.020 Let's see what the Cyclops says. 00:02:39.800 --> 00:02:40.460 A Cyclops. 00:02:40.880 --> 00:02:43.620 It's like a little programming kitty, but it's a Cyclops. 00:02:43.880 --> 00:02:44.160 It's a cute. 00:02:44.260 --> 00:02:45.780 Like Opt, O-P-T. 00:02:46.620 --> 00:02:47.660 operations cycle. 00:02:48.780 --> 00:02:49.620 I get it. 00:02:49.760 --> 00:02:51.200 So we've heard of Click. 00:02:51.820 --> 00:02:53.940 You and I were both just actually singing 00:02:54.030 --> 00:02:55.400 the praises of ArgPars, 00:02:55.980 --> 00:02:57.020 which is pretty interesting. 00:02:57.460 --> 00:02:59.660 I am such a fan of ArgPars these days 00:02:59.980 --> 00:03:01.800 because it's just built in and it's 00:03:02.020 --> 00:03:02.860 simple and it's good enough. 00:03:04.180 --> 00:03:05.680 If you were building 00:03:05.880 --> 00:03:07.680 something where the CLI 00:03:08.340 --> 00:03:09.440 API or interface 00:03:09.820 --> 00:03:11.860 or dev user experience was super 00:03:12.040 --> 00:03:13.560 important, you might choose something 00:03:13.770 --> 00:03:14.700 other than ArgPars. 00:03:15.120 --> 00:03:16.140 So what are your options? 00:03:16.480 --> 00:03:19.300 You could choose Click, you could choose Typer. 00:03:19.720 --> 00:03:23.460 Typer is actually built on Click, so in a sense it's like Starlette and FastAPI. 00:03:23.540 --> 00:03:25.500 You choose one, you get the other in a sense. 00:03:25.920 --> 00:03:27.760 So there's a blend there, and there's others. 00:03:27.960 --> 00:03:31.140 I know there's a bunch of different CLI building options. 00:03:31.660 --> 00:03:36.640 But the Cyclops is one that sort of has the second mover advantage over Typer. 00:03:37.020 --> 00:03:40.660 And their sort of tagline, I don't remember where I saw it, but 00:03:40.860 --> 00:03:43.700 somewhere in here, it's not actually right here on this page. 00:03:44.080 --> 00:03:48.020 but no shade at typer, but it says what you thought typer was going to be. 00:03:48.420 --> 00:03:50.600 And my second boomer advantage is like, all right, 00:03:51.060 --> 00:03:55.160 we've seen different interface things built based around type information. 00:03:55.660 --> 00:03:58.340 And now that we've seen the pluses and the minuses, 00:03:58.340 --> 00:04:02.460 could we do a slightly different version that has more pluses and fewer minuses? 00:04:02.640 --> 00:04:05.340 And so there's a whole page of the typer comparison here. 00:04:05.740 --> 00:04:08.860 And I'm not a super expert on typer. 00:04:09.240 --> 00:04:12.380 My CLI, who is not that great. 00:04:12.900 --> 00:04:19.400 So there's 13 different things, 13 different components or features or aspects of the API 00:04:20.079 --> 00:04:23.320 that they chose to address to say, Typer's great. 00:04:23.560 --> 00:04:25.080 We're basically inspired by Typer. 00:04:25.200 --> 00:04:25.700 That's what we're doing. 00:04:26.220 --> 00:04:30.480 However, there's a couple of these 13 areas I think we should make better, right? 00:04:30.540 --> 00:04:32.760 So you could actually go through and look at all of them. 00:04:33.000 --> 00:04:39.180 Probably the biggest one is that Typer was made with Python 3.7, 3.8, 00:04:39.720 --> 00:04:43.520 where Python's types were at an earlier stage in their life. 00:04:44.380 --> 00:04:48.960 You had to say things like, this is an argument of int, 00:04:49.120 --> 00:04:52.040 or it is an int when it's actually an argument of int or something like that. 00:04:52.360 --> 00:04:57.520 And this Cyclops thing was built once annotated was introduced, 00:04:58.160 --> 00:04:59.960 which allows you to have sort of a dual role. 00:05:00.180 --> 00:05:05.540 Like, it really is one of these, but its type could also be like its native value, right? 00:05:05.880 --> 00:05:08.360 Allowing the removal of proxy defaults. 00:05:08.560 --> 00:05:09.140 Why does that matter? 00:05:09.460 --> 00:05:12.340 Because if you build a CLI with Cyclops, 00:05:13.630 --> 00:05:14.400 and you use types, 00:05:14.610 --> 00:05:16.720 you can still use it as regular functions 00:05:17.200 --> 00:05:18.660 as if they just had an integer 00:05:18.880 --> 00:05:20.340 where it said it took an integer and so on. 00:05:20.660 --> 00:05:21.540 So things like that. 00:05:21.880 --> 00:05:22.640 It's got about, I think, 00:05:22.640 --> 00:05:24.420 a thousand GitHub stars or so. 00:05:24.580 --> 00:05:26.040 It's not crazy, crazy popular. 00:05:26.280 --> 00:05:28.960 But if you're really loving that concept 00:05:29.110 --> 00:05:31.380 of having types for your CLI, 00:05:31.670 --> 00:05:32.180 give this thing a look. 00:05:33.100 --> 00:05:34.500 Yeah, actually, I got a shout out to him 00:05:34.680 --> 00:05:38.919 for doing things like comparing to Typer 00:05:39.120 --> 00:05:43.040 because, like you said, a lot of us, I use Cyper as well. 00:05:43.300 --> 00:05:46.420 And I've used Typer, I've used Click and ArgParse. 00:05:47.800 --> 00:05:52.800 And so you're probably not going to grab too many of the ArgParse people 00:05:53.160 --> 00:05:56.440 because they're just using it because it's built in, maybe. 00:05:57.920 --> 00:05:59.440 You're like the unit test people, Brian. 00:05:59.520 --> 00:06:00.140 What can you do? 00:06:01.180 --> 00:06:02.800 You talk pytest for 10 years. 00:06:02.980 --> 00:06:03.820 I yell louder. 00:06:04.080 --> 00:06:04.600 That's what I do. 00:06:06.600 --> 00:06:16.140 But I think it's a fair thing because I'd be thinking, well, if I'm not going to use ArgParse, I'm probably going to reach for Typer or Click, lately Typer. 00:06:17.479 --> 00:06:26.100 But having this comparison here and then even a migration from Typer, I think that's cool to show that. 00:06:27.539 --> 00:06:31.240 And there's always room for making CLI tools better. 00:06:31.560 --> 00:06:32.500 We love CLI tools. 00:06:32.820 --> 00:06:33.060 Yeah. 00:06:33.780 --> 00:06:34.540 Yeah, there definitely are. 00:06:34.780 --> 00:06:35.560 But yeah, so cool. 00:06:35.700 --> 00:06:39.680 I ran across this and I built something with it recently and it was nice. 00:06:40.620 --> 00:06:41.120 Oh, did you? 00:06:41.160 --> 00:06:41.480 Checking out. 00:06:41.600 --> 00:06:42.000 Yeah. 00:06:42.460 --> 00:06:44.060 A little, you know, I'm starting to add. 00:06:44.460 --> 00:06:50.140 I've been kind of, I've drunk the Kool-Aid now that maybe having an actual CLI, 00:06:50.290 --> 00:06:53.080 even from my own tools, might be a little bit better than just, 00:06:53.420 --> 00:06:56.180 here's a script I run and maybe I'll pass it something 00:06:56.270 --> 00:06:59.180 and just look at sys.argv and see if it's in there. 00:06:59.400 --> 00:07:00.160 Oh, man. 00:07:00.380 --> 00:07:01.520 Let's do a little bit better. 00:07:01.690 --> 00:07:04.020 And now that I've started to do that, I've been playing with these different ones, 00:07:04.160 --> 00:07:08.200 which is, I think, where I kind of got inspired to go down this path and talk about it today. 00:07:08.560 --> 00:07:09.120 Yeah, awesome. 00:07:09.560 --> 00:07:09.640 Cool. 00:07:11.220 --> 00:07:16.260 I want to talk about the present, the future, a little bit of both. 00:07:17.020 --> 00:07:21.840 So there is this interesting article, of course, in Python 3.14. 00:07:22.140 --> 00:07:31.180 Well, we had it in 3.13, is that the GIL was optional with what they call the free threading version, right? 00:07:32.000 --> 00:07:32.900 Free threaded Python. 00:07:33.740 --> 00:07:37.260 Not the gill-less, not the galectomy. 00:07:37.640 --> 00:07:39.920 Free-threaded, I think, is where we landed from the PEP. 00:07:40.580 --> 00:07:42.580 Okay, but is it kind of the same thing? 00:07:42.780 --> 00:07:43.000 Yeah. 00:07:43.320 --> 00:07:43.500 Okay. 00:07:46.600 --> 00:07:46.900 Oh, right. 00:07:47.060 --> 00:07:48.240 The galectomy was a different project. 00:07:48.800 --> 00:07:49.280 Yeah, it was. 00:07:49.940 --> 00:07:50.120 Gosh. 00:07:50.520 --> 00:07:50.820 Anyway. 00:07:51.500 --> 00:07:52.740 Larry Hastings was doing that. 00:07:53.080 --> 00:07:55.240 But I believe, I mean, the free-threaded stuff, 00:07:55.380 --> 00:07:57.160 there's a lot of things that had to happen. 00:07:57.270 --> 00:07:59.840 And actually, my next topic is also on free-threaded Python. 00:08:00.250 --> 00:08:01.740 And it's not just let's take out the gill, 00:08:01.860 --> 00:08:03.460 but they had to rework memory management. 00:08:04.440 --> 00:08:05.700 the structure of object. 00:08:05.920 --> 00:08:07.920 There's like a lot of moving parts 00:08:07.950 --> 00:08:08.880 in order to make this possible. 00:08:09.020 --> 00:08:09.680 Okay, cool. 00:08:11.120 --> 00:08:14.480 Okay, so with the free-threaded Python, 00:08:15.340 --> 00:08:16.700 so now we have in 3.13, 00:08:16.810 --> 00:08:18.580 we had two versions of Python released. 00:08:18.700 --> 00:08:20.000 So if you go to download Python, 00:08:20.250 --> 00:08:20.900 you get a choice. 00:08:21.720 --> 00:08:25.420 And with UV2, you can add a T to it, 3.14 T, 00:08:26.020 --> 00:08:27.500 and you get the free-threaded version. 00:08:29.760 --> 00:08:33.500 But like, and also definitely encourage everybody 00:08:33.500 --> 00:08:36.640 test and publish that you've tested. 00:08:36.680 --> 00:08:41.680 In CI, you go ahead and test it because the CI tools support both. 00:08:42.460 --> 00:08:43.599 Why do we care about this? 00:08:44.140 --> 00:08:49.560 Well, because some people are migrating to it because as with 3.14, 00:08:49.880 --> 00:08:52.040 it's no longer just an experimental thing. 00:08:52.240 --> 00:08:58.020 So here, I'm going to cover an article by Giovanni Barili. 00:08:58.560 --> 00:08:59.560 Sorry, Giovanni. 00:08:59.740 --> 00:09:00.640 I can pronounce that one. 00:09:00.940 --> 00:09:03.540 I'm pretty sure this is the same Giovanni that makes Granian. 00:09:04.020 --> 00:09:05.360 Oh, okay. 00:09:06.540 --> 00:09:07.240 I think so. 00:09:07.460 --> 00:09:10.560 The future of Python web services looks gill-free. 00:09:10.870 --> 00:09:18.800 So it starts out with two major changes when comparing free-threaded variant of 3.14 versus 3.13. 00:09:19.779 --> 00:09:25.480 First, free-threaded support now reaches phase two, meaning it is no longer considered experimental. 00:09:25.940 --> 00:09:30.100 So everybody's on board with this is what we're going to at least try to do for a while. 00:09:30.960 --> 00:09:36.620 not just try to do but we're the python core team is supporting this and we're going to do it 00:09:36.680 --> 00:09:42.340 moving forward what does that mean it means that people can depend on a free threaded version and 00:09:42.400 --> 00:09:49.180 change their code accordingly if necessary which is great especially for a lot of async stuff 00:09:49.840 --> 00:09:56.359 like web services so uh secondly the implementation is now completed meaning that the workarounds 00:09:56.380 --> 00:10:04.760 introduced in 3.13 make code sound without the gil are now gone, and free-threaded implementation 00:10:05.200 --> 00:10:11.600 now uses the adaptive interpreter as the gil-enabled variant. What does that mean? It means that the 00:10:13.360 --> 00:10:19.320 additional optimizations... Oh, okay. Also, those facts plus additional optimizations make the 00:10:19.440 --> 00:10:27.340 performance penalty that we had in 313 way better or way less annoying so in 313 the free thread if 00:10:27.340 --> 00:10:34.740 you're doing non-async code just straight code you had to face a like a 35 time penalty which sucks 00:10:35.340 --> 00:10:40.180 um now it's like a five to ten percent difference and i think it's going to shrink even more 00:10:40.840 --> 00:10:47.899 but um so if you're if you don't need the free threaded don't use it unless or or use it whatever 00:10:47.920 --> 00:10:51.300 But if it's time critical, don't right now. 00:10:51.450 --> 00:10:52.600 But I think it's going to get better. 00:10:54.180 --> 00:10:59.920 And especially if you are using async and stuff, it's way faster to use the free-threaded, of course. 00:11:00.340 --> 00:11:05.880 So this article does a shout-out to Miguel Grimberg's article about performance. 00:11:06.030 --> 00:11:07.640 I think we covered it last week. 00:11:07.640 --> 00:11:08.140 We did. You did. 00:11:09.120 --> 00:11:12.060 No, maybe I did. We did. I can't remember who started it. 00:11:13.700 --> 00:11:16.820 So this article has a whole bunch more benchmarks. 00:11:17.120 --> 00:11:31.120 And I'm not going to walk through all of them, but talks about doing a service with JSON responses and both measuring with WSGI and ASCII implementations. 00:11:31.460 --> 00:11:35.360 And yes, talking about using Gradient. 00:11:35.510 --> 00:11:36.580 So that makes sense. 00:11:37.720 --> 00:11:38.840 So I'm going to jump down. 00:11:38.880 --> 00:11:48.540 So there's a bunch of metrics, but basically the end result is if you're using ASCII or ASGI, the free-threaded one is obviously the way to go. 00:11:49.860 --> 00:11:56.160 And you don't get really much of a hit because of free-threaded implementation at all. 00:11:56.480 --> 00:11:59.500 You get speedups and memory usage is reasonable. 00:12:00.480 --> 00:12:07.260 So what I want people to do, if you're going to check this out, is to jump down to the final thoughts because there's some great stuff here. 00:12:08.380 --> 00:12:11.560 Essentially, so what do I want to pick out? 00:12:13.680 --> 00:12:16.280 On asynchronous protocols like ASGI, 00:12:16.620 --> 00:12:19.640 despite the fact that concurrency model doesn't change that much, 00:12:20.360 --> 00:12:24.800 it's a shift from one event loop per process to one event loop per thread. 00:12:25.360 --> 00:12:26.880 I think that's a big change, actually. 00:12:27.780 --> 00:12:30.620 Just the fact that we no longer need to scale memory allocations 00:12:30.960 --> 00:12:33.260 just to use more CPU is a massive improvement. 00:12:33.660 --> 00:12:34.000 That's cool. 00:12:34.140 --> 00:12:34.720 Didn't know that. 00:12:35.140 --> 00:12:35.520 That's neat. 00:12:36.460 --> 00:12:39.880 For everybody out there coding a web application in Python, 00:12:40.520 --> 00:12:42.280 simplifying the concurrency paradigms 00:12:42.310 --> 00:12:44.520 and the deployment process of such applications 00:12:44.790 --> 00:12:46.280 is a good thing, obviously. 00:12:47.060 --> 00:12:48.160 And the conclusion being, 00:12:50.120 --> 00:12:52.580 for me, the future of Python web services 00:12:52.940 --> 00:12:53.900 looks like the Guilfri. 00:12:54.120 --> 00:12:56.060 So if you're doing web services, 00:12:56.740 --> 00:12:58.220 try out the free-threaded version. 00:12:58.900 --> 00:13:01.000 At least one developer there is completely happy 00:13:01.160 --> 00:13:02.080 with what we have now. 00:13:02.620 --> 00:13:03.580 Yeah, super nice. 00:13:03.880 --> 00:13:05.500 A bit of real-time follow-up. 00:13:05.900 --> 00:13:07.900 Yes, indeed. It is the same Giovanni. 00:13:08.280 --> 00:13:08.740 All right. 00:13:08.860 --> 00:13:09.800 Who creates a granion. 00:13:10.180 --> 00:13:13.800 So with any of these web production app servers 00:13:14.320 --> 00:13:16.280 where you run your Python code when it's running, 00:13:16.660 --> 00:13:17.640 whether it's Django, Flask, whatever, 00:13:17.880 --> 00:13:19.600 there's a process that runs your code. 00:13:19.920 --> 00:13:23.420 Very often, the way that we've got them to work around the gill, 00:13:23.500 --> 00:13:26.260 like in the web, the GIL is a much smaller problem. 00:13:26.740 --> 00:13:28.140 It's still a problem, but it's less. 00:13:28.500 --> 00:13:33.360 Because what we do often is we create a web garden. 00:13:33.880 --> 00:13:35.280 So when you set up gran, you can say, 00:13:35.500 --> 00:13:37.280 and start four copies of yourself. 00:13:37.780 --> 00:13:39.620 So that, yes, they all have the gil, 00:13:40.060 --> 00:13:42.740 but we'll round robin requests between the fours. 00:13:43.080 --> 00:13:45.420 If you've got four cores, four CPUs, 00:13:45.640 --> 00:13:47.300 you basically can say, well, each one of these 00:13:47.340 --> 00:13:50.260 is dedicated to a CPU and it can kind of like match, right? 00:13:51.180 --> 00:13:53.020 Yeah, so we're running on good stuff. 00:13:53.600 --> 00:13:57.000 But the thing is, when you have this free threaded option, 00:13:57.420 --> 00:13:59.960 you can actually have true concurrency in your one worker. 00:14:00.480 --> 00:14:02.480 So instead of scaling out four copies, 00:14:02.680 --> 00:14:04.480 you could have just one and just say, 00:14:04.660 --> 00:14:06.480 let that one take 10 concurrent requests 00:14:06.960 --> 00:14:07.940 or whatever it needs to take. 00:14:08.220 --> 00:14:08.360 - Yeah. 00:14:08.820 --> 00:14:10.540 - Right, so that's how the free thread gets better. 00:14:10.600 --> 00:14:11.680 And like, well, okay, why? 00:14:11.800 --> 00:14:13.940 What's like six, one, half dozen, the other? 00:14:14.220 --> 00:14:16.260 No, the memory becomes a problem 00:14:16.420 --> 00:14:17.580 when you create these little web gardens 00:14:17.920 --> 00:14:21.320 because if normally your server would use half a gig 00:14:21.700 --> 00:14:23.220 and you create four, well now it's two gigs 00:14:23.600 --> 00:14:26.480 and maybe that bumps you up in another tier and so on, right? 00:14:26.820 --> 00:14:30.240 - Yeah, and if you need that memory for data, 00:14:30.640 --> 00:14:31.480 you don't have it, so. 00:14:31.920 --> 00:14:34.620 - Yeah, so I think that's kind of one of the angles 00:14:34.640 --> 00:14:39.180 your writing concurrent code, but the foundations of your code running can do so more efficiently 00:14:39.420 --> 00:14:44.580 because they're no longer needing to work around processes, limitations like, well, we got to 00:14:44.620 --> 00:14:49.360 fan out these processes because of the kill. Okay, back to the regular scheduled programming, 00:14:49.820 --> 00:14:57.600 free threaded Python, let's keep going. So here's an interesting article from a snake wearing a very 00:14:57.820 --> 00:15:04.180 fast, it's a very fast snake with jet engines that is wearing a garbage collector. So what I 00:15:04.060 --> 00:15:09.180 want to talk about is unlocking the performance in Python's free threaded future GC optimization. 00:15:09.650 --> 00:15:15.320 So garbage collection is not something that we frequently talk about a ton in Python. You know, 00:15:15.440 --> 00:15:20.200 it's just, we don't think a lot about GC. We don't think a lot about memory. I don't know why, like, 00:15:20.460 --> 00:15:24.900 as you know, Brian, in C, C++, people are like always about it, right? Like, oh my gosh, 00:15:25.320 --> 00:15:29.140 what size of point and what size of integer are we going to use for this, right? And like, 00:15:29.220 --> 00:15:34.020 it's just way more sort of in the forefront, but it's nice every now and then to peel back the 00:15:34.140 --> 00:15:36.180 and get a look at what's going on here. 00:15:36.470 --> 00:15:41.840 So Neil Schemenauer wrote this article over here from QuantSight. 00:15:42.020 --> 00:15:43.700 They do a bunch of data science primarily. 00:15:44.440 --> 00:15:45.240 But here, check this out. 00:15:45.360 --> 00:15:47.080 This is news to me, actually, 00:15:47.540 --> 00:15:48.940 even though I'm still interested in these things. 00:15:49.160 --> 00:15:50.900 It says, first, the most important thing to know 00:15:50.950 --> 00:15:54.220 is that free-threaded Python uses a different garbage collector 00:15:54.490 --> 00:15:56.900 than the default Python, the gil-enabled. 00:15:57.240 --> 00:15:59.320 The gilded, I still want to call it the gilded Python. 00:15:59.680 --> 00:16:00.600 The gilded Python. 00:16:01.060 --> 00:16:02.220 So we have the default GC, 00:16:02.480 --> 00:16:05.400 which people probably understand pretty well. 00:16:05.710 --> 00:16:08.420 When you create a number, like a thousand, 00:16:08.950 --> 00:16:10.060 when you create a list, 00:16:10.400 --> 00:16:12.440 when you create an object from a class, 00:16:12.860 --> 00:16:16.340 all of those things have a data structure at the top of them 00:16:16.640 --> 00:16:19.400 that allows them to manage and track the memory. 00:16:19.860 --> 00:16:22.280 And people think of the GIL as being a threading thing. 00:16:22.640 --> 00:16:25.140 The GIL is really a protection mechanism 00:16:25.230 --> 00:16:27.140 for memory management in Python, right? 00:16:27.320 --> 00:16:31.040 It's basically protection against a race condition 00:16:31.060 --> 00:16:32.400 in the reference counting. 00:16:32.720 --> 00:16:35.120 So basically interacting with this structure 00:16:35.320 --> 00:16:37.420 that has seven things reference me 00:16:37.680 --> 00:16:39.800 and I reference it, however, you know what I mean? 00:16:39.860 --> 00:16:41.040 Like that sort of deal. 00:16:41.380 --> 00:16:41.540 - Yeah. 00:16:41.700 --> 00:16:43.400 - And when the thing goes out of scope, 00:16:43.520 --> 00:16:45.700 it decrements that and that's where the GIL comes in 00:16:45.720 --> 00:16:47.740 to like make that decrement safe and so on. 00:16:47.940 --> 00:16:49.740 So that's the regular one, 00:16:50.120 --> 00:16:52.140 but we don't even have that structure anymore 00:16:52.860 --> 00:16:54.160 in the free threaded one. 00:16:54.740 --> 00:16:55.540 So what? 00:16:56.379 --> 00:16:58.600 So instead, when you allocate stuff, 00:16:58.760 --> 00:17:03.820 it goes into a special memory managed heap called memalloc, 00:17:04.100 --> 00:17:05.760 or managed by memalloc, right? 00:17:06.199 --> 00:17:09.000 And this allows the GC to loop over all these objects 00:17:09.480 --> 00:17:13.100 and figure out which ones are junk and which ones aren't. 00:17:13.100 --> 00:17:16.699 A little bit like a mark and sweep garbage collector. 00:17:17.240 --> 00:17:18.760 So there's a couple of interesting things. 00:17:20.079 --> 00:17:23.079 One is that most of the mark and sweep garbage collectors 00:17:23.500 --> 00:17:26.540 and that type of thing, they have generations, 00:17:27.060 --> 00:17:28.160 like a generational one. 00:17:28.540 --> 00:17:31.500 So it has Gen 0s where most objects come, 00:17:31.550 --> 00:17:33.620 then it'll check that frequently and so on. 00:17:33.680 --> 00:17:36.200 That's also how the garbage collector that looks for cycles 00:17:36.390 --> 00:17:38.600 in the regular Python goes, right? 00:17:39.040 --> 00:17:43.320 But it doesn't work here because of unmanaged C extensions 00:17:43.940 --> 00:17:45.460 and a bunch of stuff like that. 00:17:45.820 --> 00:17:50.640 So what it does is it can mark all the objects reachable 00:17:50.840 --> 00:17:52.480 from what it calls known roots. 00:17:52.780 --> 00:17:54.600 So instead of trying to scan the entire memory space, 00:17:54.690 --> 00:17:55.700 it says, well, what are globals? 00:17:55.800 --> 00:17:56.180 What are locals? 00:17:56.520 --> 00:18:02.400 what are like a you know it sort of follow those and it marks those as active and that can they can 00:18:02.660 --> 00:18:07.920 automatically be excluded from the search which is kind of like a generational optimization so 00:18:08.310 --> 00:18:12.900 pretty interesting but here's the takeaway we were talking about making things faster by using free 00:18:13.040 --> 00:18:19.720 threaded python with this one it's the free threaded gc collection is between two to 12 times faster 00:18:19.920 --> 00:18:25.220 than the 3.13 version wow that's pretty yeah that's pretty wild right yeah yeah so depending on how 00:18:25.220 --> 00:18:26.080 your algorithms work, 00:18:26.090 --> 00:18:27.160 do you have a super pointer, 00:18:27.440 --> 00:18:27.660 pointer, 00:18:27.970 --> 00:18:28.620 heavy allocation, 00:18:29.000 --> 00:18:30.220 heavy type of algorithm, 00:18:30.440 --> 00:18:30.640 then, 00:18:31.000 --> 00:18:31.160 you know, 00:18:31.250 --> 00:18:32.340 we'll probably see a bigger benefit 00:18:32.540 --> 00:18:33.980 than if you allocate a few things 00:18:34.160 --> 00:18:35.040 and jam on those. 00:18:35.380 --> 00:18:35.720 So anyway, 00:18:35.880 --> 00:18:37.620 if you want to peel back the covers 00:18:37.880 --> 00:18:38.500 and see the GC, 00:18:38.570 --> 00:18:39.600 I didn't even know they were different, 00:18:39.900 --> 00:18:40.760 but apparently they're different. 00:18:41.080 --> 00:18:41.860 And presumably, 00:18:42.060 --> 00:18:43.120 maybe they could even have 00:18:43.300 --> 00:18:45.700 like multi-threaded GC stuff going on. 00:18:46.000 --> 00:18:46.580 That might be cool. 00:18:46.720 --> 00:18:48.040 Or background thread GC. 00:18:48.440 --> 00:18:49.600 I know those are a lot of different things 00:18:49.650 --> 00:18:50.900 that happen in some of these systems. 00:18:51.260 --> 00:18:52.220 These garbage-coach systems. 00:18:52.640 --> 00:18:52.740 Yeah. 00:18:53.300 --> 00:18:53.800 And finally, 00:18:54.100 --> 00:18:58.140 A little bit of real time, not quite real time, but real world follow up, I'll say. 00:18:58.480 --> 00:19:00.960 So for some reason, I can't remember what I was doing. 00:19:01.460 --> 00:19:07.220 Something I had to do, I had to go back, go through all the examples of my async programming course at Talk Python. 00:19:07.640 --> 00:19:13.100 So I went back in there and I said, all right, well, let me just make sure everything's running, update all the dependencies. 00:19:14.200 --> 00:19:15.120 I can't remember what it was. 00:19:15.310 --> 00:19:16.580 But anyway, something had to be updated. 00:19:16.860 --> 00:19:20.020 So I made sure all the dependencies got updated and pinned them to newer ones. 00:19:20.110 --> 00:19:21.980 And I'm like, well, there's a lot of changes here. 00:19:21.980 --> 00:19:22.900 Let me make sure they're all running. 00:19:23.140 --> 00:19:28.060 So go around and I ran every example from the course, probably 25 little apps. 00:19:28.520 --> 00:19:32.380 And many of them are like, well, here's a web app, or here's just a way to do 00:19:33.020 --> 00:19:33.960 multiprocessing, have a look at it. 00:19:33.960 --> 00:19:36.920 But a lot of them were like, let's actually do this with threads. 00:19:37.240 --> 00:19:40.240 And in this example with doing IO, you see it does make a difference. 00:19:40.340 --> 00:19:44.840 In this example doing computational stuff, no difference or slower because there's 00:19:44.920 --> 00:19:47.180 just overhead and it's still running one at a time, right? 00:19:47.500 --> 00:19:56.120 Well, I decided to type uv-python 3.14t run those examples and run them free threaded. 00:19:56.500 --> 00:20:01.580 The ones that used to have no benefit or a net negative are now like seven times faster. 00:20:03.700 --> 00:20:08.400 It would go like synchronous one, 10.2 seconds. 00:20:08.980 --> 00:20:12.800 Async or threaded one rather, 10.25 seconds. 00:20:13.660 --> 00:20:16.560 And now just put the T on the end, three seconds. 00:20:18.140 --> 00:20:25.300 that's pretty cool that is pretty cool man so to me it's really down to what are the framework 00:20:25.650 --> 00:20:30.460 what are the packages and libraries that you're using if it's green across the board for free 00:20:30.560 --> 00:20:37.340 threaded that's pretty interesting it opens up some real possibilities yeah also i i think i'll 00:20:37.340 --> 00:20:41.919 be looking forward to the i know i don't know if we have a deadline or timeline for this but 00:20:41.940 --> 00:20:45.760 when we can go back to having one version of Python 00:20:47.160 --> 00:20:48.680 and it's being the free-threaded one, 00:20:49.420 --> 00:20:53.240 it'll be, you know, maybe we can switch it 00:20:53.360 --> 00:20:55.080 to be the default is the free-threaded one. 00:20:55.180 --> 00:20:57.760 And for a couple of versions, there's the other one also. 00:20:57.900 --> 00:20:59.660 You got to say 3.14G. 00:21:00.260 --> 00:21:01.380 Yeah, or something like that. 00:21:02.720 --> 00:21:04.820 And I think that would be good 00:21:05.140 --> 00:21:08.220 because the default way we think about how to program 00:21:08.360 --> 00:21:10.359