WEBVTT 00:00:00.080 --> 00:00:01.740 Hello and welcome to Python Bytes, 00:00:01.910 --> 00:00:04.620 where we deliver Python news and headlines directly to 00:00:04.800 --> 00:00:05.200 your earbuds. 00:00:05.640 --> 00:00:07.280 This is episode 501, 00:00:07.580 --> 00:00:09.840 recorded October 20th, 2026. 00:00:10.020 --> 00:00:11.220 I'm Calvin Hendryx-Parker. 00:00:11.430 --> 00:00:12.220 And I'm Michael Kennedy. 00:00:12.480 --> 00:00:13.260 Great to have you, Michael. 00:00:13.480 --> 00:00:16.240 This show is sponsored through by us, 00:00:16.350 --> 00:00:18.580 our continual support through our own work. 00:00:18.760 --> 00:00:19.240 Actually, 00:00:19.580 --> 00:00:21.020 check out Michael's great work over 00:00:21.020 --> 00:00:22.420 at the Talk Python community. 00:00:23.180 --> 00:00:25.900 He's got some great new courses up, some really cool stuff. 00:00:26.180 --> 00:00:26.680 Some people 00:00:26.700 --> 00:00:30.940 who've been collaborating on the various courses that are on Talk Python. 00:00:31.350 --> 00:00:31.980 And then if you want to 00:00:32.200 --> 00:00:34.980 support Six Feet Up, so I'm co-founder and Six Feet Up CTO, 00:00:35.500 --> 00:00:38.200 and we do really fun projects with people 00:00:38.300 --> 00:00:41.880 who've got hard problems and need cool things solved. 00:00:42.080 --> 00:00:44.240 So check out sixfeetup.com and then connect 00:00:44.290 --> 00:00:45.680 with us over on the socials. 00:00:45.890 --> 00:00:48.980 You can find Michael and myself over on the various regulars, Mastodon, 00:00:49.340 --> 00:00:50.020 Bluesky X, 00:00:50.280 --> 00:00:50.700 and LinkedIn. 00:00:51.330 --> 00:00:53.860 And then the show itself is on Mastodon Bluesky X. 00:00:54.060 --> 00:00:55.100 And then you can also 00:00:55.120 --> 00:00:58.120 join us for the live stream. So if you're here with us right now, 00:00:58.340 --> 00:00:59.060 you're on the live stream. 00:00:59.440 --> 00:01:01.860 We're at pythonbytes.fm/live. 00:01:02.180 --> 00:01:03.880 And then if you want the handcrafted, 00:01:04.199 --> 00:01:04.839 not handcrafted, 00:01:04.920 --> 00:01:08.440 but the bespoke show notes delivered to your inbox, 00:01:08.720 --> 00:01:11.260 the artisanal show notes delivered to 00:01:11.260 --> 00:01:11.680 your inbox, 00:01:12.080 --> 00:01:17.080 join our friends of the show list and we will never share your email. 00:01:17.540 --> 00:01:17.700 But if we 00:01:17.730 --> 00:01:18.480 wanted to take a pause, 00:01:18.920 --> 00:01:19.100 Michael, 00:01:19.540 --> 00:01:22.060 what would that look like? Maybe a little nod, a little nod, 00:01:22.340 --> 00:01:23.740 A little nod, if you will. 00:01:24.000 --> 00:01:24.080 Oh, 00:01:24.360 --> 00:01:24.520 yeah. 00:01:24.880 --> 00:01:25.420 A little nod. 00:01:25.720 --> 00:01:30.860 So let's talk about notebooks. 00:01:31.439 --> 00:01:31.840 Now, 00:01:32.400 --> 00:01:33.600 I don't know how you work. 00:01:34.420 --> 00:01:35.340 I could take a guess. 00:01:35.780 --> 00:01:38.580 But I don't know how if you've got a problem and you're like debugging it. 00:01:38.580 --> 00:01:38.960 And you're like, oh, 00:01:39.280 --> 00:01:41.340 I'm not really sure what I'm going to do here. 00:01:41.700 --> 00:01:42.400 There's different things. 00:01:42.880 --> 00:01:46.700 There's the time-tested print location 1. 00:01:47.120 --> 00:01:48.880 Now I'm in location 1A. 00:01:49.480 --> 00:01:50.080 Now I'm location, 00:01:50.280 --> 00:01:56.400 you know, the bisection method of like you just start printing out stuff all around the area you're trying to understand. 00:01:56.610 --> 00:01:56.740 And, 00:01:57.020 --> 00:01:58.020 you know, there's a place for that. 00:01:58.380 --> 00:01:59.920 But maybe we got better tools. 00:02:00.250 --> 00:02:00.520 I don't know. 00:02:00.650 --> 00:02:01.180 I would hope so. 00:02:01.540 --> 00:02:04.660 I mean, I remember the day I discovered PDB and the magic. 00:02:05.040 --> 00:02:05.220 Yeah, 00:02:05.390 --> 00:02:05.500 exactly. 00:02:05.900 --> 00:02:06.500 Set a breakpoint. 00:02:06.660 --> 00:02:07.080 Let's go in. 00:02:07.340 --> 00:02:07.540 Yeah. 00:02:07.880 --> 00:02:08.000 Yeah. 00:02:08.369 --> 00:02:08.820 You could use, 00:02:09.000 --> 00:02:09.759 you know, 00:02:10.119 --> 00:02:10.420 VS Code, 00:02:10.640 --> 00:02:11.000 PyCharm, 00:02:11.300 --> 00:02:11.560 one of them, 00:02:11.920 --> 00:02:13.800 and run it in a debugger potentially. 00:02:14.380 --> 00:02:17.940 But there's this project called Nod, Notebooks on Demand. 00:02:17.980 --> 00:02:23.340 So if your style of exploration is notebooks already and you're writing some code and you're like, oh, 00:02:23.720 --> 00:02:24.460 this part is not working. 00:02:24.570 --> 00:02:28.020 I need to kind of debug it. I need to understand it. I need to play with it. 00:02:28.230 --> 00:02:30.600 Then you can use this nod or notebook on demand, 00:02:30.980 --> 00:02:32.940 which is super cool by Eric Rahn. 00:02:33.300 --> 00:02:38.980 And the advantages that I see here are if I'm somehow able to explore my code with a notebook, 00:02:39.640 --> 00:02:43.320 it's not just a debugger will let you sort of see what's there, step forward, 00:02:43.560 --> 00:02:44.000 step backwards. 00:02:44.440 --> 00:02:46.700 but you can actually explore different ideas. 00:02:46.780 --> 00:02:49.080 Like, well, what if I had a function that did this? 00:02:49.120 --> 00:02:51.500 Or what if I actually had a query that ran it differently? 00:02:51.880 --> 00:02:53.280 Let me write that and see what happens. 00:02:53.700 --> 00:02:54.420 So here's how this works. 00:02:54.820 --> 00:02:57.840 What you do is you import nodpy and you get the notebook. 00:02:58.380 --> 00:03:01.560 Then whenever you want to basically set a break point, 00:03:01.660 --> 00:03:02.780 you just say notebook. 00:03:03.780 --> 00:03:04.500 I don't know, break. 00:03:04.620 --> 00:03:08.060 I might do import notebook as notebook break or something. 00:03:08.120 --> 00:03:11.320 But anyway, you just call notebook and that will pause your code 00:03:11.340 --> 00:03:14.780 And it fires up or attaches to a Jupyter notebook. 00:03:14.880 --> 00:03:19.920 So you've got to install a Jupyter extension that basically lets it listen for these incoming events. 00:03:20.280 --> 00:03:24.460 And when they do, it will break into a notebook instead of to a debugger. 00:03:24.880 --> 00:03:27.020 And you're just in your function as a cell. 00:03:27.340 --> 00:03:28.520 You can run your function. 00:03:28.680 --> 00:03:29.440 You can explore it. 00:03:29.640 --> 00:03:32.500 There's the other functions that are nearby that you can play with. 00:03:32.680 --> 00:03:34.120 You can write other pieces, 00:03:34.620 --> 00:03:34.740 right? 00:03:35.000 --> 00:03:35.720 Like a new cell. 00:03:35.740 --> 00:03:37.520 You could write a new cell and then go play with that. 00:03:37.740 --> 00:03:38.120 What do you think? 00:03:38.320 --> 00:03:38.780 I love it. 00:03:38.940 --> 00:03:40.780 I think folks who are used to notebooks 00:03:41.240 --> 00:03:43.480 but are a little intimidated by, say, the debugger, 00:03:43.740 --> 00:03:45.520 this is way more of a natural feel. 00:03:46.780 --> 00:03:49.620 It's weird because notebooks break your mind a little bit 00:03:49.680 --> 00:03:50.980 because you can run the cells out of order. 00:03:51.340 --> 00:03:53.880 You can jump back up and go to a previous thing 00:03:54.280 --> 00:03:56.420 and play there and come back down and play here. 00:03:57.220 --> 00:03:59.380 And so you can kind of lose yourself a little bit. 00:03:59.420 --> 00:04:01.300 But this gives people that capability 00:04:01.620 --> 00:04:04.740 to express that creativity and debugging 00:04:05.420 --> 00:04:07.680 by using various cells to play. 00:04:08.140 --> 00:04:08.800 It's interesting, 00:04:09.050 --> 00:04:13.240 like when you're the most stressed out and things are the most not working, 00:04:13.460 --> 00:04:18.600 being in a comfortable place makes a bigger difference than I think just looking at a calm time from the outside. 00:04:18.920 --> 00:04:19.780 Why is this not working? 00:04:19.900 --> 00:04:19.959 Like, 00:04:20.320 --> 00:04:22.040 oh, OK, but this thing, this thing, I'm really comfortable. 00:04:22.160 --> 00:04:22.360 Let's go. 00:04:22.700 --> 00:04:23.900 And now I understand, right? 00:04:24.100 --> 00:04:28.940 Like a friend of mine had this saying about debugging and code, 00:04:29.200 --> 00:04:31.080 about basically code complexity in general. 00:04:31.760 --> 00:04:34.080 I'll share people like Jason said, 00:04:34.840 --> 00:04:37.940 debugging is always a little bit harder than writing code. 00:04:38.220 --> 00:04:42.860 you know because there's all the complexities of what's going on so if you write code that's at the 00:04:43.100 --> 00:04:49.060 limit of your capability of like understanding complexity or like the situation then you might 00:04:49.060 --> 00:04:53.960 not be able to debug it right it's like yeah you should always leave a little bit of a buffer in 00:04:53.980 --> 00:04:58.320 there of of that and i feel like this takes that down a notch right because it gives you 00:04:58.680 --> 00:05:03.039 a better understanding during that harder debugging time yeah well it was like the difference between 00:05:03.060 --> 00:05:04.620 going from PDB to, 00:05:04.960 --> 00:05:06.540 say, PyCharm for a debugger. 00:05:06.700 --> 00:05:07.620 I remember in PDB, 00:05:08.160 --> 00:05:09.760 traversing up the call stack 00:05:10.080 --> 00:05:14.280 and down into things just required you kind of holding a lot of that in your head. You didn't 00:05:14.280 --> 00:05:15.800 get a good visual model of it, 00:05:16.040 --> 00:05:18.360 where if you use PyCharm, you could just kind of click through the 00:05:18.500 --> 00:05:20.880 stack and you see the rest of the stack still sitting on the screen. There's the call stack right there. 00:05:21.280 --> 00:05:21.400 Exactly. 00:05:21.580 --> 00:05:22.400 You can just see it. 00:05:22.600 --> 00:05:26.040 Yeah. And so this gives you that same comfort level and visual 00:05:27.060 --> 00:05:33.020 anchoring when debugging. So I love the fact that they have built this for the notebook natives 00:05:33.240 --> 00:05:33.680 I agree. 00:05:34.040 --> 00:05:36.020 And I believe there's a couple other out there. 00:05:36.280 --> 00:05:38.020 But one of the things that's interesting 00:05:38.220 --> 00:05:41.600 about this one is the markdown cells become comments, 00:05:42.240 --> 00:05:43.560 cells become new lines, and the 00:05:43.680 --> 00:05:48.820 notebooks you can just throw away because they get saved into the source file if you want. 00:05:49.120 --> 00:05:50.040 So if you run it again, 00:05:50.250 --> 00:05:53.380 it kind of recreates the exploration that you set up. 00:05:53.580 --> 00:05:54.300 Oh, that's really nice. 00:05:54.600 --> 00:05:57.300 It can persist from run to run. 00:05:57.640 --> 00:05:57.820 Yeah. 00:05:58.030 --> 00:05:59.160 So it's a pretty new project. 00:05:59.660 --> 00:06:01.260 Don't expect it to be super polished. 00:06:01.720 --> 00:06:02.280 But people 00:06:02.300 --> 00:06:02.720 well, check it out. 00:06:02.780 --> 00:06:04.480 I think it's certainly worth a try. 00:06:04.820 --> 00:06:05.360 Yeah, it looks really cool. 00:06:05.660 --> 00:06:06.800 We should definitely check that out. 00:06:07.520 --> 00:06:07.700 Definitely. 00:06:08.060 --> 00:06:08.440 Over to you. 00:06:08.840 --> 00:06:09.120 All right. 00:06:09.380 --> 00:06:09.480 Well, 00:06:09.680 --> 00:06:11.960 are you ready for the new thing, 00:06:12.120 --> 00:06:14.220 the hot new release of Polars? 00:06:14.400 --> 00:06:15.700 Polars 2.0 has shipped. 00:06:16.520 --> 00:06:18.820 And streaming engine is on by default. 00:06:19.920 --> 00:06:20.820 There's a lot of new features. 00:06:21.100 --> 00:06:23.460 That was the reason for the major bump in version 00:06:23.920 --> 00:06:25.780 is because there's going to be some changes 00:06:26.020 --> 00:06:28.360 and some things you're going to need to do 00:06:28.520 --> 00:06:31.240 as you upgrade to your new version of Polars. 00:06:31.420 --> 00:06:33.320 But one other thing to mention here 00:06:33.330 --> 00:06:35.560 is really, really important is the performance. 00:06:36.030 --> 00:06:37.900 I know we've mentioned in previous episodes, 00:06:38.160 --> 00:06:39.500 we've talked about Polars performance 00:06:39.770 --> 00:06:41.040 versus things like DuckDB. 00:06:41.540 --> 00:06:43.980 And in the blog post of the release here by Richie, 00:06:44.140 --> 00:06:47.240 they've got some performance numbers here 00:06:47.400 --> 00:06:50.220 because SQL is a first class citizen now 00:06:50.320 --> 00:06:51.160 in the Polars environment. 00:06:51.440 --> 00:06:53.120 So if you are doing things like you would have done 00:06:53.260 --> 00:06:53.660 in DuckDB, 00:06:53.910 --> 00:06:54.340 for example, 00:06:54.540 --> 00:06:55.660 maybe you're more comfortable there 00:06:55.860 --> 00:06:57.600 because of the SQL environment, 00:06:58.060 --> 00:06:59.240 and you love the speed of DuckDB, 00:06:59.480 --> 00:07:00.260 look at these numbers. 00:07:01.120 --> 00:07:04.980 This is on some AWS instances here on a C7 4X large, 00:07:05.440 --> 00:07:07.080 16 vCPUs and 32 giga RAM. 00:07:07.360 --> 00:07:08.000 That is a large. 00:07:08.420 --> 00:07:09.020 That is a very large. 00:07:09.180 --> 00:07:10.900 They're running two different benchmarks here, 00:07:11.100 --> 00:07:15.240 the TPCH SF10 and the SF100. 00:07:15.640 --> 00:07:16.300 And you can see here, 00:07:16.640 --> 00:07:19.380 Polars completes it in 3.2 seconds 00:07:19.860 --> 00:07:20.960 compared to DuckDBDB, 00:07:21.180 --> 00:07:21.620 which is fast. 00:07:21.720 --> 00:07:23.640 I mean, we all know compared to what we read 00:07:23.640 --> 00:07:24.020 in our, 00:07:24.500 --> 00:07:25.460 went over in the last episode, 00:07:25.920 --> 00:07:29.760 DuckDB is at 4.44 seconds on that same benchmark. 00:07:30.120 --> 00:07:34.740 And then they basically did the DS version of that benchmark as well and saw that we've got 00:07:34.880 --> 00:07:39.940 Polars at 12.59 seconds where the current release of DuckDB is at 15.92. 00:07:40.140 --> 00:07:41.680 The alpha of DuckDB 2.0 00:07:41.890 --> 00:07:44.040 still slower at 14.3. 00:07:44.420 --> 00:07:47.740 That's not saying don't use DuckDB but I'm just saying Polars is making a 00:07:47.740 --> 00:07:50.600 real run for performance here with some of the new enhancements. 00:07:50.890 --> 00:07:53.219 That streaming capability really 00:07:53.240 --> 00:07:54.740 minimizes memory usage. 00:07:55.230 --> 00:07:59.380 And when you do use heavy memory on these various pullers examples, 00:07:59.790 --> 00:08:00.660 you'll get the new, 00:08:00.850 --> 00:08:01.020 well, 00:08:01.350 --> 00:08:01.480 new, 00:08:01.660 --> 00:08:05.020 basically the out of core or spill to disk is on by default. 00:08:05.410 --> 00:08:06.580 So if you start hitting, 00:08:06.790 --> 00:08:07.220 for example, 00:08:08.080 --> 00:08:08.420 by default, 00:08:08.620 --> 00:08:10.280 it's set to 80% of your RAM usage, 00:08:10.710 --> 00:08:14.840 it will spill out to disk for these larger operations. 00:08:15.330 --> 00:08:17.600 And it supports joins and group 00:08:17.720 --> 00:08:21.780 buys are not supported yet. They're planned but not shipped, 00:08:22.010 --> 00:08:23.200 but it does support 00:08:23.220 --> 00:08:25.320 sort window functions and many expressions. 00:08:26.060 --> 00:08:28.100 So those things will actually continue running 00:08:28.410 --> 00:08:29.840 even if you would have gotten an out of memory 00:08:30.120 --> 00:08:32.260 or maybe the Ohm killer would have come 00:08:32.360 --> 00:08:33.200 and killed your process. 00:08:33.719 --> 00:08:36.740 You can actually make these bigger datasets work 00:08:37.020 --> 00:08:40.500 by leveraging that spill to disk feature of it. 00:08:40.820 --> 00:08:44.000 What a neat idea because the examples you got on the screen 00:08:44.050 --> 00:08:44.820 do have a lot of memory, 00:08:45.100 --> 00:08:46.140 but at the same time, 00:08:46.300 --> 00:08:47.400 memory is expensive 00:08:47.880 --> 00:08:49.560 even before all this crazy stuff, right? 00:08:49.940 --> 00:08:51.500 Relative to how much you can have. 00:08:51.720 --> 00:08:59.540 Like memory on a server is more expensive than an NVMe disk that is not as fast, but still really fast. 00:08:59.700 --> 00:09:00.420 But still pretty darn fast. 00:09:00.680 --> 00:09:00.980 I mean, 00:09:01.380 --> 00:09:07.180 you're basically kind of going back a couple of years in memory technology, but you're gaining the ability to finish the work. 00:09:07.580 --> 00:09:09.620 So I think that may be more important. 00:09:10.140 --> 00:09:10.240 Yeah, 00:09:10.400 --> 00:09:10.500 exactly. 00:09:10.800 --> 00:09:11.860 A little detail. 00:09:12.440 --> 00:09:16.200 Oh, all of a sudden I went from 16 gigs of RAM to 500 and I don't know, 00:09:16.360 --> 00:09:16.800 30 or whatever, 00:09:16.960 --> 00:09:17.040 right? 00:09:17.320 --> 00:09:17.440 Yep. 00:09:17.660 --> 00:09:20.800 Yeah, so one of the things here, again, I mentioned the streaming engine is on by default, 00:09:21.120 --> 00:09:22.240 but that has a side effect. 00:09:22.420 --> 00:09:24.260 So one of the things you need to consider 00:09:24.300 --> 00:09:25.960 when you're upgrading your code from 1.0 00:09:25.960 --> 00:09:27.400 or the one version to the two version 00:09:27.840 --> 00:09:29.520 is that order of operations 00:09:30.080 --> 00:09:31.860 or order of the data is not guaranteed 00:09:32.080 --> 00:09:32.840 in the streaming version 00:09:33.140 --> 00:09:35.440 unless you set maintaining order to true. 00:09:35.800 --> 00:09:37.660 So there's certain row level 00:09:38.180 --> 00:09:39.720 or row order default operations 00:09:39.820 --> 00:09:40.640 that might want that. 00:09:40.780 --> 00:09:42.900 Be sure you check out the upgrading guide 00:09:43.460 --> 00:09:45.380 before you switch up to 2.0. 00:09:45.640 --> 00:09:47.640 And then there's also the new map data type 00:09:47.840 --> 00:09:48.420 called map type. 00:09:48.820 --> 00:09:51.080 So it's now the arrow map type 00:09:51.100 --> 00:09:56.160 supported in the Polars map data type. So if you're in the arrows game, 00:09:56.540 --> 00:09:57.260 which is actually kind 00:09:57.260 --> 00:10:03.540 of cool because arrow gives you that in-memory transportable data type that you can move between 00:10:04.060 --> 00:10:04.660 various processes, 00:10:04.960 --> 00:10:08.440 Polars now supports the map type there, which is basically like a dictionary 00:10:09.000 --> 00:10:11.600 that's super powered in the Polars world. 00:10:12.440 --> 00:10:14.080 That's kind of the big, big news here. 00:10:15.360 --> 00:10:21.060 There's last words, I don't know, coming out in months, but I think the benchmarks are the thing 00:10:21.080 --> 00:10:22.860 speaks for itself on this release. 00:10:23.220 --> 00:10:25.400 It is incredibly fast performance. 00:10:26.880 --> 00:10:28.340 This is another thing I just I 00:10:28.460 --> 00:10:33.100 love about the Python community is people may claim Python slow and maybe should be using 00:10:33.640 --> 00:10:38.660 Go or Rust. I don't know. I think you can there's lots of great work going on to make sure that 00:10:38.820 --> 00:10:43.640 Python is still a first class citizen and maintains that performance that is needed to do great 00:10:43.900 --> 00:10:44.780 production work with these tools. 00:10:45.060 --> 00:10:45.240 Yeah. 00:10:45.520 --> 00:10:49.560 If you've got a large scale application so frequently it's 00:10:49.760 --> 00:10:55.260 There's a little part of it that is performance critical and 90% of it that's not as well. 00:10:55.640 --> 00:10:58.780 And you can bring different tools to bear on that 10%. 00:10:58.780 --> 00:10:58.900 Yep. 00:10:59.240 --> 00:10:59.340 Yep. 00:10:59.700 --> 00:11:00.480 There's an upgrade guide. 00:11:00.580 --> 00:11:04.960 So if you go to the Polars documentation under the releases upgrade slash two. 00:11:05.380 --> 00:11:10.740 So make sure you check that out before performing any kind of an update or point your LLM agent 00:11:10.900 --> 00:11:12.420 at that upgrade guide and say, make it happen. 00:11:12.700 --> 00:11:14.500 You probably get better results by doing that. 00:11:14.820 --> 00:11:15.020 Yes. 00:11:15.120 --> 00:11:15.960 A hundred percent you will. 00:11:16.320 --> 00:11:16.440 Yeah. 00:11:16.780 --> 00:11:16.940 Yeah. 00:11:17.140 --> 00:11:17.720 I'm sure you will. 00:11:17.780 --> 00:11:26.320 So to your performance comment, I don't think that this had anything to do with free threaded Python or any concurrency on the consumer side. 00:11:26.320 --> 00:11:27.000 No, I don't think so. 00:11:27.300 --> 00:11:27.360 Nope, 00:11:27.600 --> 00:11:27.820 not yet. 00:11:28.180 --> 00:11:33.740 But it certainly looks like Holders itself internally is using multiple threads. 00:11:34.280 --> 00:11:37.840 Otherwise, why would you get a much better result on the much larger server, 00:11:38.040 --> 00:11:38.140 right? 00:11:38.410 --> 00:11:39.180 Unless it's just pure memory. 00:11:39.400 --> 00:11:41.340 So you're still in a sense, this is like... 00:11:41.400 --> 00:11:43.740 Yeah, number cores wouldn't matter unless you're using that. 00:11:43.740 --> 00:11:43.820 Yeah, exactly. 00:11:44.160 --> 00:11:44.480 Exactly. 00:11:44.660 --> 00:11:45.340 So it's like, 00:11:45.580 --> 00:11:45.660 hey, 00:11:46.100 --> 00:11:47.780 we don't have this great threading story, or do we? 00:11:48.500 --> 00:11:50.020 We don't have this great threading story on Python, 00:11:50.380 --> 00:11:53.120 but still, here's the part where you actually care. 00:11:53.500 --> 00:11:53.600 Yep. 00:11:53.780 --> 00:11:54.860 You know, jamming on it anyway. 00:11:55.160 --> 00:11:55.340 All right. 00:11:55.480 --> 00:11:56.740 So pick the right libraries. 00:11:57.120 --> 00:11:57.700 And that'd be good. 00:11:57.880 --> 00:11:58.800 Speaking of performance, 00:11:59.120 --> 00:12:01.080 Michael, what have we cached more? 00:12:01.520 --> 00:12:03.380 Would you say if you could cache a lot? 00:12:03.680 --> 00:12:04.980 I love that name of this project. 00:12:06.740 --> 00:12:07.660 Django cache a lot. 00:12:08.140 --> 00:12:08.240 Yeah. 00:12:09.080 --> 00:12:10.340 A little bit of CERM makes a lot. 00:12:11.020 --> 00:12:11.600 A real throwback, 00:12:11.760 --> 00:12:11.820 right? 00:12:12.180 --> 00:12:13.380 I'm here for it all day long. 00:12:13.420 --> 00:12:13.800 I am. 00:12:13.960 --> 00:12:14.420 So am I. 00:12:14.560 --> 00:12:15.040 Oh my gosh, 00:12:15.400 --> 00:12:18.180 what a music genre that was back in the day. 00:12:18.190 --> 00:12:18.620 That was fun. 00:12:19.740 --> 00:12:21.040 So this project, 00:12:21.280 --> 00:12:23.840 1.4 thousand stars, 00:12:24.000 --> 00:12:25.920 called Django Cash-A-Lot. 00:12:26.090 --> 00:12:28.700 I think we've got to just throw it out there, the requisite joke. 00:12:28.980 --> 00:12:29.720 Three things, two, 00:12:29.900 --> 00:12:30.760 I already broke it. 00:12:31.040 --> 00:12:32.780 There's two things that are hard in computer science. 00:12:33.320 --> 00:12:33.640 Right. 00:12:34.060 --> 00:12:34.700 Naming things, 00:12:34.960 --> 00:12:36.880 cache and validation and off by one errors, 00:12:37.040 --> 00:12:37.120 right? 00:12:37.270 --> 00:12:37.360 Yeah. 00:12:37.490 --> 00:12:42.860 But the fact that cache and validation is like one of the first two before the joke even goes off the rails, 00:12:43.260 --> 00:12:47.180 is it's interesting because it absolutely is not easy. 00:12:47.760 --> 00:12:50.820 So there's different types of caching that you might want to do. 00:12:51.200 --> 00:12:55.940 One way to cache is just I'm going to put some kind of front end 00:12:55.950 --> 00:12:58.460 or pre-compute or something in front of a page. 00:12:58.840 --> 00:13:00.120 So like on this page, 00:13:00.540 --> 00:13:02.120 it's got the issues, 00:13:02.460 --> 00:13:02.860 counts, 00:13:03.040 --> 00:13:04.140 it's got the number of watchers, 00:13:04.380 --> 00:13:05.840 the forks, all that kind of stuff. 00:13:06.060 --> 00:13:09.640 GitHub could just say, well, we're just going to pre-render all of that stuff. 00:13:09.890 --> 00:13:12.260 And when you ask, here are your bytes back, right? 00:13:12.540 --> 00:13:15.240 That's probably the most effective, but it also has a lot of challenges. 00:13:15.500 --> 00:13:15.940 For example, 00:13:16.160 --> 00:13:19.020 what if a new issue comes up while I'm sitting on this page? 00:13:19.360 --> 00:13:20.200 Should that refresh? 00:13:20.420 --> 00:13:20.540 Maybe. 00:13:20.980 --> 00:13:22.260 What about my little picture up here? 00:13:22.780 --> 00:13:24.760 If you just straight up cache the whole thing, 00:13:25.420 --> 00:13:26.220 Calvin logs in. 00:13:26.330 --> 00:13:29.100 He doesn't want to see me, and I certainly don't want him accessing my stuff. 00:13:29.300 --> 00:13:29.640 You know what I mean? 00:13:30.000 --> 00:13:33.500 So there's just a lot of issues with caching that much. 00:13:33.530 --> 00:13:35.820 So one way you can cache that's really interesting is just say, 00:13:36.260 --> 00:13:39.540 well, what if everything I asked for the database was already, 00:13:40.000 --> 00:13:42.800 the queries were ran, the results were given back, 00:13:43.110 --> 00:13:46.280 they were parsed, and they were turned into ORM objects, 00:13:46.600 --> 00:13:48.360 and then those things were held on to, right? 00:13:48.600 --> 00:13:51.980 That could be a much better option where you say, 00:13:52.350 --> 00:13:54.760 give me the details of this page, that part is cached, 00:13:54.960 --> 00:13:57.760 give me the details of the user, that part is not cached, 00:13:57.790 --> 00:13:58.520 and then render it, 00:13:58.800 --> 00:13:58.880 right? 00:13:59.100 --> 00:14:01.460 So that's kind of where this thing lives. 00:14:01.820 --> 00:14:04.020 It basically caches your ORM queries, 00:14:04.490 --> 00:14:05.660 and then here's the joke part. 00:14:05.960 --> 00:14:07.260 Hopefully this part is not the joke, 00:14:07.620 --> 00:14:09.400 but there's a part that is challenging, 00:14:09.740 --> 00:14:12.580 the invalidation. So this automatically invalidates them, 00:14:13.040 --> 00:14:14.540 which I think is pretty interesting. 00:14:15.000 --> 00:14:17.560 Notices when your tables change or something like that. 00:14:17.840 --> 00:14:18.220 And hey, 00:14:18.700 --> 00:14:19.680 this cache is now invalid. 00:14:19.980 --> 00:14:21.440 That's really, really nice. 00:14:21.620 --> 00:14:21.880 Yeah. 00:14:22.300 --> 00:14:24.000 Because otherwise you're spending all the time and 00:14:24.140 --> 00:14:25.200 mechanics to figure that out. 00:14:25.480 --> 00:14:29.360 Yeah. You know, sometimes you've got to subscribe to changes 00:14:29.800 --> 00:14:32.660 if your database server gives you those kinds of things. 00:14:32.880 --> 00:14:33.240 I don't know. 00:14:33.560 --> 00:14:34.980 It's pretty tricky. 00:14:39.260 --> 00:14:39.700 So 00:14:39.720 --> 00:14:44.840 the edge cases are here though there's probably still some not funness i believe it plugs into 00:14:44.860 --> 00:14:51.460 the django um just caching built-in caching yeah stuff right for the orm because it points out hey 00:14:51.600 --> 00:14:57.320 if you have multiple servers doing the caching i know multiple web servers and i bet servers also 00:14:57.440 --> 00:15:02.460 would just mean web workers as in web garden anyway with a common cache server uh server 00:15:02.640 --> 00:15:07.300 make sure they have their clock synchronized because they're gonna have to use uh each other's 00:15:07.320 --> 00:15:08.180 numbers and so on. 00:15:08.560 --> 00:15:10.120 But that seems like a solved problem these days. 00:15:10.400 --> 00:15:11.380 If you don't have clock 00:15:11.660 --> 00:15:13.600 synchronization, you've got lots of other problems happening too. 00:15:14.680 --> 00:15:15.080 Exactly. 00:15:15.460 --> 00:15:15.580 Exactly. 00:15:16.220 --> 00:15:17.380 SSL or TLS won't 00:15:17.480 --> 00:15:17.660 work. 00:15:17.860 --> 00:15:18.160 Details. 00:15:18.720 --> 00:15:18.860 Details. 00:15:19.760 --> 00:15:23.900 Also, if you run a script that somehow changes the database outside of that, 00:15:24.280 --> 00:15:26.040 so it needs to run manage.py. 00:15:26.460 --> 00:15:29.300 So I imagine that what's happening is there's a last modified 00:15:29.920 --> 00:15:30.560 on the cache server. 00:15:31.040 --> 00:15:33.540 And every time you run a query, it goes, when was this last modified? 00:15:33.720 --> 00:15:34.680 And if that changes, 00:15:35.170 --> 00:15:36.520 then it's just going to do a full query. 00:15:36.760 --> 00:15:36.840 Otherwise, 00:15:37.080 --> 00:15:37.820 it'll just keep pulling. 00:15:37.960 --> 00:15:38.700 I'll bet you that that's it. 00:15:38.890 --> 00:15:43.340 Because otherwise, if you just use the ORM directly through this other script, it would 00:15:43.350 --> 00:15:43.840 have changed it. 00:15:43.850 --> 00:15:46.380 But you've got to run this manage pi command on it. 00:15:46.620 --> 00:15:47.120 That's what I'm guessing. 00:15:47.200 --> 00:15:49.120 You've got to be in the Django world, 00:15:49.350 --> 00:15:50.640 the Django machinery for it. 00:15:51.020 --> 00:15:51.220 Exactly. 00:15:52.280 --> 00:15:53.340 I've had this problem before. 00:15:53.610 --> 00:15:57.320 If you run Redis caches in Redis command, 00:15:57.620 --> 00:16:00.000 like Redis through Django, like accessing it, 00:16:00.010 --> 00:16:01.760 not just as a cache, but using it directly. 00:16:02.180 --> 00:16:04.100 and you try and do something outside of that Redis, 00:16:04.460 --> 00:16:05.880 there's some subtleties there 00:16:05.940 --> 00:16:07.080 that you've got to be really, really careful of. 00:16:07.120 --> 00:16:07.900 So it sounds like this is similar. 00:16:08.160 --> 00:16:08.620 Yeah, yeah. 00:16:09.740 --> 00:16:12.320 It's using Django ORM technology, 00:16:12.800 --> 00:16:15.880 not the database technology or the cache technology, 00:16:16.060 --> 00:16:16.160 right? 00:16:17.360 --> 00:16:19.900 Like I said, like subscribing to changes to a table or whatever. 00:16:20.040 --> 00:16:21.660 So one of the things that Warren's about is 00:16:21.860 --> 00:16:24.080 if you have a high rate of database modifications, 00:16:24.820 --> 00:16:26.920 then that'll keep invalidating your cache. 00:16:26.970 --> 00:16:29.080 So maybe it won't help that much. 00:16:29.340 --> 00:16:30.460 The win, maybe a lose. 00:16:31.680 --> 00:16:31.780 Exactly. 00:16:32.120 --> 00:16:33.240 You're just adding complexity, 00:16:33.460 --> 00:16:37.960 but maybe every read effectively is going to just run anyway. 00:16:38.200 --> 00:16:39.460 So there's a couple of limits. 00:16:39.720 --> 00:16:40.580 People can check them out, 00:16:40.820 --> 00:16:42.000 different setups and so on. 00:16:42.080 --> 00:16:43.340 But I think it's a cool project. 00:16:43.840 --> 00:16:44.480 So yeah. 00:16:45.259 --> 00:16:52.220 If you're looking to kind of gain a performance gain real quick there, that's an easy one to try and see if it fits your use case. 00:16:53.320 --> 00:16:57.080 Caching is such a bit of magic tixie dust that you can sprinkle on. 00:16:57.460 --> 00:17:00.380 But the challenge is it's the complexity and the invalidation. 00:17:00.980 --> 00:17:01.040 Yeah. 00:17:01.820 --> 00:17:04.120 Yeah, because you don't want to serve the stale data like you mentioned at the beginning. 00:17:04.539 --> 00:17:04.939 Yeah. 00:17:05.339 --> 00:17:05.780 That's interesting. 00:17:06.760 --> 00:17:07.500 Performance is tricky. 00:17:07.720 --> 00:17:08.199 Cash it. 00:17:08.459 --> 00:17:08.600 Yeah. 00:17:08.939 --> 00:17:09.839 Yeah, performance is tricky. 00:17:10.939 --> 00:17:12.240 And speaking of performance, 00:17:12.540 --> 00:17:17.079 some people may think asynchronous is the answer to all things in performance. 00:17:17.400 --> 00:17:23.500 But Carlton Gibson actually had a good bit of work done at the Django on the Med sprint. 00:17:23.819 --> 00:17:25.439 So if you're not familiar with code sprints, 00:17:25.620 --> 00:17:28.800 people get together from time to time and will work on the open source projects. 00:17:29.200 --> 00:17:31.260 And one of the outcomes from the latest sprint 00:17:31.660 --> 00:17:34.260 was a lot of work toward making async 00:17:34.400 --> 00:17:36.860 with transaction atomic come to Django, 00:17:37.320 --> 00:17:38.040 hopefully in 6.2, 00:17:38.200 --> 00:17:39.120 which would be pretty incredible 00:17:39.320 --> 00:17:41.240 because that's the next release of Django. 00:17:41.700 --> 00:17:43.880 And this is one of the pieces that's been missing 00:17:44.020 --> 00:17:45.860 for a while in the Django ecosystem 00:17:46.040 --> 00:17:49.280 is the ability to use the ORM in an asynchronous fashion. 00:17:49.680 --> 00:17:50.900 Because currently ORM, 00:17:51.140 --> 00:17:52.100 you have to still wrap it 00:17:52.240 --> 00:17:55.300 with async to async version of that. 00:17:55.460 --> 00:17:57.740 And so he's got some example code here 00:17:57.760 --> 00:17:59.820 showing basically what this is all about. 00:18:00.060 --> 00:18:01.460 But this is also a very, 00:18:01.640 --> 00:18:02.260 very tricky problem. 00:18:03.220 --> 00:18:05.640 Asynchronous operations and concurrency, 00:18:06.000 --> 00:18:07.680 where multiple things can happen in any order, 00:18:08.220 --> 00:18:10.360 don't combine well typically with database transactions, 00:18:10.840 --> 00:18:12.580 which are necessarily well ordered, 00:18:12.680 --> 00:18:14.400 as he mentions here in the blog post. 00:18:15.880 --> 00:18:17.640 There's a PR open as of, 00:18:17.980 --> 00:18:18.920 I think, yesterday and today 00:18:19.160 --> 00:18:20.780 with no approvals and no milestones yet. 00:18:21.040 --> 00:18:23.200 So if you're excited about transactions 00:18:23.560 --> 00:18:25.840 and the Django ecosystem and ORMs, 00:18:26.200 --> 00:18:27.620 you may want to go check out the current work 00:18:27.840 --> 00:18:30.340 that Carlton did based on this sprint. 00:18:30.620 --> 00:18:33.440 He made quite a bit of forward progress. 00:18:33.910 --> 00:18:36.520 And again, I think that this is not an easy problem 00:18:36.720 --> 00:18:37.960 or else it would have been solved long ago. 00:18:38.100 --> 00:18:42.060 We've had asynchronous views in Django now for years and years. 00:18:42.560 --> 00:18:43.100 And I think that, 00:18:43.700 --> 00:18:44.540 like I mentioned here, 00:18:44.980 --> 00:18:47.600 Django has required using the ORM's sync API 00:18:47.920 --> 00:18:49.360 for transactions specifically. 00:18:49.560 --> 00:18:50.500 If you aren't using a transaction, 00:18:50.640 --> 00:18:52.320 if you didn't wrap it in a begin and a commit, 00:18:52.520 --> 00:18:54.900 which is what you kind of put a wrap a transaction into 00:18:54.920 --> 00:18:57.840 because you're running multiple SQL commands at one time 00:18:58.080 --> 00:18:59.920 or multiple ORM operations at one time, 00:19:00.120 --> 00:19:03.400 you have to use this sync to async wrapper 00:19:03.660 --> 00:19:04.900 to make that all go correctly. 00:19:05.720 --> 00:19:08.580 But now if we get this async with transaction atomic, 00:19:09.080 --> 00:19:09.240 Django, 00:19:09.480 --> 00:19:11.440 it could actually make this work. 00:19:11.840 --> 00:19:14.120 I just think that he puts a little ad in here 00:19:14.240 --> 00:19:16.180 for the Django on the Med sprint, 00:19:16.320 --> 00:19:17.820 which I highly recommend people going to sprints. 00:19:17.960 --> 00:19:19.540 It's a really great way to get involved in the community. 00:19:19.900 --> 00:19:23.300 But if you wanna be able to use this version of the code, 00:19:23.540 --> 00:19:24.780 There's again a PR. 00:19:24.960 --> 00:19:25.900 You can check out the thread. 00:19:26.280 --> 00:19:28.820 You can see how it works for your specific workloads. 00:19:28.980 --> 00:19:30.940 I think a lot of this is going to be workload specific 00:19:31.420 --> 00:19:35.740 and you're heading into kind of extreme performance area here 00:19:35.840 --> 00:19:38.960 when you're talking about asynchronous operations on transactions. 00:19:39.360 --> 00:19:41.880 This could be a big win for your specific workloads. 00:19:42.180 --> 00:19:45.680 It could also be a big headache if it doesn't operate as expected 00:19:45.720 --> 00:19:48.360 or you're not paying close enough attention to the order of operations 00:19:48.580 --> 00:19:49.360 for some of these things, 00:19:49.780 --> 00:19:51.260 which it goes over with in the post. 00:19:51.340 --> 00:19:52.040 It's a really good post. 00:19:52.580 --> 00:19:54.160 They had a fun time there on the Mediterranean. 00:19:55.200 --> 00:19:57.320 Not terrible going for bicycle rides along the sea. 00:19:57.580 --> 00:19:58.120 That looks all right. 00:19:58.380 --> 00:19:59.480 They got quite a bit of work done. 00:20:00.400 --> 00:20:03.440 He actually had, it looks like he collaborated with Caleb Haddington, 00:20:03.840 --> 00:20:05.360 who wrote a book on 00:20:05.800 --> 00:20:05.860 that. 00:20:05.920 --> 00:20:07.360 So you actually click over here, 00:20:07.620 --> 00:20:09.060 the Using Async in Python. 00:20:09.320 --> 00:20:13.000 So someone who knew quite a bit about the async story in Python. 00:20:13.460 --> 00:20:19.139 And so they spent literally three days working through this and ended up with a pull request 00:20:19.160 --> 00:20:22.740 against the ASGIE ref and on the Django bits to make this all go. 00:20:23.160 --> 00:20:24.160 That's pretty optimistic. 00:20:24.470 --> 00:20:26.520 It seems like the right brains got together at the right time, 00:20:26.890 --> 00:20:28.420 which is again the reason why we do 00:20:28.580 --> 00:20:31.960 things like sprints where people get together in person in the same place, 00:20:32.250 --> 00:20:32.840 and usually they're in 00:20:32.980 --> 00:20:33.480 pretty nice places, 00:20:33.700 --> 00:20:35.640 to work on awesome code like this. 00:20:36.390 --> 00:20:37.580 So you can see here, 00:20:37.900 --> 00:20:38.880 again, pretty extensive, 00:20:39.700 --> 00:20:42.000 a couple poll requests for people to go review, 00:20:42.430 --> 00:20:43.160 and lots of thanks, 00:20:43.410 --> 00:20:44.320 and lots of great things 00:20:44.340 --> 00:20:45.460 happened at Django on the Met. 00:20:45.980 --> 00:20:48.240 So I don't know, how do you feel about asynchronous transactions 00:20:48.900 --> 00:20:49.340 to a database? 00:20:49.740 --> 00:20:50.820 I feel okay with it, 00:20:51.020 --> 00:20:51.540 I think. 00:20:51.940 --> 00:20:53.380 I think I feel okay with it. 00:20:53.560 --> 00:20:54.680 I had Calvin, 00:20:55.740 --> 00:20:58.520 I had Carlton, sorry, Carlton. I had Carlton on. 00:20:58.680 --> 00:21:00.280 He and I look the same. 00:21:00.540 --> 00:21:01.120 Yeah, I know. 00:21:01.520 --> 00:21:01.620 Well, 00:21:01.960 --> 00:21:02.600 it's the C. 00:21:03.340 --> 00:21:08.080 So I had him on to talk about updates to Django's async story. 00:21:08.400 --> 00:21:09.080 And it sounds like 00:21:09.360 --> 00:21:11.580 Django's async story is really strong these days. 00:21:11.880 --> 00:21:15.600 It's just down to a couple of little hard problems to solve, 00:21:16.220 --> 00:21:17.200 like transactions. 00:21:17.779 --> 00:21:19.300 I'm a big fan of async. 00:21:19.300 --> 00:21:26.400 I think it unlocks a bunch of different deployment stories and operational stories that are really powerful. 00:21:26.840 --> 00:21:28.700 It doesn't always solve a ton of problems, 00:21:29.100 --> 00:21:29.920 but it can. 00:21:30.160 --> 00:21:30.440 Yeah, 00:21:30.860 --> 00:21:41.640 well, I feel like this keeps Django more than relevant in today's day and age of things like FastAPI and everyone basically touting full asynchronous stories. 00:21:42.200 --> 00:21:45.880 Django is still a very, very valid option when it comes to a web framework. 00:21:45.950 --> 00:21:51.820 And Frank Wiles and I did a presentation at this year's DjangoCon comparing FastAPI with Django and Ninja, 00:21:52.060 --> 00:21:56.400 which Ninja is an API layer on top of Django that does async really, really well. 00:21:56.660 --> 00:21:59.300 and the performance is obviously FastAPI still faster, 00:21:59.700 --> 00:22:01.580 but the performance is really, really good for Django 00:22:01.820 --> 00:22:03.220 if you're using things like Ninja 00:22:03.460 --> 00:22:06.260 because it leverages this asynchronous capabilities 00:22:06.800 --> 00:22:08.860 that folks like Carlton have worked really, really hard 00:22:09.000 --> 00:22:10.820 to make sure that Django has a good story for. 00:22:11.180 --> 00:22:11.400 Yeah. 00:22:11.660 --> 00:22:12.720 You were talking about Django Ninja, 00:22:12.940 --> 00:22:13.000 right? 00:22:13.300 --> 00:22:13.980 Yeah, yeah, Django Ninja. 00:22:14.460 --> 00:22:15.280 Yeah, which is super neat. 00:22:15.380 --> 00:22:17.980 Yeah, the analogous to FastAPI. 00:22:18.480 --> 00:22:20.680 So I think it's really powerful. 00:22:21.340 --> 00:22:22.660 One thing I would throw out there though, 00:22:22.820 --> 00:22:26.080 this is not even necessarily related to async, 00:22:26.300 --> 00:22:27.800 but it could be in the mix here. 00:22:28.150 --> 00:22:30.940 So if you're worried about transactions and performance, 00:22:31.580 --> 00:22:32.980 and this is a big caveat, 00:22:33.150 --> 00:22:33.940 but if it's true, 00:22:34.420 --> 00:22:35.900 and you're using ORMs, 00:22:36.130 --> 00:22:39.440 you could use a design pattern called optimistic concurrency, 00:22:39.940 --> 00:22:42.600 which itself is already a pretty interesting thing. 00:22:42.970 --> 00:22:46.620 Like ORMs don't necessarily always work that well with transactions. 00:22:47.120 --> 00:22:47.220 Right. 00:22:47.520 --> 00:22:49.360 Because I'm going to do a query, I'm going to get a user object. 00:22:49.560 --> 00:22:52.040 I'll return that user object to some other part of the code. 00:22:52.340 --> 00:22:54.420 If it makes a change to it, it needs to save it. 00:22:54.660 --> 00:22:57.700 Like you don't want to let the entire request run within a single transaction, 00:22:58.070 --> 00:22:58.180 right? 00:22:58.780 --> 00:23:00.820 These need to be like, I'm doing the data stuff and then I'm done. 00:23:01.250 --> 00:23:04.440 But if you say like, well, we're going to enforce concurrency by just like the beginning 00:23:04.510 --> 00:23:07.340 of a web request and the end of the web request becomes a transaction. 00:23:07.520 --> 00:23:11.600 You're just saying I'm having a single threaded process end to end, which is not great. 00:23:11.870 --> 00:23:16.220 So optimistic concurrency puts a last modified hash on the result. 00:23:16.370 --> 00:23:21.900 And when you try to save it, it's going to say update the username to name where the modified 00:23:22.220 --> 00:23:23.580 hash is equal to the one that I have. 00:23:23.680 --> 00:23:24.320 And if that changes, 00:23:24.960 --> 00:23:26.240 like, oh, it was changed behind you, 00:23:26.420 --> 00:23:28.980 you know, you could catch that, requery it, make the, you know what I mean? 00:23:29.100 --> 00:23:34.200 Like that can get you some better concurrency and some better safety if you're using an ORM, right? 00:23:34.280 --> 00:23:35.720 Like that's a pretty big story. 00:23:36.020 --> 00:23:36.720 But I don't know. 00:23:36.800 --> 00:23:37.720 There's a lot going on here. 00:23:37.860 --> 00:23:43.940 I don't know how I feel about ASync transactions because I try to avoid using too many transactions already. 00:23:44.380 --> 00:23:44.820 Usually you don't. 00:23:45.100 --> 00:23:45.220 But, 00:23:45.460 --> 00:23:46.260 you know, if you're running a bank, 00:23:46.420 --> 00:23:46.780 you want them. 00:23:47.120 --> 00:23:47.240 Right. 00:23:47.380 --> 00:23:48.760 things can get out of order and, 00:23:48.810 --> 00:23:53.200 and then you could end up with a strange right history based on performance. 00:23:53.480 --> 00:23:56.680 If some slow query opens the first transaction and there's a fast one that 00:23:56.780 --> 00:23:57.580 comes behind it, 00:23:58.080 --> 00:23:58.600 making a right, 00:23:59.320 --> 00:24:00.520 you've got to make sure you handle that. 00:24:00.820 --> 00:24:02.440 So it looks like we're working on it. 00:24:02.820 --> 00:24:02.920 Yeah. 00:24:03.040 --> 00:24:03.100 Yeah. 00:24:03.110 --> 00:24:04.880 And you got to start talking like transaction, 00:24:05.730 --> 00:24:05.820 uh, 00:24:06.260 --> 00:24:07.500 concurrency levels within trans, 00:24:07.700 --> 00:24:08.740 like read committed, 00:24:08.980 --> 00:24:09.600 read uncommitted, 00:24:09.940 --> 00:24:11.620 all the different things you can set on a database. 00:24:11.770 --> 00:24:12.140 It gets, 00:24:12.520 --> 00:24:12.760 all right. 00:24:12.790 --> 00:24:13.140 I always, 00:24:13.240 --> 00:24:13.940 that part's still hard. 00:24:14.240 --> 00:24:14.840 That part's still hard. 00:24:14.840 --> 00:24:15.360 I can't do it. 00:24:15.400 --> 00:24:16.000 We just got to talk. 00:24:16.020 --> 00:24:16.820 Let's just talk about something. 00:24:16.980 --> 00:24:17.940 Let's go talk about our extras. 00:24:18.200 --> 00:24:18.680 How about some extras, 00:24:18.860 --> 00:24:18.940 Michael? 00:24:19.080 --> 00:24:19.340 What do you got? 00:24:19.800 --> 00:24:20.120 Well, 00:24:20.360 --> 00:24:20.840 let's see here. 00:24:20.860 --> 00:24:22.140 I already got them all queued up. 00:24:22.860 --> 00:24:23.780 So first extra, 00:24:24.100 --> 00:24:26.140 this comes to us from Christian Klaus, 00:24:26.420 --> 00:24:28.200 as you can see here, right now here, 00:24:28.580 --> 00:24:29.640 at Mike C. Kennedy, 00:24:29.880 --> 00:24:33.720 FYI update on Calvin's first topic, 00:24:34.160 --> 00:24:36.220 free threaded wheels for polars. 00:24:36.540 --> 00:24:36.700 Oh, 00:24:36.860 --> 00:24:36.960 wow. 00:24:37.260 --> 00:24:37.560 Very quick. 00:24:37.940 --> 00:24:39.180 So we've already got, 00:24:39.820 --> 00:24:39.960 well, 00:24:40.180 --> 00:24:43.200 there's a very interesting story and people out there may 00:24:43.340 --> 00:24:44.200 know a little better than I do. 00:24:44.300 --> 00:24:47.500 So I only have like very sparse GitHub comments to go on. 00:24:47.620 --> 00:24:49.960 So please give me some leeway to get it right here. 00:24:50.320 --> 00:24:53.720 So this is an open issue to add free-threaded wheels, 00:24:53.940 --> 00:24:57.180 like add the A-B-I-T wheels to PyPI. 00:24:57.340 --> 00:25:01.080 So it says currently Polars builds on the free-threaded Python build. 00:25:01.300 --> 00:25:02.120 So you can use it, 00:25:02.300 --> 00:25:03.940 but there's no binary wheels. 00:25:04.540 --> 00:25:09.020 It's going to be like a slow install build or rust and so on. 00:25:09.260 --> 00:25:09.800 But to be clear, 00:25:10.120 --> 00:25:13.260 you can use Polars 2 on free-threaded Python. 00:25:13.660 --> 00:25:15.780 Just the installing of it is a bit tricky. 00:25:16.340 --> 00:25:18.580 So this issue is like, can we make that better? 00:25:19.000 --> 00:25:19.380 It's open. 00:25:19.940 --> 00:25:21.440 That's the part that's interesting, 00:25:21.600 --> 00:25:22.560 that it's not closed. 00:25:22.820 --> 00:25:24.860 But if you go down here somewhere, 00:25:25.260 --> 00:25:26.860 if I look for PyPI, 00:25:27.480 --> 00:25:28.300 it says, 00:25:28.720 --> 00:25:32.640 however, before we can do it, we still have to wait on getting more space from PyPI 00:25:32.940 --> 00:25:36.780 because PyPI has said that you're using too much space 00:25:36.840 --> 00:25:38.760 and we're not going to allow you to upload anything anymore. 00:25:39.280 --> 00:25:40.020 That's a new one. 00:25:40.300 --> 00:25:41.640 So you can see the request here. 00:25:41.880 --> 00:25:44.720 If you jump over to it and you wait for GitHub, 00:25:44.960 --> 00:25:46.700 because GitHub has become slow the last few years, 00:25:46.960 --> 00:25:48.280 not on a red sentence fault. 00:25:48.740 --> 00:25:50.440 But over on PyPI, 00:25:50.650 --> 00:25:51.120 it says, 00:25:51.510 --> 00:25:53.500 project limit request, pullers runtime compatibility, 00:25:53.980 --> 00:25:54.480 50 gigabytes, 00:25:54.770 --> 00:25:54.920 please. 00:25:56.520 --> 00:25:57.680 And it's asking for, 00:25:57.860 --> 00:25:59.500 this is by Richie Vink, 00:25:59.600 --> 00:26:01.600 the creator, as you mentioned before. 00:26:02.150 --> 00:26:03.100 And it said, help, 00:26:03.280 --> 00:26:04.340 we can't upload anymore. 00:26:04.980 --> 00:26:07.080 So this is an interesting problem because... 00:26:07.080 --> 00:26:09.900 Yeah, obviously they're trying to avoid abuse of PyPI. 00:26:10.580 --> 00:26:12.640 Right. And just trying to pay for it. You know, 00:26:13.640 --> 00:26:15.720 they're asking for 50 gigs. That's a lot of space. 00:26:16.080 --> 00:26:16.880 At the same time, 00:26:17.280 --> 00:26:23.160 if you have a popular project that has a big binary built component like the rest part of this, 00:26:23.600 --> 00:26:26.100 and you want to support all the different things, right? 00:26:26.120 --> 00:26:28.740 I want to support free threaded wheels on ARM, 00:26:29.280 --> 00:26:36.280 you know, like all the different things that you might build for that starts to explode out into a bunch of combinatorial options that take a lot of space. 00:26:36.360 --> 00:26:41.600 right so i'm sympathetic to it somebody it's just i don't know i can't remember where it was um so 00:26:41.900 --> 00:26:47.120 it's like do do we really need pi pi yes you really need it to be or do do we really no do 00:26:47.120 --> 00:26:53.540 we really need old releases on pi pi i'm like yes yes yes you do please anyway thank you christian 00:26:53.640 --> 00:26:59.460 klaus for sending this in this is um it's about polars it ties into your items but it's also just 00:26:59.570 --> 00:27:04.139 an interesting difficulty of the day you know there's still things going on behind the scenes 00:27:04.260 --> 00:27:10.920 absolutely okay two more things i want to cover real quick let's do this one next so i've i started 00:27:11.120 --> 00:27:17.520 working on these write-ups that are basically telling like guides visual guides to talk python 00:27:17.780 --> 00:27:24.320 episodes that tell this the technical story of what the episode was about so for example we've got 00:27:24.330 --> 00:27:30.999 let's see the probably the funnest one is this eve because it's a game so it's got maybe 10 to 15 00:27:31.020 --> 00:27:31.280 graphics. 00:27:31.750 --> 00:27:32.780 Got a nice little reader view. 00:27:32.940 --> 00:27:34.940 You can do like full screen or you can, 00:27:35.180 --> 00:27:35.800 you know, 00:27:36.140 --> 00:27:36.300 a little, 00:27:36.580 --> 00:27:38.940 it's like a little Instapaper-ish because it's, 00:27:39.180 --> 00:27:40.560 it's a decent amount of reading. So it goes through 00:27:40.660 --> 00:27:41.120 and it says, 00:27:41.500 --> 00:27:41.700 you know, 00:27:42.000 --> 00:27:45.540 okay, what is this? It talks about like the problem with nice pictures, 00:27:46.300 --> 00:27:47.240 tells the story of, 00:27:47.400 --> 00:27:49.240 of what all the, what's going on. And just, 00:27:49.540 --> 00:27:51.180 it has this like visual storytelling 00:27:51.500 --> 00:27:52.660 component of each, 00:27:53.090 --> 00:27:53.180 um, 00:27:54.040 --> 00:27:54.980 of each episode. 00:27:55.540 --> 00:27:57.359 And so I've been working on this. I don't have that many 00:27:57.360 --> 00:27:57.580 out. 00:27:57.740 --> 00:27:59.380 I think I've got six out, 00:27:59.840 --> 00:28:01.600 but I just, I was fascinated with like, 00:28:01.760 --> 00:28:02.600 could I make a visual 00:28:03.240 --> 00:28:03.900 storytelling thing? 00:28:04.100 --> 00:28:04.700 That's just not, 00:28:05.000 --> 00:28:05.660 it's not just narration, 00:28:06.060 --> 00:28:06.380 right? It's, 00:28:06.700 --> 00:28:07.580 it's, let's look at the 00:28:07.700 --> 00:28:11.900 different things discussed in the episode and kind of make a technical article out of them. 00:28:12.190 --> 00:28:12.320 Yeah. 00:28:12.520 --> 00:28:13.700 Well, and people learn differently. 00:28:14.020 --> 00:28:15.040 Some people want to hear the podcast. 00:28:15.300 --> 00:28:15.700 Some people want 00:28:15.700 --> 00:28:18.780 to read the blog posts and some people would love this visual representation, 00:28:19.080 --> 00:28:19.280 which is, 00:28:19.470 --> 00:28:19.840 I like how 00:28:19.850 --> 00:28:22.500 it themed or how you theme the graphics, 00:28:23.320 --> 00:28:24.320 you know, in line with Eve, 00:28:24.620 --> 00:28:25.220 you know, as opposed to. Yeah. 00:28:25.360 --> 00:28:29.220 Thanks. There's a bunch of really cool graphics in here. 00:28:29.700 --> 00:28:30.540 It's very sci-fi looking. 00:28:31.120 --> 00:28:31.260 Yeah. 00:28:31.560 --> 00:28:33.800 And each one's a little bit of a different theme. 00:28:34.100 --> 00:28:37.180 I'll go to the one that we just did together, 00:28:37.420 --> 00:28:39.480 the state of the art in Python. 00:28:40.279 --> 00:28:42.660 And it's got some really interesting pictures. 00:28:43.420 --> 00:28:45.420 Check it out. If you just go to Talk Python, 00:28:45.800 --> 00:28:46.760 hover over episodes, 00:28:47.060 --> 00:28:48.360 it drops into the visual guides 00:28:48.400 --> 00:28:50.200 and you can go and see all of them. 00:28:50.280 --> 00:28:51.700 Like I said, there's a handful of them. 00:28:51.980 --> 00:28:53.420 It's not just a podcast anymore. 00:28:53.800 --> 00:28:55.240 No, it's so much more. 00:28:55.280 --> 00:28:55.940 So much more. 00:28:57.340 --> 00:28:58.420 And you've got so much more. 00:28:59.080 --> 00:29:00.880 Then, remember how I lamented? 00:29:01.200 --> 00:29:02.080 And I wish I knew this. 00:29:02.880 --> 00:29:04.060 Two people sent this in. 00:29:04.200 --> 00:29:04.620 Nick Moua. 00:29:04.980 --> 00:29:05.260 Hey, Nick. 00:29:05.500 --> 00:29:06.860 And Raphael Bosen and said, 00:29:06.960 --> 00:29:07.200 Michael, 00:29:07.360 --> 00:29:10.920 you kind of went off on PEP 824 about like, 00:29:11.140 --> 00:29:12.320 why is it just so focused? 00:29:12.400 --> 00:29:14.300 Couldn't it have this other thing that you wanted? 00:29:14.660 --> 00:29:16.080 And you're like, no, I don't really want it. 00:29:16.180 --> 00:29:16.920 What are you talking about? 00:29:16.980 --> 00:29:17.260 You're insane. 00:29:17.880 --> 00:29:18.160 Well, 00:29:18.400 --> 00:29:20.940 if I had just gone back at one in PEP numbers, 00:29:22.099 --> 00:29:29.740 8pep823 is in fact that null coalescing operator that I was looking for right like a.b question mark 00:29:29.820 --> 00:29:37.040 dot c d is the complicated sort of deal here that if I'm trying to access something in a chain 00:29:37.200 --> 00:29:43.640 like x.y.z.whatever if any of those is none I need to just stop and say it's none or stop and 00:29:43.640 --> 00:29:50.160 raise an exception like that that that is not none type has no attribute whatever this is what that's 00:29:50.160 --> 00:29:51.120 about. So that's pretty interesting. 00:29:51.400 --> 00:29:52.940 And I think I'm here for it. 00:29:53.140 --> 00:29:53.240 Nice. 00:29:53.640 --> 00:29:53.700 Yeah. 00:29:54.100 --> 00:29:54.900 Last thing. And this 00:29:54.970 --> 00:29:55.960 one is, it's a big one. 00:29:56.240 --> 00:29:57.760 This is really fun. 00:29:58.070 --> 00:29:58.560 This is really, 00:29:58.820 --> 00:29:59.500 yeah, this is a big one. 00:29:59.660 --> 00:30:00.560 So I'm 00:30:01.520 --> 00:30:02.740 launching Talk Python membership, 00:30:03.340 --> 00:30:06.440 and I'm hoping that we can create a really nice community over 00:30:06.520 --> 00:30:08.320 there that has a couple of aspects. 00:30:08.680 --> 00:30:10.000 So I've been thinking for a long time, 00:30:10.160 --> 00:30:10.220 like, 00:30:10.520 --> 00:30:10.960 couldn't I offer 00:30:11.160 --> 00:30:12.980 something like a little bit more for people, 00:30:13.160 --> 00:30:15.220 listeners of the podcast and this podcast too, 00:30:15.520 --> 00:30:19.740 that's one thing I could offer that seems super obvious, like, hey, you get ad free episodes, 00:30:19.980 --> 00:30:21.240 or you get episodes ahead of time. 00:30:21.270 --> 00:30:21.760 It's like, well, 00:30:22.580 --> 00:30:22.820 you know, 00:30:23.200 --> 00:30:23.640 that's great, 00:30:23.690 --> 00:30:24.700 but that's not that great of it. 00:30:24.760 --> 00:30:25.740 Like that's not a huge benefit. 00:30:25.980 --> 00:30:26.520 So sure, 00:30:26.940 --> 00:30:28.400 Talk Python membership does come with ads, 00:30:28.560 --> 00:30:30.340 but I wanted to see what else I could offer. 00:30:30.430 --> 00:30:33.280 So it comes with a nice Discord community. 00:30:33.670 --> 00:30:36.300 A bunch of the Talk Python guests are already in the community. 00:30:36.450 --> 00:30:38.220 So you can come hang out with many of the people 00:30:38.440 --> 00:30:39.840 that you've heard on the show. 00:30:40.240 --> 00:30:40.460 Yeah. 00:30:40.720 --> 00:30:41.000 Calvin, 00:30:41.320 --> 00:30:41.560 for example. 00:30:41.580 --> 00:30:44.540 It's been one of the reasons I've now keeping Discord open 00:30:44.980 --> 00:30:45.400 more regularly. 00:30:46.140 --> 00:30:46.440 That's awesome. 00:30:46.700 --> 00:30:47.980 There's enough gravitational pull 00:30:48.370 --> 00:30:49.900 because of the work you're doing there 00:30:49.920 --> 00:30:50.600 I've keep it open now. 00:30:50.830 --> 00:30:51.100 Thank you. 00:30:51.220 --> 00:30:51.500 That's awesome. 00:30:51.660 --> 00:30:52.140 Yeah, I do too. 00:30:52.400 --> 00:30:53.100 And it's really, 00:30:53.360 --> 00:30:53.500 really, 00:30:53.660 --> 00:30:54.840 it's a neat area to be in. 00:30:54.880 --> 00:30:56.000 And if you're not a gamer, 00:30:56.340 --> 00:30:57.520 just Discord is easier. 00:30:57.600 --> 00:30:58.280 It's easier than Slack. 00:30:58.400 --> 00:30:59.140 It's not just for gamers. 00:30:59.580 --> 00:31:00.880 It's actually just an easier Slack. 00:31:01.070 --> 00:31:01.440 I agree. 00:31:02.960 --> 00:31:06.240 And one of the main things I wanted to focus on is live events. 00:31:06.620 --> 00:31:09.160 So it comes with a meetup. 00:31:09.380 --> 00:31:13.920 If you would like to go to a Python meetup or a regional conference or something like that, 00:31:13.970 --> 00:31:17.180 but your area doesn't have one, you can't make it, or you just want to go to more, 00:31:17.720 --> 00:31:24.380 You could go and I'm running a monthly tech session where it's like a conference style presentation, 00:31:24.720 --> 00:31:30.820 but then sort of a mix and mingle, just hang out on Discord video channels with whoever gave the presentation and everyone else, 00:31:31.110 --> 00:31:31.620 me included. 00:31:31.880 --> 00:31:33.060 So all those things. 00:31:33.500 --> 00:31:36.440 And I'm also going to add a preview, 00:31:36.940 --> 00:31:39.300 like a summary type of thing to the episode. 00:31:39.430 --> 00:31:41.720 So a separate sidecar podcast feed. 00:31:42.030 --> 00:31:44.420 Like here's an hour and 20 minute podcast episode, 00:31:44.770 --> 00:31:46.280 but here's a four minute. 00:31:46.920 --> 00:31:47.480 What's it about? 00:31:47.600 --> 00:31:48.300 kind of the cliff notes. 00:31:48.470 --> 00:31:49.420 And if you find that interesting, 00:31:49.880 --> 00:31:51.120 then you can go listen to the full one, 00:31:51.370 --> 00:31:51.440 right? 00:31:51.640 --> 00:31:52.480 Kind of let you, you know, 00:31:52.880 --> 00:31:53.700 protect your time a little bit, 00:31:53.860 --> 00:31:55.020 but keep up on the ones that, 00:31:55.300 --> 00:31:56.260 I don't know, you don't have the time to listen. 00:31:56.360 --> 00:31:56.720 I love it. 00:31:57.000 --> 00:31:57.420 I'm here for it. 00:31:57.520 --> 00:31:58.440 I'm all about community. 00:31:58.740 --> 00:32:00.440 And so this is a great, great move. 00:32:00.540 --> 00:32:01.260 I'm glad you're doing this. 00:32:01.520 --> 00:32:01.700 Thanks. 00:32:02.030 --> 00:32:02.540 Thank you so much. 00:32:02.960 --> 00:32:03.740 So folks, 00:32:04.220 --> 00:32:05.200 support all the work. 00:32:05.919 --> 00:32:06.480 Talkpython.fm. 00:32:06.750 --> 00:32:08.000 Click on membership right at the top. 00:32:08.240 --> 00:32:08.580 Check it out. 00:32:08.670 --> 00:32:09.100 Be part of it. 00:32:09.140 --> 00:32:09.500 Hope you're there. 00:32:09.740 --> 00:32:09.940 Cool. 00:32:10.070 --> 00:32:10.140 Well, 00:32:10.300 --> 00:32:10.900 thank you for all that. 00:32:11.040 --> 00:32:12.980 That's an amazing extra to end on there for you. 00:32:13.240 --> 00:32:14.080 I've got a couple extras 00:32:14.340 --> 00:32:17.560 that we want 00:32:17.600 --> 00:32:19.660 is the fact that Jazz Band is shutting down. 00:32:19.720 --> 00:32:20.820 That was announced back in March, 00:32:21.040 --> 00:32:24.680 but there was a renewed discussion a week ago here on Reddit. 00:32:25.140 --> 00:32:26.680 And one of the things that came out of that is, 00:32:26.760 --> 00:32:27.240 by the way, 00:32:27.640 --> 00:32:28.300 there's Django Commons 00:32:28.800 --> 00:32:30.480 for things like what Jazz Band used to do. 00:32:30.660 --> 00:32:31.680 So if you wanted to come out 00:32:31.960 --> 00:32:33.740 and have a place where you can find 00:32:34.320 --> 00:32:37.620 kind of more of the Commons supported projects for Django, 00:32:37.740 --> 00:32:40.620 make sure you check out django-commons.org. 00:32:40.920 --> 00:32:41.620 You can join the Commons, 00:32:41.780 --> 00:32:42.620 you can see the projects, 00:32:42.720 --> 00:32:43.940 you can see here, you know, 00:32:44.220 --> 00:32:45.520 pretty heavy hitter projects, 00:32:45.840 --> 00:32:47.740 Django Valkey, so support for Valkey, 00:32:48.280 --> 00:32:49.760 things like Tailwind CLI, 00:32:50.300 --> 00:32:50.980 DRF stuff. 00:32:52.640 --> 00:32:53.580 One of my favorites, 00:32:54.040 --> 00:32:54.700 Django FSM 2 00:32:55.140 --> 00:32:56.980 is now part of the Commons projects. 00:32:57.320 --> 00:32:59.100 So tons more that are joining in there, 00:32:59.500 --> 00:33:00.020 all one home, 00:33:00.280 --> 00:33:02.680 which means they have a nice, safe place to live. 00:33:02.900 --> 00:33:03.860 So check out the Django Commons. 00:33:04.280 --> 00:33:07.600 The other thing, this is not necessarily Python related, 00:33:07.660 --> 00:33:09.000 but boy, is it an awesome, 00:33:09.260 --> 00:33:10.640 fun little tool I found. 00:33:10.960 --> 00:33:13.160 Since I'm doing more and more of my agentic work 00:33:13.360 --> 00:33:15.800 on remote machines and a lot of the output 00:33:15.820 --> 00:33:17.220 maybe markdown files, 00:33:17.440 --> 00:33:21.800 I would love to have a very rich way to view markdown in the terminal. 00:33:22.050 --> 00:33:26.840 So I went and searched for a TUI slash CLI markdown navigator and I found TreeMD. 00:33:27.600 --> 00:33:29.320 I believe it is in Rust. 00:33:29.940 --> 00:33:32.160 Rust? Yeah, 99.2% Rust. 00:33:32.830 --> 00:33:35.380 But it is a really nice markdown viewer, 00:33:35.550 --> 00:33:39.060 which gives you obviously mouse usage. A lot of the TUI apps, 00:33:39.330 --> 00:33:40.840 the big benefit is you can use the 00:33:40.760 --> 00:33:41.940 mouse in your terminal. 00:33:42.400 --> 00:33:43.240 It gives you an outline. 00:33:43.860 --> 00:33:45.700 It gives you obviously a rich rendering. 00:33:46.220 --> 00:33:46.420 If your 00:33:46.760 --> 00:33:48.000 terminal supports images, 00:33:48.320 --> 00:33:51.240 it will see inline images inside the markdown files. 00:33:51.480 --> 00:33:51.680 Wow. 00:33:52.060 --> 00:33:52.140 Yeah, 00:33:52.420 --> 00:33:52.640 that's cool. 00:33:52.880 --> 00:33:56.000 See by their screenshot doesn't show that off because that's actually a really fancy 00:33:56.200 --> 00:33:56.900 feature of this. 00:33:57.140 --> 00:33:58.660 You can jump in the outline. 00:33:59.080 --> 00:34:00.440 I'll make that bigger maybe. 00:34:00.620 --> 00:34:01.420 Yeah, there you go. You 00:34:01.420 --> 00:34:03.080 can jump in the outline to various sections. 00:34:03.500 --> 00:34:06.559 You can also pre-filter a markdown file from the 00:34:06.560 --> 00:34:07.560 command line to say, 00:34:07.780 --> 00:34:11.179 show me all the Rust snippets or Python code snippets in there. 00:34:11.440 --> 00:34:11.940 And then it'll 00:34:12.100 --> 00:34:16.460 basically filter the document down to just those snippets and give you a navigator of the various 00:34:16.720 --> 00:34:19.260 snippets. Cause you're like, I'm looking for a code sample in this markdown. 00:34:19.600 --> 00:34:20.179 Just show me only 00:34:20.220 --> 00:34:20.620 those pieces. 00:34:21.000 --> 00:34:24.800 And you can do that with a tree MD. So I know again, it's not a, not a Python tool, 00:34:24.960 --> 00:34:25.300 but boy, 00:34:25.540 --> 00:34:30.200 is it a part of my new productivity toolkit of great things that I have installed 00:34:30.560 --> 00:34:36.120 to basically remote work remotely with my agents and the outputs that are coming from them. 00:34:36.320 --> 00:34:38.340 So another cool thing that I'll mention, 00:34:38.540 --> 00:34:39.320 remote documents. 00:34:39.879 --> 00:34:44.600 You can type treeMD and like a GitHub repo reference to owner slash repo, 00:34:44.919 --> 00:34:47.379 and it will get to open the readme immediately. 00:34:47.919 --> 00:34:51.340 Or you can just put in any URL to a raw markdown file on the web, 00:34:51.840 --> 00:34:54.460 and it's now open in your local viewer in your command line. 00:34:54.600 --> 00:34:55.440 So you can be remote. 00:34:55.679 --> 00:34:58.700 You know, I've been doubling down on my usage of herdr 00:34:59.080 --> 00:35:00.860 and my framework desktop that's over here 00:35:01.280 --> 00:35:03.680 so that I can run my Pi sessions on my CloudCo sessions. 00:35:03.880 --> 00:35:05.860 And now I can view all my markdown files. 00:35:06.280 --> 00:35:11.960 so that was a cool one i think it's a great a great find it looks really nice so two things first one 00:35:11.960 --> 00:35:16.100 thing i've learned there are so many projects by running this show there are so many projects out 00:35:16.100 --> 00:35:20.920 there that are a UI focused sort of thing and they sometimes don't even have one screenshot what are 00:35:20.930 --> 00:35:26.840 you doing you're literally the thing you're about this you are about pictures why do you have no 00:35:27.000 --> 00:35:32.920 picture right there's only words here and it's got themes too oh yeah i love it like nine different 00:35:32.960 --> 00:35:33.160 themes. 00:35:34.010 --> 00:35:34.140 Yeah. 00:35:34.530 --> 00:35:34.880 And the other, 00:35:35.090 --> 00:35:35.460 I think, 00:35:35.840 --> 00:35:38.560 is our mission is to bring tools to Python developers, 00:35:38.750 --> 00:35:39.220 not necessarily. 00:35:39.600 --> 00:35:41.580 I don't think they don't have to be Python tools. 00:35:42.010 --> 00:35:43.660 It doesn't have to be written in, 00:35:43.960 --> 00:35:45.040 compiled in or whatever, 00:35:45.650 --> 00:35:45.760 Python, 00:35:46.380 --> 00:35:48.700 in order for it to be something awesome that we can use. So 00:35:48.870 --> 00:35:49.400 I think it's great. 00:35:49.840 --> 00:35:49.980 Cool. 00:35:50.340 --> 00:35:50.600 All right, 00:35:50.920 --> 00:35:51.080 Michael. 00:35:51.360 --> 00:35:52.860 Would you say that it looks good for you? 00:35:53.440 --> 00:35:55.080 It does look good. Oh, no, it started playing. 00:35:57.940 --> 00:36:03.720 All right, so the joke this week comes to us from this guy named Calvin sent this in to me. 00:36:04.000 --> 00:36:09.940 No, Calvin shared this with me earlier, and it's, boy, this thing captures the zeitgeist so well, doesn't it? 00:36:10.820 --> 00:36:12.200 It's called Looks Good to Me, 00:36:12.640 --> 00:36:13.120 LGTM, 00:36:13.660 --> 00:36:15.020 Claude Opus 5.5. 00:36:16.800 --> 00:36:17.820 It starts on a Friday. 00:36:18.160 --> 00:36:20.960 It's this kinetic typography, 00:36:21.240 --> 00:36:23.340 a lot of moving words sort of interesting. 00:36:23.560 --> 00:36:24.780 Really well done, I think, on the graphics. 00:36:25.380 --> 00:36:33.900 And it talks about basically the story of the manager who gets super psyched about AI and just makes everyone use it. 00:36:34.240 --> 00:36:34.360 Yeah. 00:36:34.680 --> 00:36:35.700 So go give it a listen. 00:36:35.920 --> 00:36:37.540 It's a fun little music video. 00:36:37.610 --> 00:36:39.500 I believe it was generated by AI itself, 00:36:39.820 --> 00:36:39.920 too, 00:36:40.200 --> 00:36:40.620 which is kind of fun. 00:36:40.620 --> 00:36:41.180 Oh, it's got to be. 00:36:41.460 --> 00:36:41.940 It's got to be. 00:36:42.160 --> 00:36:43.200 Very meta. 00:36:44.400 --> 00:36:51.000 You've got to be careful because once you go down this path, I believe it will send you down a path of other Opus 5 videos. 00:36:51.460 --> 00:36:52.520 I'll set the stage. 00:36:52.620 --> 00:36:53.160 So there's a Slack. 00:36:53.600 --> 00:36:54.400 I mean, it's not actually Slack, 00:36:54.600 --> 00:36:55.300 but you know it's Slack. 00:36:55.640 --> 00:36:56.440 and Brad, 00:36:56.680 --> 00:36:57.780 VP of Velocity, 00:36:59.000 --> 00:36:59.940 Vice President of Velocity. 00:37:00.300 --> 00:37:00.520 Hey team, 00:37:00.760 --> 00:37:01.160 quick one. 00:37:01.240 --> 00:37:01.760 Before the weekend, 00:37:01.980 --> 00:37:04.340 leadership is super excited about AI. 00:37:04.660 --> 00:37:05.120 Off it goes. 00:37:05.440 --> 00:37:06.000 It's like, 00:37:06.180 --> 00:37:06.320 ooh. 00:37:07.660 --> 00:37:08.680 Give it a listen. 00:37:09.280 --> 00:37:10.460 You'll definitely laugh. 00:37:10.920 --> 00:37:11.720 It's very fun. 00:37:11.720 --> 00:37:11.980 You'll get a giggle. 00:37:12.300 --> 00:37:12.760 Yeah, you will. 00:37:13.020 --> 00:37:13.320 You know what? 00:37:13.340 --> 00:37:16.400 I think this is a perfect bookend as well, Calvin. 00:37:16.980 --> 00:37:21.960 We started with Sir Mix-a-Lot and we end with LGTM. 00:37:22.300 --> 00:37:22.600 Let's go. 00:37:22.860 --> 00:37:23.840 Looks good to me. 00:37:24.120 --> 00:37:24.600 All right, Michael. 00:37:25.060 --> 00:37:26.520 This episode looks good to me. 00:37:27.420 --> 00:37:28.360 Let's give it a wrap. 00:37:28.820 --> 00:37:29.600 Let's give it a wrap. 00:37:29.720 --> 00:37:30.140 Oh, my gosh. 00:37:30.300 --> 00:37:30.440 All right. 00:37:30.880 --> 00:37:30.940 Bye, 00:37:31.140 --> 00:37:31.200 all. 00:37:31.900 --> 00:37:32.380 See y'all later.