Django Developers Survey Results & Reproducible Python Builds

0:00Welcome to the Real Python Podcast. This is episode 311. One of the latest trends uncovered in the 2026 Django Developers survey. How are Django users employing LLMs in their development process? Christopher Trudeau is back on the show this week with another batch of Pycoders Weekly, Articles, and Projects. We discuss the summary by Will Vincent about this year's Django Developers survey. The survey draws on responses from nearly 3,500 developers across more than 40 countries. It provides a look at how developers are adapting to AI workflows, in which tools they're embracing. We dig into a post from Brett Cannon about reproducible builds in Python. It covers the importance of creating an independently verifiable repeatable build of C Python and other associated tools. The post explains why Python isn't there yet, and the direction of the work still needed. We also share several other articles and projects

1:01from the Python community, including recent releases, upcoming PSF elections, Polar's versus SQL differences nobody is talking about, creating Django unsubscribe links without a login, allow for it to make measurement units easier through PIDantic, and a tool to convert if else code to match statements. This episode is brought to you by 6 feet up, the Python and AI experts who solve hard software problems, whether it's scaling an application, deriving insights from data, or getting results from AI. 6 feet up helps you move forward faster. See what's possible at 6 feet up.com. All right, let's get started.

2:06The Real Python podcast is a weekly conversation about using Python in the real world. My name is Christopher Bailey, your host. Each week we feature interviews with experts in the community in discussions about the topics, articles, and courses found at realpython.com. After the podcast, join us and learn real world Python skills with a community of experts at realpython.com. Hey Christopher, welcome back. Hey there. We got a lot of news. And announcements and other fun stuff. Yes, welcome to the all news version of the Real Python podcast. What were we going to try to sneak in some topics and projects? We'll see what happens. Yeah, yeah. All right, well, we should just dig in. Yeah, guys, this is going to take a while. So the endless march towards October continues, and we now have Python 315 release candidate 2. So library writers, get your test on, go, they've actually sent out a call to go please check this. It's now time to see whether or not anything's broken. So respond to the call. Definitely. And speaking of testing, the first patch for

3:12Django version 6.1 has come out. It fixes over a dozen regressive defects, which were accidentally introduced in the release and sticking with the world of Django, WAGtail, which is the Django based CMS has released version 8. So big milestone. This version concentrates on new API features, making it easier to control and manage the CMS programmatically. We'll link to both the release notes and an article by Tibo Colis that walks you through the new features. I have Tibo and Megan coming on the show. So you can learn a little bit more not only about WAGtail, but like what they've been up to. And they've been talking a lot about AI and their stuff kind of in their sex there. And it's a really great conversation about how an organization needs to think about how they want to embrace something like this out in the open source. Yeah, and they've done some interesting things architecturally as well. And I think that's part of why the concentration here was on API, because they have separated the where AI goes. It's in its own place versus the CMS. And having more

4:15API pieces in it means those two systems can talk to each other a little better. So I think that was kind of the driver behind it was kind of build this wall between those two spaces. So yeah, they're taking very interesting approach here. Cool. The next bit of news is the addition of risk 5, which is what Wikipedia says is the way to pronounce what I've always called risk V as a supported architecture for CPython. If you're not familiar, risk 5 is an open source instruction set that defines how a CPU works. So vendors then can implement it. So think of the assembly language that you have in a CPU risk 5 defines that assembly language. And then a hardware builder can go use that for free because it's open source. For a long time, this architecture was the go to for high end servers as it was far less complicated than the x86 definition, which meant it could do a better job of things like caching and branch prediction eventually until one out, but the platform is still around and still holds its own in microcontrollers and embedded systems. And now it has an

5:16official Python to go with it. So there you go. All right. I've now reached the point in the news where I say, PEP. This time it is PEP 843 titled export statement for dry re exports. And if you're having a bit of deja vu, that's because this is the third PEP having to do with what is and isn't exposed as an export from a module. This one proposes adding an export keyword available as part of an import statement with it. You'd be able to write from internal package export public object. This would work just like an import statement, but would automatically populate the dunder all mechanism. This would mean you wouldn't have to do both the import and keep it in sync with dunder all of the three PEPs. I think I like this one the best. Actually, I probably should say of the two PEPs because 842, which proposed the dunder export variable has been withdrawn. So there seems to be a bunch of different ideas floating around here to deal with the whole what should be exposed from a

