Python Bytes - #489 Or JSON?

Episode Date: July 21, 2026

Topics covered in this episode: django-orjson Best Django Redis configuration for speed and size Linus Torvalds puts the foot down against Anti-AI Kernel Maintainers Django Steering Council backs the Triptych Project Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Consulting from Six Feet Up Connect with the hosts Michael: Mastodon / BlueSky / X / LinkedIn Calvin: Mastodon / BlueSky / X / LinkedIn Show: Mastodon / BlueSky / X Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too. Michael #1: django-orjson Adam Johnson dropped django-orjson - drop-in replacements for the Django and DRF pieces that touch JSON, swapping stdlib json for orjson, the Rust-based library. Headline numbers: 10x faster serialization, 2x faster deserialization. The interesting question is why this needs to be a package at all. pip install orjson is the easy part. Adam's actual pitch: adopting it "isn't easy, especially when your framework uses json in many different parts." Django scatters JSON across JsonResponse, the test client and test case classes, the json_script template tag, and more. There's no single hook to grab, so you get a library that catches them all. Adam is refreshingly honest about the scale of the win. His words: "While database queries tend to dominate the typical Django application's runtime, the time spent in serialization and deserialization can still be significant." He calls it "a nearly free performance win" - not "this will 10x your app." That's a claim about cost, not magnitude, and it's worth keeping those straight. Worth flagging what the post doesn't cover: caveats. There are none in the article, but orjson has real ones. Django and Flask both render datetimes as RFC 822 HTTP-date (Wed, 15 Jul 2026 12:00:00 GMT); orjson does ISO 8601. It can't do ensure_ascii, it rejects NaN and Infinity (which stdlib happily emits), and it raises on Decimal. If you've got a JS client parsing dates, that's a wire-format change. Who should actually take this? If you're a DRF shop shoveling JSON all day, yes - it's cheap and it's real. If your app mostly renders HTML templates, you're optimizing a slice of runtime that's already near zero. The problem Adam's package solves doesn't exist in Flask or Quart. They already centralize every JSON operation - jsonify, request.get_json(), the test client, the |tojson filter - behind one provider object at app.json. So there's no library to install. It's about ten lines: import orjson from quart.json.provider import JSONProvider # or flask.json.provider class OrjsonProvider(JSONProvider): def dumps(self, obj, **kwargs) -> str: return orjson.dumps(obj).decode() # provider must return str def loads(self, s, **kwargs): return orjson.loads(s) app.json = OrjsonProvider(app) The numbers on talkpython.fm Evaluated it, measured it, and skipped it. The biggest JSON payload we serve is our MCP server returning a cached episode transcript, about 139 KB. Swapping the provider saves 0.119 milliseconds per request. That total response takes 1.1 ms We got 4.1x, not 10x - and the reason is the good lesson. Payload shape decides your speedup. The 10x is for structure-heavy data, lots of small keys where stdlib burns time in Python-level dispatch per item. Our hot payload is one giant transcript string, so the work is escaping and memcpy Calvin #2: Best Django Redis configuration for speed and size Peter Bengtsson revisits a classic: his 2017 "Fastest Redis configuration for Django" benchmark now has a 2026 update posted this week. The 2017 post pitted django-redis serializers (json, ujson, msgpack, pickle) and compressors (zlib, lzma) against each other; conclusion was msgpack + zlib as the sweet spot - avoid the json serializer, it's fat and slow. The 2026 update narrows focus to just compressors: default (no compression), zlib, lzma, and newcomer zstd. New results: lzma compresses best but is slowest; zstd is the fastest compressor on Ubuntu; differences between them are very small. Big takeaway across both: compression buys you a lot of space (2–3.5x smaller) for very little speed cost - worth it for Redis where memory is the constraint. Caveat from the author: results depend heavily on your data - his test stores short strings of numbers, so benchmark your own workload. Michael #3: Linus Torvalds puts the foot down against Anti-AI Kernel Maintainers Write up on Ars. Really good coverage by Maximillian: Time to wake up (for some) Torvalds said that “Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away.” I agree with Max, putting your head in the sand and waiting for AI to go away will likely mean you won’t be working professionally in software development in the coming years. The statement came amid a lengthy thread arguing about the use of Sashiko, an “agentic Linux kernel code review system” that its creators claim can, in tests, independently find 53.6 percent of the bugs that would end up being fixed by human coders in later commits. “We’re not forcing anybody to use [LLM tools], but I will very loudly ignore people who try to argue against other people from using it,” Torvalds said. “Anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time,” Torvalds wrote. Calvin #4: Django Steering Council backs the Triptych Project Django Steering Council issued a Letter of Collaboration backing Carson Gross & Alex Petros's funding bid for the Triptych Project - three proposals to make HTML more expressive natively, in every browser. The three additions: PUT/PATCH/DELETE methods for forms, button actions (buttons that fire HTTP requests without a wrapping form), and partial page replacement. Distills the core ideas from HTMX/Unpoly/Turbo into the HTML standard itself - no JS, no library, nothing to ship or maintain. Current focus is button actions (WHATWG #12330): <button action=/logout method=POST>Logout</button> instead of wrapping a button in a form. Relevant to Django directly - think the admin submit row and disguised delete links; Django 6.0's template partials were already inspired by these patterns. How to help: companies can send non-binding letters of support on letterhead; individuals can read the proposals and weigh in on the WHATWG issues. Extras Calvin: DOOMQL - A playable first-person shooter whose framebuffer is a SQL query. Michael: Granian 2.7.9 fixes WSGI threadpool scheduler starvation/underscaling Welcome Calvin post Joke: Solving all bugs

Hello and welcome to Python Bites, where we deliver Python news and headlines directly to your earbuds. This is episode 489 recorded July 21st, 2026. I'm Calvin Hendricks Parker. And I'm Michael Kennedy. Hey, Michael, welcome. Good to see you. We want to make sure you all recognize our sponsorships of the show. So thanks to Michael and the courses over at Talk Python, go check those out.

If you head over and he's got tons of new stuff he's been adding in there. And I hear there's more on the way. And then check out the fine folks over at Six Feet Up. So I'm co-founder and CTO of Six Feet Up. And we do some amazing consulting to solve hard problems. We love using Python. We've been doing this for 27 years as part of that agency and I love it. If you want to connect with Michael and I between the shows, you can find us on all the socials.

We're on Macedon, Blue Sky, X, LinkedIn. And then the show has also got links in the show notes for the shows, Massadon, Blue Sky, and X. If you want to watch live, you can always catch us generally Tuesday, mornings by time, very early mornings for Michael's time. So 7 a.m. Pacific on Pythonbytes.fm. slash live to be part of the audience. Sometimes we'll get questions in there and we'll pop them onto the show and you can get them answered right away. Kind of real-time feedback to the episode. Older versions are also available there if you want to watch the live stream and see our shiny faces as we go through and talk about the news of the day. Speaking of the news, Michael, I think you're going to kick it off with the first article today. I am, but let me do a little follow-up to what you just said, actually,

which is not normally something that deserves follow-up. But, you know, last time, a couple times ago, I talked about Hermes. Yeah. What a cool little thing. I've been getting more and more done with it. One of the things I did over the weekend was I've set up an automation such that Hermes can use the website to manage the YouTube channel. And then I set up a nightly job.