6:20module challenge. Hopefully some discussion happens and a simple solution is the result. We'll see on a more meta level. The Python software foundation election is currently on. If you downloaded the podcast when it became available, you'll still have a couple of days to vote voting closes on September 15th. There are actually two elections going on, one for the PSF board and the other for the newly created packaging council. We'll link to the detail pages as well as the interviews tag on the Python blog that has interviews from most of the candidates and links to their asking anything sessions. So if you want to learn a little bit about the people before you vote, there's all sorts of information there. Yeah, I got a little bit more on that at that in one of my topics this week. So excellent. Spoiler alert. Yeah. And you mean we're going to talk about something besides news? Yeah, we still got two to go. The next chunk is totally self-serving, but hey, I got to take advantage of having an audience once in a while. I've just released a new course over at Talk Python

7:24called Up and Running with Rust. It is an introduction to the Rust programming language for Pythonistas. It's meant for programmers, so it doesn't teach you what a list or an object is and quickly gets to the differences between the Python you know and the Rust that you want to learn. The final step in the course teaches you how to write a library in Rust that can be imported and used as a Python package. So if you've been thinking about adding Rust to your arsenal or if your code needs to be higher performance, I hope this would be a good place for you to start. End of self-serving commercial. And the last one. Yeah, I'm not sure what to do with this. So I find this interesting. I also don't want to fan a flame war. I'm not sure exactly what's going on, but anyways. Spray around some fuel and stuff. Exactly. Yeah, throw in gasoline on the fire. There's a discussion going on in the Python forums right now having to do with Pep 805, which is titled Safe Parallel Python. This perhaps actually been around for over a year,

8:28but it's connected to somehow the internals are working and how to make it easier to code within plugins and NC Python in a space where the GIL has gone away. And this means you know there's going to be extra locks and this is supposed to make it, if I understand it correctly, it has to do with signaling when something is safe or when something isn't safe and makes it a little more explicit. Where this gets interesting is recently in the last couple of weeks, the Guido has been participating in the conversation. And there's this kind of one-off line in response to somebody saying this is kind of messy. And he says personally, I wish we'd stuck with the GIL everything was simpler. And coming from anybody, but Guido, that might not be a mic drop. But coming from Guido. And I don't normally like I'm not one to throw gasoline on the fire, but this kind of speaks to my heart. I've got a fair amount of experience with parallel and

9:29concurrent systems and they're gnarly. And my default is always try not to. And so this kind of spoke to my heart a little bit and I found it a bit amusing. So yeah, maybe we'll just leave that there and see what. To our own form of a mic drop. Wait, wait, that's an expectation mic. Exactly. Yeah, mine's tightly hooked in a harness. It ain't going anywhere. So we'll see. Over to you. All right, Diamond and Topics. So my first one is on the Quonsight blog. It's by previous guest and creator of the NARWALS library, Marco Garelli. It's titled The Polars versus Sequel differences. Nobody is talking about some of these crucial differences that he is highlighting here. I'll read from the second paragraph. It's titled mental models and Polars data frames are best thought of as collections of columns, each of which has a unique name. Within each column, all elements must be of a homogeneous type. And all columns must be of the same length. There are no

10:33special tie between the columns as we will see later. This allows for column independence. Roe order is defined, but as we will also see later, Polars doesn't always promise to preserve it. Sequel is a programming language used to interact with databases, which follow the relational model. In the relational model, a table is an unordered bag of rows, each of which is atomic, meaning that it can't be split up. Roe order isn't defined. All the rows may be sorted in a certain manner before being displayed. So to reiterate, Polars data frames are a collection of columns, again, coming from the numpy world, thinking about these individual columns that are being tied together into the data frame, whereas Sequel accesses tables and databases and a table is an unordered bag of rows that are atomic. So he stresses several areas where this may affect your work. The first is row order. Polars' row order is well defined and can be preserved by select and with column operations. In Sequel to perform an order dependent operation, you can use the order by

11:39clause. But if you think about that, that's really ordering after what you've done. And some Sequel engines may maintain order, but if you use different Sequel engines, you might get different results. It's best not to rely on this. He shows a code example of doing cumulative summing in the Polars code versus the Sequel code. And the results are the same, but the ductyb output, in this particular case, would be in a different order. The output shows up, which might be surprising to some people who, again, primarily work with data frames. Column independence, remember, in Polars, it's a collection of columns, and you can form on each independently, which again is powerful, but with such power, you need to be careful with your creativity. Let's just resale it in a different way. He shows an example of removing nulls from two unique columns, and you end up with a confusing result. You start with having three rows. And by doing this operation, suddenly you have two rows as he demonstrates in his code example. So the difference there is that

12:43the rows in Tequel again are atomic. His suggestion is to write maximally safe Polars, then your best off avoiding expressions, which would change the length expressions like drop nulls, or change the order like expression dot sort. Instead of use the data frame equivalence, data frame dot drop nulls, or data frames sort, respectively. So that all the rows are getting truncated or rearranged together, or specify ignore nulls and order by arguments when available. Again, he has code examples kind of showing this off. Literals, this is something I don't use much in this way. The interpretation of literals, such as Polars can be abbreviated when you import it in his PL. So PL dot LIT parentheses one differs between Polars and SQL. And Polars lit one means a row, a single row with a value of one. Whereas in SQL, it means repeat the value of one in every row in this table. It's like you're sort of inserting, if you will, like a column with ones in it. These are some interesting differences

13:48that again, you might think things are more transferable. He notes a few others at the end of the article. He talks about null sorting. If you sort of table in SQL, the null comes last by default in Polars. They come first. This is configurable. I guess in Polars, you would put nulls underscore first equals true, or the reverse and nulls first equals false. Just be aware that the defaults differ if you're porting code. The sum of zero elements is null in SQL and zero in Polars. So his personal feeling is that Polars is more mathematically correct here. Zero is the addition identity, although in practice, I think I'd find this SQL behavior more useful. Did I get zero because my sensor is broken and didn't take any readings or because it took readings which sum to zero. It's a difference that's easy to work around, but you got to be aware of it. And then he talks about another example regarding broadcasting. Polars follows numpy style broadcast,

14:49whereby if you apply a binary expression with inputs of length n and one, then the latter one gets broadcasted to be the length of n. He uses this doing centering, a common thing you might want to do. He has a deeper explanation of this and how this might work inside of SQL. He has an article clamastering.db when you're used to pandas or Polars. So I'll include that link also. So again, some differences here. And if you're bouncing around and moving between these two, which I think is really common. Yeah, I think this stuff always comes down to like, what are your assumptions? I don't use any of these things often enough to have any. So it's always look at the results. No, I'm more in the more fortunate position because I know that that might be wrong. So I have to go and look it up. I think it's when you've got more familiarity with something and then you just assume, well, the other libraries will be that way as well. And yeah, I was recently doing some work and I was, I was assuming it was degrees and none of the math was working. And that's because it was radians. And it was, you know, that assumption bit me, right? Yeah, the other thing is I feel like people

15:53work with such large data sets that these things might get hidden inside there. And unless you're checking for that, like, okay, well, how many rows do we have now? Or something else like that? Well, we're going to touch on it later, but I'm in the process of working on another astronomy course and it uses polar and as I was going through and exploring the data and prepping the course, there were multiple times where I was, I wasn't paying enough attention and the shape had changed. And it was because something was getting filtered or wasn't supposed to be filtered or something that had been filled in that wasn't supposed to be filled in and I'd get like three steps later and I'd be like, that outliers shouldn't be there. Why is that outlier there? And I'm like, oh, I put the end in the wrong place. And it was one of those where, like, if it addressed in one of the cases, it was bad use of nulls. And there were only three or four of them in the table. So the shape didn't change by a lot. And yeah, in large data sets, it's really easy to lose track of that, right? So yeah, definitely. So thanks, Marco.

16:58This episode of the real Python podcast is brought to you by six feet up. What's stopping you? Maybe it's an application that won't scale or an AI initiative that just isn't delivering. That's where six feet up comes in with deep expertise in Python and AI. They solve hard software problems, modernize platforms and get teams to market faster. Their impact speaks for itself, automating healthcare pipelines, helping NASA explore Pluto, building severe weather prediction tools and applying AI to connect farmers with the vital crop data. When the stakes are high and the problems are hard, six feet up is the partner that delivers. See what's possible at six feet up.com. What are you on next year? I've got some Django stuff. Okay. And actually, I got a bunch of Django stuff. Whatever we'll get there. Yeah. Got a theme going today. Django's a pretty big library.