So every night, as much credits as I can get for API interactions from YouTube, it will automatically go back and update the back catalog, like 10 or 20 shows at a time. And so it's on this cool, cool thing. So the live back catalog YouTube stuff is getting better and better because it happens as I sleep like it should. I love that, getting the richer show notes, et cetera, put onto there. I like the fact that we can use this to make the world a better place. Yeah, exactly. Like it's just everybody gets, you know, links and stuff in there in the videos if they watch it. Cool. And how do you get it? Well, is it a JSON API or something else? We don't know. So I want to talk about Jingo or JSON. Is it ORJSON or or JSON? It's probably ORJson. Hi, OR. It's my guess. Let's go with, let's go with OR. I agree because or JSON is weird. Or Jason. Or Jason? I don't know. Yeah, so I want to talk about this project from Adam Johnson.

So we have a couple of Django topics. This one is a Jango topic, but it also goes more broadly. So there's kind of a multi-level thing going on here, not the marketing badness, but just multiple uses. So this is a project that Adam created so that you can change Jango's response model. So apparently the way Jango uses JSON or generates JSON responses happens in a bunch of different ways. So it says there's a library called ORJson. And somewhere it says, yeah, here we go. It says compared to Python's built-in JSON, it boasts 10x faster serialization and two-time

decerealization. And I believe it is a little bit more forgiving of date times and stuff. It has like default conversions, whereas if you've ever tried to serialize certain things, it's like, nope. Sounds like a win. I know it does. It couldn't possibly figure out a way to represent time. What a weird.

This is a rare concept we don't normally encounter. So this handles some of those things as well. So there are a couple reasons that you might play with it. But it is a little bit different. So be a bit careful. So the idea is that there's a bunch of different places, like such a great library, but adopting it isn't easy when your framework uses JSON in multiple different parts, different places.

So Adam introduces Django-O-R-J-Son, which provides a bunch of replacements and you just plug it in, right? So import j-sson response and you can return that directly, which is cool. There's test capabilities loaded up in a template and so on. After seeing the initial proposal, Django for J-G-O-R-J-S-on, Paolo, who was recently on Talk Python to talk about maintainer burden and AI, coming back to that at the end as well or later, decided to push for the addition of OR-J-J-S support in Chanko itself.

under a new feature called Plugable JSON serialization backend, which I think is pretty cool. I'm all for it. Yeah, it's nice, right? Like, why not make that an option? Yeah, totally. It's like saying, eh, that Pidantic thing, probably a flash in the pan. We don't need it really worry about that. Scott Huskin, did you get to try it out?

You've got a lot of data. Yes. And so I'm like, well, let me just, let me just try this. And one of the things that's really cool is with cloud code and other things. You can say, here is a proposal for how to do this for JSON. on how would I do this for Flask and Court where I'm running my apps? And can you tell me the areas where it might be a benefit or not so much a benefit? Not only did I get a little summary for how that might go.

It's like, and I set up some test performance runs. And it turns out that you get four times performance boost, not 10 times performance boost. Yeah, that's not bad. No, it's not too bad. But I put that actually the reason, like a little bit of that analysis into, the show notes. And it turns out that if you have large JSON documents with a few fields, then it doesn't give you a big boost. If you have a very fine-grained JSON document with lots of small fields, apparently that's where this performance starts to pay off. And I happen to have,

like, big chunky JSON, I guess is what I got. I don't know. It's got things like 100K of transcripts in a response, you know, not. And it's structured as a giant piece of text. It's not necessarily like, subtitle, text, second, and so on. So that's interesting. And it said, look, it can help your MCP server, but the traffic on the MCP server is not that high. You swap it out. You'd probably save 0.119 milliseconds of request.

And for a response that takes 1.1 milliseconds, you really wouldn't mess with it? I decided to know, which I thought was kind of interesting in the first place. Like, you try it out. You're like, oh, cool idea. Just not for my use case. Most of my stuff is RSS. It's HTML.

It's like not that much JSON. But I do think for the right use case, it would be really powerful. Are there any compatibility caveats that people need to be aware of here? There are some minor ones about like how it handles certain things that either can't be serialized or if you don't specify how to serialize them. Like for example, date times and stuff like that. Which everyone loves dealing with date times. That's our favorite. Yeah.