18:01I've been coding in it for a wait a second. Let me look that up. Did you hear that gulp? I've had, I've been coding in this for almost 20 years. Yeah. I even wrote a book on the subject. So I've already taken advantage of you with one commercial today. So I'm just going to leave that book reference. You'll look it up on your own. So, but even with that experience, because of its size, I still occasionally come across stuff I just didn't know Django could do. And that leads me to the article by Bob Belldraboss titled Unsubscribe Links Without a Login Django Signing. So say you have a newsletter and you want to provide the ability for your audience members to unsubscribe. Making changes to an account preference typically means you want them to authenticate. You want to make sure that person making the changes actually that person. Of course, if you want to unsubscribe forcing them to authenticate is an extra barrier. You could just include their ID in the unsubscribe list. But if someone figures that out, they'll be able to call the URL with any ID defeating that whole make sure the person is that person's step that I was talking about.

19:06Django comes with a solution for this. The signing module lets you create a temper evident token containing information like the user ID, but fully encrypted. You can include one of these tokens in an unsubscribe URL. Then when processing the URL, you can check that the token is valid before doing the action. So if somebody mucks with it, the validation step fails and your code can catch that condition. The call that creates this token takes a salt. That's a bit of extra text that you use to help scramble the signature. The salt is needed when decoding and Bob shows an example where he uses two different salts for two different actions. That way the token can't be passed to a different URL for a different purpose. So you can customize how this thing is working. In addition to walking through the necessary code, Bob's article also explains why you want to do unsubscribe as a two-step process. You could just unsubscribe when the URL is visited, but many mail processes visit URLs to check if they're valid and to double check that they don't point at malicious content.

20:07You wouldn't want that automatic check to accidentally unsubscribe the user. So instead, visiting the URL typically goes to a confirm page and then a post from that confirmation page to do the final step. This also gives you the opportunity to ask why they're unsubscribing if you want that info. You've probably seen that pattern of fair amount out there, so this is why they're doing it not just to nag you, but because you kind of have to do it as a two-step process. Then the article finally finishes up by briefly discussing RFC 8058, which is the specification for how providers like Google and Apple can do the unsubscribe step for you, as well as how to use the same feature for doing things like magic login links with expiration times. Bob always writes good content, and I'm always happy to learn something new about one of my favorite libraries. All right. Going back to what I was mentioning before, this next piece I have is from Friend of the Show, Brett Cannon. Speaking of the inaugural Python packaging council election, Brett is running. He has a blog post with his thoughts and his background in consideration of

21:11voting for him. He has been continuing his work on standards and making things reproducible, but also safe. We talked about it very recently on the show. He's involved in a variety of peps that we covered there, and he also worked on one, PEP 770, which I actually discuss a little bit more with upcoming guest Seth Larson, who's the PSF security development resonance. They both worked on this. We briefly mentioned it back in episode 250 on the show while we were in Dublin. That PEP is titled Improving Measureability of Python Packages with Software Bill of Materials. And this has become even more important in this sort of age of AI and potential attack vectors and things like that. If you're not familiar with it, Software Bill of Materials is a technology and ecosystem agnostic method for describing software composition, provenance heritage, and more S-bombs as they're abbreviated are used as inputs for SCA tools,

22:14such as scanners, reveal vulnerabilities, and licenses have been gaining traction in global software regulations and frameworks. S-bombs are required by recent software security regulations, like the Secure Software Development Framework and the Cyber-Resilience Act. 770 was accepted in April last year. I won't dive too much further into all the specifics of it of the PEP, but it's well written and definitely something you might want to look into. Again, I talk about it with Seth on the show and so I'll add some links. Brett's blog post is titled What's Missing to Have Reproducible Builds on Pipei. And this is from his intro. One thing related to having a secure supply chain, we lack is a defined way to perform reproducible builds. The reason I like the idea of making reproducible builds work is that I think it can be done in such a way as to not require any work on the part of the producer of a distribution, which is a technical term for estus or wheels. The people who upload stuff to

23:17Pipei and thus make reproducible builds very low friction for people to opt into supporting. And this is part of what the 770 thing gets into a lot is that there are phantom dependencies in a lot of the things that you get from Pipei. You may look simple that it's just adding, say, the pillow library, but like, well, what is all inside of that and how much of it, like you were mentioning before, talking about rust being involved in Python. There's so many different languages that are used. It's something to think about. Python packages are particularly affected by the phantom dependency problem. Seth has a good talk on that, I'll include a link for that. From the Pepegan software components that aren't written in Python are included in Python packages. And that's for a lot of different reasons. We talk about it in data science packages, things like rust, C, C++, 4T and JavaScript and others. We just talked about Polars a second ago that's written in rust. The Python wheel format is preferred by users due to the ease of installation. No code is executed during the installation step. Only extracting the archive and the

24:23Python wheel format requires bundling shared compiled libraries without a method to encode metadata about these libraries. So again, if you look at something like the Pile library, there are maybe 15 phantom dependencies inside there. So going back to Brett's piece, why should you care? In terms of secure supply chain reproducible builds can let independent third parties verify that the bits and the distribution match what's expected based on the source code the distribution was made from. That lets you potentially detect if anyone tampered with the code during the build process. So the solution for wheels is what they're looking at with pep 770 and it added that support to record the software build of materials and sboms can be used to record the build tools used to create a distribution. S.Dis don't have a similar mechanism. He goes into a bit about how that could work with the information stored in the build system table if you're using the pie project.tomel file.

25:25This isn't implemented and would mean work for the people who maintain PIP. He dives into it a little bit further across the article, but his last paragraph digs into surfacing reproducibility on pipi, assuming all of this comes to pass and we record where the source code is, that went into a distribution and the software used to make the distribution. How do we make it useful to people? Does every person who cares about having a secure supply chain have to rebuild everything they use themselves? Is there some way for even people who don't care about the stuff to benefit? So these are really hard problems that he's looking at. I'm glad that Brett and Seth are both looking at this across the board and I feel like reproducibility and security in general are steadily moving forward, but it requires a lot of effort and sponsorship, things like the security development residence program, which has luckily been sponsored last several years, but also

26:25communication across these different boards. So there's a bunch of links in these articles. Again, I'll include some links to talks on this, but I feel like five years ago or so when people would mention something like an S-bomb, a lot of people were like, sure, I'd like, oh, that's not of interest for me. One thing that I discussed with Seth is that at Picon this year, they had a security track for a single day and it was standing room only. So that might show that there is a lot more interest in security and maybe what's happening with all this stuff. So thanks again, Brett, for your work. Yep. There's nothing like getting your house broken into for making you want to buy some new locks. So what exactly? Yeah. It's time to shine a spotlight on another Real Python video course. Integrating large local language models into your Python projects with Olamah is a great way to improve privacy, reduce costs and build offline, capable AI-powered apps.

27:29Olamah is an open source platform that makes it straightforward to run modern LLMs locally on your machine. This video course is titled How to Get Started with Olamah. It's based on a tutorial by Leidan Esposoramos and in the video course, your instructor is Ariane D. Through the video course, you'll integrate local LLMs into your Python projects using the Olamah platform and its Python SDK. First, you'll set up Olamah and pull a couple of LLMs. Then you'll learn how to use chat and text generation from your Python code. These skills will enable you to build AI-powered apps that run locally, ensure better privacy and reduce costs. Real Python video courses are broken into easily consumable sections and were needed include code examples for the technique shown. All lessons have a transcript including closed captions and like most of the recent courses on Real Python, their exercises woven through your path along the course to test your knowledge. Check out the video course you could find a link in the show

28:34notes or you can find it using the search tool on realpython.com. I have one other little thing I want to mention here is a piece by Peyton Green and it's regard to the Astral Acquisition of PyOpenAI. The title is The Python Community's institutional response to the Astral Acquisition has begun, which is an interesting title but it hovers around Python Build standalone, which is a project that creates portable self-contained C Python distributions, Python binaries that work without needing system Python, system libraries or any external dependencies. The worry is what happens now if Astral's new parent OpenAI changes course or priorities. There's a quote from Brett, I'm working on it and have been since October. It's been on pause waiting for Astral to upstream their patches after I gave them an initial review at the end of January. I have a pep that I'm about to go public with. I don't know if that's happened off the