Could we put some time zones in there for? please. Yeah, yes. All right, over to you. Yeah, very cool. Well, mine's also performance related. And I think it'll dovetail nicely into what you just mentioned here. Speaking of performance and Jason and evaluations, I think one of the things that has been nice about using these AI agents, like you just mentioned, is you can put it on a mission to go try some hypotheses and some theories and et cetera. This is a article from Peter Mengson, who revits is a one from 2017. So this is actually the original performance article he did around fastest Redis configurations for Django. So a lot of folks just use the default out of the box configuration for Redis. Kind of a standard thing these days to use for any kind of cacheing that you might use inside of your application. But it has tunable capabilities. Since you can adjust the format of the serializer, so whether it uses like JSON, UJSON, message pack, pickle. You can also adjust the compressors it may use. So whether it's using Zlib, LZMA or Z standards is a new one that's coming up.

But it didn't exist when he did this 2017. So he just actually, this is kind of all pre-AI as well. He did it the old school Hardway, which is specified a bunch of different configuration combinations run through a framework and try and test and see what the performance boost may be based on the kind of data he threw at it. So if you look down here, actually it's kind of fun, very asky art result graphs here. I'm here for the ASCII art. I'm here for it.

So JSON's the slowest. Like on the here, the shorter or better, so best averages, like for averages, medians and size of data stored. You can see here Jason not so great. Actually, I wonder if he's in his updated version, he did not use OR Jason. I wonder how that would affect this. But basically message pack as a message format is going to be one of the fastest ones he found for this specific application.

And then if we look over here. I would, I would, I bet that message pack is faster than OR JSON. Probably still. So I bet that sets a lower bound, you know. Yeah. So updating here to look at three specific compressors, Z-L-ZM-A and Z-Standard, the LZMA is still slow.

While it compresses well, it's slower from a performance standpoint. The default actually not doing too bad here except for size of data stored, which if you're saving larger size. items, there was a different performance difference, which actually leads to why coding agents like Claude Code and Pi and these orchestrators allow you to do this kind of experimentation with very low risk in overhead, because ultimately the indifference matters on the kind of data. Like you just mentioned, the kind of data you're storing in these various serializers are going to determine a lot of the performance characteristics. So I hate saying it depends, but your mileage will

vary based on what you're throwing into Redis and how you're accessing it. So it's always nice to be able to set up some kind of performance harness or benchmark where you can actually test these yourself and see how you get the most mileage out of these tools. And based on what I saw here, it seems like there's quite a bit of room for improvement for eking out more performance. So as we typically do, I like starting off with the defaults first and only optimize when I see a problem. But these are great ways to take a look at the different message format serializers.

for Django Redis and then the various compression formats that are out there for it. So a nice methodology, a nice little write-up showing some of the results, and showing that it's actually not too hard for you to go implement this yourself. A great way to get some squeeze more performance out to Jango with your Redis, which is already fast. I love it. But here you can make faster. Yeah, it's super fast. I 100% endorse here.

Let's try it with the built-in stuff and then see because, like in my example, I could have taken on one more dependency and thing I have to update. but it's like, do you really need a tenth of a millisecond? No, it makes zero difference to me, honestly. We'll talk about simplicity in my next one I bring up after yours here. Okay. Yeah. I do have a little bit of real-time follow-up sort of.

I just chose to throw this out by the way. Oh, nice. Just a quick shout out to Valke. When I hear stuff on Redis, I'm like, don't forget the Valci. You're familiar with this, yes? Oh, yeah. We've, when there was a whole hadoo around the licensing with Redis, we've switched over to Valki for many of our projects.

It's been great. Cool. Yeah, yeah, that's awesome. Yeah, so basically Valki is like the more open source, a fork of Redis, and it's like API compatible, of my understanding. But it's, you know, 26,000 stars. It's like a half a flask, something like that level of popularity.