29:35look for that. Once that's done, I'm pivoting back to working on pre-built relocatable builds for C Python that will come from Python.org. There's a GitHub repository that he links to Python, pre-built C Python that already exists and the article can deduce on with more details of what's happening and where the conversation is taking place. All right. Speaking of Django. Yeah, like I said, I've got a bit of a theme going here. Although this is Django specific, it also is kind of generic. You'll understand in a second. Every year, JetRain sponsors the State of Django Survey, which is similar to their State of Python Survey, but Django specific. The results from 2026 have just come out and Will Vincent Django, Coder, Extrord and Air and Resident Advocate at JetRain has written up a summary. There's too much here to go into all of it, but there are a couple of trends that I found interesting. The survey is smaller than its Python cousin, but it still has 3,500 respondents from over 40 different countries. And a bunch of this,

30:38although it's Django, it's kind of web framework and some of the patterns, for example, the AI stuff, which we're going to spend a little time talking about, it probably is representative of things far deeper than Django. The first bit that kind of stuck out to me was that 72% of respondents use server rendered templates. 53% use Django for API-only apps, and 46 use it for a JavaScript front-end like reactor angular. Some quick math tells you that there's overlap in that data. For example, someone like myself used to check all three of these boxes. Now with HTMLX, I mostly eliminated the JavaScript front-end approach, but I'll come back to that in a second. This is kind of interesting because they really are sort of three distinct approaches, and I find it how this ebbsm flows amongst the community. I don't have the data handy, but I'm sure a few years ago when React was definitely the answer to the be-all and end-all, I think some of the server rendered stuff might have been scoring lower, but it's had a bit of

31:42a resurgence, and I'll dig into that a bit more later. It's the one that I always find more natural, so I think that's why I find it interesting. Anyhow, 2026 being 2026, there are some AI questions in the survey. 53% of developers use AI tools every day. That number seems both higher and lower than I expected somehow. Obviously can't be both. Of those that do use AI over half of them let AI generate code, but review it and apply the changes themselves. About a quarter use AI to anonymously complete multi-step processes. Of the AI workflows, Devs are all over the place. Nobody is winning about a third each for Claude and Chat GPT with co-pilot following behind at 23%. 60% of respondents are using a web browser to interact with LLMs while 13% use local models. When learning, Django's official site is still the number one resource with 67% of people using it,

32:45but AI has come on strong with just over half using AI to help learn Django, which has surged ahead of other things like YouTube and other resources that used to be the second place. Switching topics, 57% of Devs use type hints with their Django code, which is interesting as it's something Django doesn't really take advantage of. Then another 26% claim they are planning to. So I'm a lonely, lonely voice. Of those using type hints, 40% are using the type checker built into their IDE. That's a big number. Although we've got things like my pyrof and pyrite, they share the spread, but their sum total is spread all over the place. So I think really what it comes down to is maybe I'm reading too much between the lines, but I think a lot of the type hinting really comes down to I would like to auto complete please. I'm wondering about that. And maybe also a lot of the API driven stuff, possibly also, I don't know. Yeah, it could be. Yeah. Since Django is a web framework, there are lots of

33:48kinds of projects that get built from APIs to single page applications to more traditional web 1.0, click on a page, show a page kinds of sites. The dynamic on the front end has changed sharply, though. In just five years, jQuery has dropped 15 percentage points. It used to be equal to react, but now it's way down in third place. What has taken its place is HTMLX, which is used by 34% of respondents. That's only four points behind react. That's insane, because this library is still fairly new. If you're not familiar with it, HTMLX is a JavaScript library that allows you to dynamically replace part of your HTML at a time through a call to the server. So this allows you to use web 1.0 style coding where you use a get to fetch a page, but now you can also fetch part of a page and replace some content. This makes features like searches you type fairly easy, you just go up and get the search results, and you don't have to pass JSON back and forth and re-render in the browser and all that kind of good stuff. I'm a big fan of HTMLX, and since Django favors a server-side