Yeah. Well, it's tricky because then the Redis folks went back on the whole Bizzle license back into Open, right? Yeah, exactly. It gets a little funky. But let's talk about something at, not even close to as controversial as that licensing stuff. Let's talk about Linus Torvalds puts his foot down

against anti-AI kernel maintainers. There's a lot of double negatives here. So Linus says- I had a hard time parsing that one. I know. OK, so Linus says I'm not having it that there are people saying we're unwilling to use AI in any way against the Linux kernel.

And it's pretty interesting. I'm going to link to the actual original thing here. I got some quotes that I pulled out. So this all has to do with this thing called Shishanko. And what Shashenko is, I have no, I don't like work on the Linux kernel. So it's not a thing I'm super familiar with, just to be clear. But Shashenko is an AI PR review tool. I guess it's built into GitHub or something like that for automation, you know, like GitHub actions are the equivalent thereof. And it will review inbound PRs. for bugs, for correctness, performance, that kind of stuff.

Yeah. And I think there are some people that are like, no, heck no, I want nothing to do with this thing. So it's not necessarily just cutting AI complete loose, completely loose and saying, hey, here's the spec of the kernel. Right. Make it better. See you next week. You know, it's way more subtle and less intense.

Yeah, it's a human augmentation. It's making us better what we do. Exactly. So I'll just pull out a couple of pieces here. I think this is, this is a little noteworthy. My understanding is he was fairly against this kind of stuff and then kind of played with it more. It's like, you know, and actually I'm not against it anymore.

And let me just put this out there. Like, he acknowledges it. I acknowledge it. I'm sure a lot of people will that there are downsides to AI in lots of ways, but there are also upsides, right? And so he says Linux is not one of those anti-AI projects. You know, think Zig or something like that, right? And if somebody has issues with that,

they can do the open source thing and fork it, or just walk away. It's like, you know what? Okay. I mean, what do you expect from him, right? That's true. What do you expect? AI is a tool, just like other tools we use, and it's clearly a useful one.

And it may not have been that clearly, even just a year ago, but that's no longer the question. I think that's an important thing, right? Like, people have formed opinions, especially people who have formed the opinions, like, I don't want to touch this as this junk. It's like, why would you come back to a thing that's junk? You know what I mean? Right. Why would you go build a house with hand tools when you've got power tools available?

Yes, exactly. Well, because nail guns are dangerous. And we had him since the 40s. I do want to point out that there's this really good, there's this good, I've mentioned this guy before in the show. I'm not sure. Are you familiar with this Maximilian Schwarzmule, this German guy, he's really good talking about like sort of trends in software development. And one of the things he says here is he, he, in response to talking about this, said it is time to wake up for some. it less more bluntly saying look if in a couple years if you're doing professional software development you're going to have to be using these tools yeah and you need to get good at them regardless of how you feel about them you know what i mean it's fine for hobby stuff not to do it i that's like a

12 minute that's a summary of a 12 minute video but it's really well well done so i recommend people check it out and he's just an interesting guy okay back to what line is the same yes it can be somewhat painful tool for maintainer workloads and so on and also because it just keeps finding embarrassing bugs, which is annoying, but amazing. I think that this embarrassing bugs bit is actually transient. We've got 10, 20, however long the projects have been around for, years of tech debt. Tons. Yeah, and we send this tool on. It's like running a lender. Like, do you guys have a linter? No. Oh, you should try black or rough or something. And then it's like, there's 2,000 errors. We can't fix 2,000 errors. Like, we just don't run it anymore. You know what I mean?

But projects that start adopting lenders don't always have 2,000. warnings or issues right all right carrying on but the solution feels like nothing but when here like you want to linter that i wouldn't go without it right now period yeah 100 percent it's just it's kind of painful to deal with some of the fixes but you know you get through them and then it's pretty straightforward especially with dash dash fix and a lot of the modern ones okay so the solution here says linus is not to put your head in the sand and sing la la la can't hear you at the top of your voice it's to make sure the lm tools help maintainers instead to cause in them pain. We're not for, and here's the essence of this whole thing. We're not forcing anyone to use