34:53template rendering, it's a really good fit for the framework. I'm surprised it's gained so quickly, but I'm not surprised that it's becoming popular. It's always interesting to see who's doing what out there, and I love this kind of data. So it was an interesting little read, and you can dig in some more if you like, if you visit the URLs. I was just going to chime in on the HTMLX thing. It's the one thing that I do see across the social media, the people that I follow, it's like the one that I see commented on the most. Again, I mostly follow Python people and Django people, so I'm not necessarily looking from like a JavaScript purely side. There is a move. I don't know whether it'll be successful, but there is a move to make the concepts part of the protocol. So there's a possibility that in the future HTMLX will not need to exist. It will become part of HTTP and how browsers work. So just the whole concept of being able to do these actions on snippets is basically a logical

35:54extension to how hypermedia works, and that's the whole argument for HTMLX. And there are people who are now trying to get the committees on board to do this. I don't know whether I don't have no idea how hard that is, but it would be interesting, because if you did it, basically this kind of stuff would then just be built into the browser. I don't follow browser stuff a ton, but like HTML5, right? How long ago is that? And then are there other revisions that we, I have not paid a sentence to, is there 5.1, 5.2? You don't want it to move quickly. He really don't. And yeah, it's, there are little things that happen along the way. Yeah, because it's when you go to do something more complicated and find like, oh, this version of this browser doesn't support that yet, right? So some of these things do sort of slow down, but it's a fairly stable thing, right? Like the majority of what folks do is there. Yeah, HTML5 and CSS, what, three, or whatever, have been kind of

36:55the standards for most web stuff for a long time. It's interesting time across all the stuff with web assembly. Just people are doing more and more interesting stuff with it. I keep seeing more and more stuff happening inside of browsers, which I think is, I think good news in a lot of ways. Yeah, that it's the universal platform, right? So for better or for worse. And honestly, I think it's for worse, but this is where we are. It dance with who bronias. So all right. The other thing is just like, I wonder about the AI usage. Is it a skewed thing? At all, based upon who fills in surveys or who's using Django? Or is this just like kind of what's happening across the board? Hard to know. And it wasn't detailed enough, like the amount of degree, right? So you're only talking about, I think it was 23% who are actually letting it go crazy.

38:01The autonomously completing things here. And so the 50 odd percent that on top of it are using it, that might be for snippets. The other thing, I don't like, I'm not playing with this stuff yet myself, but honestly HTML is a, I think that's probably a good use for it, right? There's a lot of boiler plate in HTML. And if you do, it's a type angle brackets. And you can't really get it suddenly wrong. You loaded in the browser, you look at it, it's either working or it's not working, right? So it's not, I think if I dip my toe into this particular lake, then I think HTML and CSS would probably be the places I would start. And I'd be more comfortable with. I'm less worried with generated code. Yes. And I'm less worried about how pretty it is. Because I can, you know, I'm less worried about regenerating it and that regeneration accidentally introducing a bug. Because again, you throw the visualization up and it either worked or it didn't work.

39:04Yeah. And there's probably some subtleties there I'm over simplifying, but if I were going to play, this would be the place that I think I would play. And in fact, that's one of the reasons I haven't had a strong need for it is because most of the time when I have this stuff, I've got existing projects that do it. So I'm not generating any of this by hand. I'm copying pasting. So I don't, yeah, you got a lot of template. I've got templates, right? So I so oftentimes I don't, there isn't a huge benefit to me for something to generate it from scratch because I've got it 95% of it. I just copy and paste things in and I'm done, right? So this is part of why I'm not haven't gotten too far down this path. So yeah, I think Django users are, you know, unique as far as Python users too, because again, they're addressing the web. And so they're, these are people that are coming across from multiple languages. And again, if you're going to be able to let your AI friend help with the boilerplate kind of stuff, then that makes sense because that was potentially,

40:06like you said, painful. It's if you template it away. Yeah. Yeah, there's a lot of xPHP people back in the day, right? Yeah. All right. Well, that takes us into projects this week. I have a rule short one. It's kind of a quick response. Somebody had put a comment on one of our short form videos that are on social media. Thanks again, shout out to Tapan for making those. You may remember I recently talked about the registry pattern being a potential replacement for long if LIF else chains. And someone pointed out or posted a comment, I think fairly snarkily, anything to avoid using the match date meant shaking my head. And I agree, the match date meant is possibly a better solution. And I look at using it in my code all the time. Again, I come from a world, you know, when I got really back into coding, I was in SQL. And so I was familiar with using that sort of stuff there. And was a little confused by like some tutorials where people dove deep