it, but I will verily loudly ignore people who try to argue against other people using it. No, AI is not perfect. But blankety blank, anyone who points the problems, points to the problems that AI had better be looking in the mirror and point themselves at the same time because people make mistakes too. All right. Pretty certainly, I did not write this email post. Yeah. This feels very human. This is very much on brand. So I thought I put out there. I feel like it's a little bit seminal in terms of this. Ars Technica has a write-up as well, and it's gathered almost 200 comments. So that's worth checking out. Yeah. Yeah, I'm curious by folks, the folks who are in the Never AI camp are not using it even for completion. Do they never use an, and I mean, I held out on IDs for a long time because they

didn't feel like I needed the auto-complete, but like those days are long gone. Like this, things have gotten so fast and have helped me like streamline my workflow. where it's not standing in my way. And I feel like these tools will get into that point where it is just like wrapping an amazing exoskeleton around your capabilities and going for it and doing more and better. Yeah.

Yeah, yeah. I don't remember the numbers. I don't believe they're in here, but they might be in a fall. I mean, there's a conversation to be at here. You can see if you look at the thread. But I believe it's something like this Shoshanko thing is like 15% false positives,

but 85% like, yeah, these are actual bugs that you didn't have to find. I just told you their bugs here. Yeah. And these people have all written helper scripts to do these kinds of things. They can't be against this one. Yeah.

I mean, they can, but it doesn't make any sense. Yeah, I just, I feel like if you've got a tool that by the time you get to the PR, it has an 85% accuracy rate of finding and dealing with any of the issues, like, that's pretty good. Yeah. Plus, you're still expected to operate as a human in this case, like bringing the creativity, bringing the original thought,

just letting it take care of all the mundane, boring stuff. Like making sure you cross your T's and dotted your eyes in the code. Seems like all win. All one to me. 100%. Speaking of when, wouldn't it be awesome if HTML did better stuff? Like, they didn't stop building it when soon his JavaScript was invented in the 90s or whatever. Yeah.

So our third Django related news item for the day is that the Django steering council is backing the triptych project. So if you're not familiar with the Triptych project, it is a three proposals for the HTML standard to make things a little more native and expressive. So adding in, for example, put patch and delete methods to forms. We've all abused post far too long and added in things like slash delete to the end of our API URLs to accomplish things that really should just be using a specific vocabulary or verb from HTTP. language which is delete. So this gives us the ability to put those three extra actions the fact that button actions should be a thing. So buttons that just can fire HTTP requests without wrapping them in a form, how many times you've had a singleton button with form on top, form on the bottom, or worse like for example, if you're

not using a button but dressing up a link to look like a button, for example, like a logout, the log out button could potentially get triggered by some of the pre-fetched operations that are happening by some of the browsers or unfurling, et cetera. So you may get unexpectedly log out or unexpectedly delete something. Be careful when you make a button that says delete that is actually a link. Those buttons should be buttons. There was actually back in Internet lore. There was a really interesting thing.

I think at the early days of Wikipedia, that one of the delete buttons or one. Yes. Was actually just a H-Ref that went to a delete operator, but did it get and got indexed and delete? I think it was Wikipedia. I think it was Wikipedia. Yeah. So the idea is, yeah, let's resimplify, make things more semantically operational in the way that we should expect them to work.

The last thing, the last proposal is actually around partial page replacements. So if you are taking the ideas from basically HTMLX, unpoly, and turbo, and putting them into the HTML standard itself. So this means if the standard gets adopted and the browser start putting this into their your HTML parser and engine that's powering your web browser, less JavaScript and libraries can actually be shipped to get the same level of interactivity on the pages that we're doing right now today with things like HTMLX. I really like the HTMLX library.