41:10into if LF and so forth. But it really depends on what you're trying to accomplish. And in this case, you know, what logic is embedded in that. And I think that's why the registry pattern makes more sense, depending on them. Again, if you're sending results to like functions and other things like that, not just simply doing, you know, numerical comparisons and things like that. So, and, you know, also the ability of making things extensible and adding new paths and stuff like that. So as a quick answer to this, I thought this project was well timed. Caviet, Semi-i may have been involved with this particular project. It's called Matchify. It's from Frank Hoffman, who goes by 15R10NK, which I'm guessing might spell something, I'm not good at translating license plates either. Matchify automatically converts eligible if LF else chains into Python 310 plus match statements. So while preserving runtime behavior and source formatting, again, you harps on the idea of preserving the formatting and the code structure

42:14supports multiple different pattern types. Again, literal type comparisons like x equals equals one and x equals equals value. Identity checks, x is none, x is true, is instance checks, class patterns with attributes, sequence patterns, nested sequences, sequence attributes, and so forth. So if you are seeing that type of stuff in code and you think that it might be useful to convert it into a match statement, this is a nice kind of quick project and tool that could help you with converting them into the more modern and potentially, depending what you're trying to do with it, the whole match statement is a very elaborate area that has been, if you listen to us talk about it on the different Python releases, there's a lot more going on there than the simple if LF potentially in both the registry solution or the match statement solution. All right, you got a whole

43:15bunch of stuff tied to your next project here. Yeah, it's a little bit of a windy road. My project this week has a prerequisite and since it's a bit of a niche, I'm going to start with the prerequisite first. That's called pint and it's by Hernán Greco. What pint does is define units that you can associate with your numbers. So if you're doing code that represents meters or degrees Celsius or leaders, I'm sure there are other examples, but I'm Canadian and I'm in denial. This library gives you a way to associate that concept with your numbers. This ensures that you don't accidentally add a variable for temperature to a variable for distance. It separates those things out and causes compilers. It goes further than type checking though. It also does conversion. So if you have something in Celsius and you want to convert it to another scale like Kelvin, you can then use the two method passing in the Kelvin designator and get out your newly converted value. I actually use pint in one of my real Python courses on astronomy, demonstrating

44:18how long it would take to get to Saturn using a sling shot maneuver around Jupiter. We'll link to it in the show notes in case you're curious. And for those who like our astronomy courses, another one is in progress and should be coming out soon. Notice that I could not use pint to describe the idea of soon as soon as unitless and vague. And that's intentional. Yeah. As I said, pint is the prerequisite. My actual project this week is Pydantic Pint by Tyler Hughes. Seeing as I've already described pint, there isn't much to explain here. What Tyler's library does is act as a bridge to Pydantic, allowing you to use pint unit mechanisms within Pydantic's verification and serialization tools. Seeing as Pydantic is commonly used in the scientific space and using units is good practice in that kind of code. This is the perfect little marriage. I think it's great that this might make pint available to a wider audience. And since Pydantic is all about verification, it's a very natural fit. Good job, Tyler. All right, Christopher. Thanks again for bringing all these. Well, this mountain

45:20of news in all these topics and projects this week. If you aren't checking out PyCoters, this is where all this information typically comes from. So I'll include another link there along with a way if you want to submit stories, you can do that there. So thanks again, Christopher. Something something next time. All right, talk to you soon. Thanks again to six feet up. The Python and AI experts you can call for the hardest software problems. From scaling applications to simplifying data complexity and unlocking AI outcomes, they help you move forward faster. See what's possible at six feet up.com. I want to say thanks to Christopher Trudeau for coming on the show again this week. And I want to thank you for listening. If you like the episode, a great way to help us grow our audience is to share it with other Python users who you think might enjoy it. You can also leave a

46:20rating or review on your podcast platform of choice. If you or your company are interested in sponsoring the podcast, you can find all the information at realpytthon.com slash advertise. You can find show notes with links to the topics we spoke about inside your podcast player or a real python.com slash podcast. And while you're there, you can leave us a question or a topic idea. I've been your host Christopher Bailey and I look forward to talking to you soon.