I feel like it gives people a clean, clear way to do things in Django really fast and have like a single page web app like front end without having to rebuild all of your Django models in React on the front end. Like with a lot of the React patterns, you're building the same models twice, the same routers twice, the same application. Basically, they have to be built and maintained in two separate frameworks, where if you just had these capabilities built right into HTMLX or the browser, I mean, with the triptych project proposals for the HTML spec, or think about how clean and this is simple that the development could be, especially for, you know, testing out and running quick little one-off projects. They could be so much less dependencies, hopefully less maintenance going on in there. So I think that's really nice. The piece is relevant for Django.

Django is here to help shepherd in the better web and new technologies for it. So that's why they're backing the Triptych project specifically. But also, for example, the Django 6 introduced template parcels, which are inspired by these patterns. So Django's kind of already ready to have this work. So if you're using HTML, you get some benefit that Django helps you generate these parcels right out of the box, which is another one of the nice things about Django. It's kind of that batteries included. All the things just work.

If you want to help, there's links here to the Triptych project, which if you are familiar with the web hypertext community, the WhatWeji. I don't know how you pronounce that specifically. But this has basically taken over from the W3C for the HTML standards. And so they have submitted a proposal to this working group. which is basically the living HTML standard, which is where browser companies now build from and based off of. That's what they've put forth. This has been put forth by Carson Gross and Alex Petros.

So if you may recognize some of those names, one of them is the creator of HTMLX itself. And if we go into the Triptych project, you can see there's the three proposals here, plus a blog post I linked to, and some of the examples of why this is actually important, and some of the history around it. And if you want to get involved, I think that's actually the more relevant call to action here,

is they're looking for folks to send non-binding letters of support on company letterhead that they would be willing to support and sponsor these proposals and help weigh in on that issue. So there's a GitHub issue. That whole living HTML spec is actually maintained as a GitHub repository. Anyone can join. It's not an exclusive club of enterprises and corporations anymore, driving that living HTML spec is driven by the community itself. So if you get excited by this, go get involved.

Go check it out. I look forward to this being the future of browsers because we can now, especially for simple things, oh boy, would this be just nice to have this built in? Yeah, yeah. It kind of fills the role that jQuery used to, you know, and we thought past it because it's like, oh, no, we need to build this huge front end stuff. And sometimes you just need when I click this, that thing over there to change, but the rest of the page to stay.

I wanted this for like two decades. Like the fact of the button couldn't just fire an action. Like having that wiring, it just makes sense. I think this makes sense for getting things cleaned up and having less workarounds means that agentic coding tools can actually operate better because they'll have a better understanding of the semantics of this. They appreciate semantics where things are wired up and work as you expect them to. Yeah.

And if you like things like HTMLX and Datastar and those kinds of frameworks, this just brings it natively to the browsers closer. There's still layers to add on top of it, but less. I'm excited to see the Django community getting behind us. It's good. There's still innovation happening on a 25-year-old project. Incredible, right? Yeah, it is.

What do you got for extras today, Michael? I have a couple of things here. Two things and just a little bit of a follow-up to what I know your extra is going to be. But I'm going to wait. It's going to be a multi-staged extra, let's say. All right. I am a fan of the Grinian Web Framework, Powers, Pythonbyte's. Python, and many, many other things.

It's a Rust-based ACP server for Python, like ThinkG Unicorn, Uveicorn, that type of thing. And it's been around for quite a while. It's quite active. It's getting a lot of updates on it. More importantly, let's see, 101 this is Nazi. I need to learn work on my Rust. Go to the cargo lock. More importantly, it wraps this thing called Hyper.

And if you look at Hyper, that's like it's a web server out of the Rust world that has like 130,000 stars. So basically this is like a whiskey and Aski server that just kind of provides hyper to Python applications, right? Cool, cool. So what am I talking about? I've had Giovanni on the show and stuff before. But there's a pretty big update to it, even though it's just a point, 2.7.9. But it sounds like that bug. It sounds like, oh, whatever.

But, you know, I fixed a bug in the blocking threadpool schedule, causing starvation underscaling with whiskey and long-running requests. Like, so if you're using this, just bump it up. That's easy. Easy to do. You should. Easy to do. It sounds like it would make a big difference.

So definitely do that. The next one, I'm going to reshare my screen here. Okay. Do a live demo if I can find the stinking window. There we go. So I really enjoy. Doom. Doom was originally coded up and created on the Next Step OS and the next machine. And so I actually have two next machines on my desk that have Doom installed on them.

I have Doom installed my iPad. But now I can have Doom installed in the terminal. And instead of usually people are saying, does it run Doom? Like that's the joke that people say, can that piece of hardware run Doom? This is a little different. This is your doom running in SQL. So Doom QL. You can see here, select star from how. So if you're a fan of the game, that joke should land. But basically, the frame buffer is a SQL query. So if we actually come in over here and I'll run the demo, make run. This is Doom running in my frame buffer, but the frame buffer is running in SQLite.

So it uses the same standard what's had key combos. You can go and grab like powerups. There are monsters in here someplace. It is tricky. Yeah, it is tricky. It's a little trick. Oh, see, I'm getting like killed by. Oh, there's a monster right there.

It just is killing me as we go. This is running SQLite. You can actually tail the SQL queries and watch all the queries that are happening under the covers. If you had in their window open and ran the Make Inspect command. So definitely check that out. It is hilarious to see that we have got Doom running in SQL Lite. So not just on fancy hardware, on crazy databases. Now we can run.

How incredible. That is super, super neat. So that's what I had to go check it out. I don't know how I feel about it, but yeah, Doom. I used to play a lot of Doom when I was much, much younger. Same. I also have another real-time follow-up. How can you possibly play Doom?

One of my earliest jobs was working this place called Eye-Tracking, E-Y-E-Tracking, at iTracking.com in San Diego. And we did all this crazy type of research by, like, looking at what people would see and how their eyes would react as they were solving problems and so on. So we had these weird collaborations. And one of the collaborations was this guy, I don't remember, it was like a university or something, who did stuff with EEG, I think it was, not EKG, the brain bit, not the heart bit, with the wires.

And so somehow wanted to kind of understand the eye tracking side and the EEG side. What does this have to do with Doom? Well, he would play it by thinking with an EEG, no hands. And he would just think, and it would turn left, and they would think something else, and it would shoot a gun. But what was really weird was he wouldn't think turn left and it would turn left. He'd have to activate different parts of his brain. So he's like, bacon, bacon, they would start shooting.

You know what I mean? Because it couldn't just be the same part with motor skills. It'd have to be like a different part. Like an Xbox controller of the brain. Anyway, I thought people might find that amazing. That's really, really weird. Doom's got quite a bit of history with the computer world and computer science world too. Yes, exactly.

Exactly. All right, let's talk about jokes. I'm sure there's a bug in Doom. So I named this joke, solving all the bugs. Have you seen this? No, I've not. Have you looked at? Okay, good. I didn't peek. Good. So I want you to put yourself in the state of, I don't know, so apocalyptic future, whenever the matrix was set with Neo and Morpheus and all that. Okay. So how in this kind of world, how would you solve the bugs? Well, it says, no production is, I can't do it. Okay. No production. incident ever exists without Jira ticket. So what if Jira tickets are the issues all along? There is no Jira. There is no spoon. Everything is perfect. All right.

Oh boy. I ready to take the red pill. Yeah, let's take it. Thanks, Michael. There is no spoon. Yeah, you bet. That's amazing, especially your Keanu Reeves impression. Very spot on.

I tried. I tried. Yeah, thank you. Very spot. Well, thank you for joining us this week for Python Bites. all the news all the time and I'm looking forward to seeing y'all next week. We'll see you later.