#489: Or JSON?

Published Tue, Jul 21, 2026, recorded Tue, Jul 21, 2026

0:00

00:30:51

Play on YouTube

Watch the live stream replay

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:

Joke: Solving all bugs

Episode Transcript

Collapse transcript

WebVTT format On GitHub

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.

00:05 This is episode 489, recorded July 21st, 2026.

00:10 I'm Calvin Hendryx-Parker.

00:12 And I'm Michael Kennedy.

00:13 Hey, Michael. Welcome. Good to see you.

00:16 We want to make sure you all recognize our sponsorships of the show.

00:20 So thanks to Michael and the courses over at Talk Python.

00:23 Go check those out if you head over.

00:25 And he's got tons of new stuff he's been adding in there.

00:28 And I hear there's more on the way.

00:30 and then check out the fine folks over at Six Feet Up.

00:33 So I'm co-founder and CTO of Six Feet Up and we do some amazing consulting to solve hard problems.

00:39 We love using Python.

00:40 I've been doing this for 27 years as part of that agency and I love it.

00:44 If you wanna connect with Michael and I between the shows,

00:48 you can find us on all the socials.

00:49 We're on Mastodon, Bluesky, X, LinkedIn.

00:52 And then the show has also got links in the show notes

00:55 for the shows, Mastodon, Bluesky, and X.

00:58 If you want to watch live, you can always catch us generally Tuesday mornings by time,

01:03 very early mornings for Michael's time.

01:06 So 7 a.m. Pacific on pythonbytes.fm/live to be part of the audience.

01:11 Sometimes we'll get questions in there and we'll pop them onto the show and you can get

01:15 them answered right away.

01:17 Kind of real time feedback to the episode.

01:20 Older versions are also available there if you want to watch the live stream and see our

01:23 shiny faces as we go through and talk about the news of the day.

01:27 Speaking of the news, Michael, I think you're going to kick it off with the first article today.

01:32 I am, but let me do a little follow-up to what you just said, actually,

01:35 which is not normally something that deserves follow-up.

01:38 But, you know, last time, a couple times ago, I talked about Hermes.

01:41 Yeah.

01:42 What a cool little thing.

01:43 I've been getting more and more done with it.

01:45 One of the things I did over the weekend was I've set up an automation

01:50 such that Hermes can use the website to manage the YouTube channel.

01:55 And then I set up a nightly job.

01:56 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.

02:06 And so it's on this cool, cool thing.

02:10 So the live back catalog YouTube stuff is getting better and better because it happens as I sleep like it should.

02:17 I love that.

02:18 Getting the richer show notes, etc. put onto there.

02:21 I like the fact we can use this to make the world a better place.

02:25 Yeah, exactly.

02:25 Like it's just everybody gets, you know, links and stuff in there in the videos if they watch it.

02:31 And how do you get it?

02:33 Well, is it a JSON API or something else?

02:36 We don't know.

02:36 So I want to talk about Django or JSON.

02:40 Is it ORJSON or ORJSON?

02:42 It's probably ORJSON.

02:43 Hi, OR is my guess.

02:44 Let's go with OR.

02:46 I agree because ORJSON is weird.

02:48 ORJSON?

02:49 OR?

02:49 ORJSON.

02:50 ORJSON?

02:50 I don't know.

02:51 Yeah.

02:51 So I want to talk about this project from Adam Johnson.

02:54 So we have a couple of Django topics.

02:57 This one is a Django topic, but it also goes more broadly.

03:00 So there's kind of a multi-level thing going on here.

03:03 Not the marketing badness, but just multiple uses.

03:07 So this is a project that Adam created so that you can change Django's response model.

03:14 So apparently the way Django uses JSON or generates JSON responses happens in a bunch of different ways.

03:22 So it says there's a library called ORJSON.

03:26 And somewhere it says, yeah, here we go.

03:28 It says, compared to Python's built-in JSON, it boasts 10x faster serialization and two times faster deserialization.

03:37 And I believe it is a little bit more forgiving of date times and stuff.

03:41 It has like default conversions, whereas if you've ever tried to serialize certain things, it's like, nope.

03:46 Sounds like a win.

03:48 I know it does.

03:49 Like I couldn't possibly figure out a way to represent time.

03:53 What a weird, this is a rare concept we don't normally encounter.

03:57 So this handles some of those things as well.

03:59 So there are a couple of reasons that you might play with it,

04:01 but it is a little bit different.

04:02 So be a bit careful.

04:04 So, all right.

04:05 So the idea is that there's a bunch of different places,

04:07 like such a great library, but adopting it isn't easy

04:10 when your framework uses JSON in multiple different parts,

04:14 in different places.

04:15 So Adam introduces Django ORJSON, which provides a bunch of replacements and you just plug it in, right?

04:22 So import JSON response and you can return that directly, which is cool.

04:27 There's test capabilities loaded up in a template and so on.

04:32 After seeing the initial proposal, Django ORJSON, Paulo, who was recently on Talk Python to talk about maintainer burden and AI,

04:41 coming back to that at the end as well, or later, decided to push for the addition of ORJSON support in Django itself

04:48 under a new feature called pluggable JSON serialization backend,

04:51 which I think is pretty cool.

04:53 I'm all for it.

04:54 Yeah, it's nice, right?

04:55 Like, why not make that an option?

04:56 Yeah, totally.

04:57 It's like saying, nah, that Pydantic thing, probably a flash in the pan.

05:00 We don't need to really worry about that.

05:01 Let's go ask, did you get to try it out?

05:03 You've got a lot of data.

05:05 Yes.

05:06 And so I'm like, well, let me just try this.

05:09 And one of the things that's really cool is with Claude Code and other things, you can say, here is a proposal for how to do this for JSON.

05:16 How would I do this for Flask and Cort, where I'm running my apps?

05:21 And can you tell me the areas where it might be a benefit or not so much a benefit?

05:25 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.

05:37 and yeah that's not bad no it's not too bad but i put that actually the reason like a little bit

05:44 of that analysis into the show notes and it turns out that if you have large json documents with a

05:52 few fields then it doesn't give you a big boost if you have a very fine-grained json document with

05:58 lots of small fields apparently that's where this performance starts to pay off and i happen to have

06:03 like big chunky JSON, I guess is what I got.

06:06 I don't know.

06:06 It's got things like 100K of transcripts in a response,

06:11 you know, not, and it's structured as a giant piece of text.

06:14 It's not necessarily like subtitle text second and so on.

06:20 So that's interesting.

06:21 And it said, look, it could help your MCP server, but the traffic on the MCP server is not that high.

06:27 You swap it out, you'd probably save 0.119 milliseconds of requests.

06:33 And for a response that takes 1.1 milliseconds, you really wouldn't mess with it?

06:38 I decided no, which I thought was kind of interesting

06:40 in the first place.

06:41 Like, you try it out, you're like, oh, cool idea.

06:44 Just not for my use case.

06:45 Most of my stuff is RSS.

06:47 It's HTML.

06:48 It's like not that much JSON.

06:50 But I do think for the right use case, it would be really powerful.

06:53 I mean, are there any compatibility caveats that people need to be aware of here?

06:57 There are some minor ones about how it handles certain things

07:02 that either can't be serialized or if you don't specify how to serialize them,

07:06 like for example, date times and stuff like that.

07:08 Which everyone loves dealing with date times.

07:10 It's our favorite.

07:11 Yeah.

07:12 Can we put some time zones in there please?

07:14 Yeah, yes.

07:16 All right, over to you.

07:17 Yeah, very cool.

07:18 Well, mine's also performance related and I think it'll dovetail nicely

07:22 into what you just mentioned here.

07:24 Speaking of performance and JSON and evaluations,

07:28 I think one of the things that has been nice about using these AI agents, like you just mentioned,

07:32 you can put it on a mission to go try some hypotheses and some theories and etc. This is a

07:38 article from Peter Mengson who revits a one from 2017. So this is actually the original performance

07:47 article he did around fastest Redis configurations for Django. So a lot of folks just use the default

07:53 out of the box configuration for Redis, kind of a standard thing these days to use for any kind of

07:57 caching that you might use inside of your application, but it has tunable capabilities

08:03 since you can adjust the format of the serializer. So whether it uses like JSON, UJSON, MessagePack,

08:09 or Pickle, you can also adjust the compressors it may use. So whether it's using Zlib,

08:15 LZMA, or ZStandard is a new one that's coming up. It didn't exist when he did this 2017.

08:20 So he just, actually, this is kind of all pre-AI as well. He did it the old school hard way,

08:25 which is specify a bunch of different configuration combinations,

08:30 run through a framework and try and test and see what the performance boost may be

08:35 based on the kind of data he threw at it.

08:37 So if you look down here, actually it's kind of fun,

08:39 very ASCII art result graphs here.

08:43 I'm here for the ASCII art.

08:45 I'm here for it.

08:45 Yeah, I know.

08:46 So JSON is the slowest.

08:48 Here are the shorter or better, so best averages,

08:50 like for averages, medians, and size of data stored.

08:54 You can see here, JSON, not so great.

08:57 Actually, I wonder if in his updated version, he did not use ORJSON.

09:01 I wonder how that would affect this.

09:02 But basically, MessagePack as a message format is going to be one of the fastest ones he found for this specific application.

09:09 And then if we look over here.

09:12 I would bet that MessagePack is faster than ORJSON.

09:17 Probably still.

09:18 So I bet that sets a lower bound.

09:19 Yeah. So updating here to look at three specific compressors, Zlibs, LZMA, and Zstandard,

09:27 the LZMA is still slow. While it compresses well, it's slower from a performance standpoint.

09:34 The default, actually not doing too bad here, except for size of data stored, which if you're

09:41 saving larger sized items, there was a different performance difference, which actually I think

09:47 leads to why coding agents like Claude Code and Pi and these orchestrators allow you to do this

09:53 kind of experimentation with very low risk and overhead. Because ultimately, the end difference

10:01 matters on the kind of data, like you just mentioned, the kind of data you're storing

10:04 in these various serializers are going to determine a lot of the performance characteristics. So

10:09 I hate saying it depends, but your mileage will vary based on what you're throwing into Redis and how

10:14 you're accessing it. So it's always nice to be able to set up some kind of performance harness

10:17 or benchmark where you can actually test these yourself and see how you get the most mileage

10:22 out of these tools. And based on what I saw here, it seems like there's quite a bit of room for

10:26 improvement for eking out more performance. So as we typically do, I like starting off with the

10:33 defaults first and only optimize when I see a problem. But these are great ways to take a look

10:37 at the different message format serializers for Django Redis and then the various compression

10:44 formats that are out there for it so a nice methodology a nice little write-up showing some

10:48 of the results and showing that it's actually not too not too hard for you to go implement this

10:52 yourself a great way to get some squeeze more performance out of jango with your redis which

10:57 is already fast but here you can i love it yeah yeah it's super fast i 100 endorse here let's try

11:03 it with the built-in stuff and then see because yeah like in my example i could have taken on one

11:09 more dependency and thing i have to update but it's like do you really need a tenth of a millisecond

11:14 No, it makes zero difference to me, honestly.

11:17 We'll talk about simplicity in my next one I bring up after yours here.

11:20 Okay.

11:21 I do have a little bit of real-time follow-up, sort of.

11:25 I just chose to throw this out there, by the way.

11:28 Oh, nice.

11:28 Just a quick shout-out to Valkey.

11:30 When I hear stuff on Redis, I'm like, don't forget the Valkey.

11:33 You're familiar with this, yes?

11:34 Oh, yeah.

11:36 When there was a whole hoodoo around the licensing with Redis,

11:40 we switched over to Valkey for many of our projects.

11:43 It's been great.

11:43 Cool. Yeah, yeah. That's awesome. Yeah. So basically Valkey is like the more open source,

11:49 all a fork of Redis and it's like API compatible of my understanding, but it's,

11:53 it's, you know, 26,000 stars. It's like a half a flask, something like that level of popularity.

11:59 Yeah. Well, it's tricky because then the Redis folks went back on the whole

12:03 Bizzle license back into open, right? Yeah, exactly. It gets, it gets a little funky,

12:08 but let's talk about something that not even close to as controversial as that licensing

12:13 Let's talk about Linus Torvalds puts his foot down against anti-AI kernel maintainers.

12:19 There's a lot of double negatives here.

12:20 So Linus says...

12:22 I had a hard time parsing that one.

12:24 I know.

12:25 Okay.

12:25 So Linus says, I'm not having it, that there are people saying we're unwilling to use AI

12:33 in any way against the Linux kernel.

12:36 And it's pretty interesting.

12:37 I'm going to link to the actual original thing here.

12:40 I got some quotes that I pulled out.

12:42 So this all has to do with this thing called Shashanko.

12:47 And what Shashanko is, I don't work on the Linux kernel,

12:51 so it's not a thing I'm super familiar with, just to be clear.

12:54 But Shashanko is an AI PR review tool.

12:59 I guess it's built into GitHub or something like that for automation.

13:03 You know, like GitHub actions are the equivalent thereof.

13:06 And it will review inbound PRs for bugs, for correctness, performance, that kind of stuff.

13:13 Yeah.

13:14 And I think there are some people that are like, no, heck no, I want nothing to do with this thing.

13:19 So it's not necessarily just cutting AI completely loose and saying, hey, here's the spec of the kernel.

13:26 Right.

13:27 Make it better.

13:28 See you next week.

13:28 You know, it's way more subtle and less intense.

13:32 It's a human augmentation.

13:34 It's making us better at what we do.

13:36 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 what, 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 says Linux is not one of those anti AI projects, you know, think Zig or something like that. Right.

14:05 And if somebody has issues with that, they can do the open source thing and fork it or just walk away.

14:10 It's like, you know what?

14:10 Okay.

14:11 I mean, what do you expect from him, right?

14:14 That's true.

14:14 What do you expect?

14:16 AI is a tool, just like other tools we use, and it's clearly a useful one.

14:19 And it may not have been that clearly even just a year ago, but that's no longer the question.

14:24 I think that's an important thing, right?

14:26 Like people have formed opinions, especially people who have formed the opinions like, I don't want to touch this.

14:31 This is junk.

14:31 It's like, why would you come back to a thing that's junk?

14:33 You know what I mean?

14:34 Right.

14:34 Why would you go build a house with hand tools when you've got power tools available?

14:38 Yes, exactly.

14:39 Well, because nail guns are dangerous.

14:42 And we've had them since the 40s.

14:45 I do want to point out that there's this really good, I've mentioned this guy before on the show.

14:51 Are you familiar with this?

14:52 I am not.

14:53 Maximilian Schwarzmüller, this German guy.

14:56 He's really good at talking about trends in software development.

15:01 And one of the things he says here is he, in response to talking about this, said it is time to wake up for some.

15:08 So he put it less, more bluntly saying, look, if in a couple of years, if you're doing professional software development, you're going to have to be using these tools.

15:16 Yeah.

15:17 And you need to get good at them regardless of how you feel about them.

15:20 You know what I mean?

15:21 It's fine for hobby stuff not to do it.

15:23 That's like a 12 minute.

15:24 That's a summary of a 12 minute video, but it's really well done.

15:27 So I recommend people check it out.

15:28 And he's just an interesting guy.

15:30 Okay, back to what Linus is saying.

15:32 Yes, it can be somewhat painful tool for maintainer workloads and so on.

15:36 And also because it just keeps finding embarrassing bugs,

15:39 which is annoying, but amazing.

15:41 I think that this embarrassing bugs bit is actually transient.

15:45 We've got 10, 20, you know, however long the projects have been around for,

15:49 years of tech debt.

15:50 Tons.

15:51 Yeah, and we send this tool on.

15:52 It's like running a linter.

15:54 Like, do you guys have a linter?

15:55 No. Oh, you should try a black or rough or something.

15:58 And then it's like, there's 2000 errors.

16:00 we can't fix 2000 errors.

16:01 Like we just don't run it anymore.

16:03 You know what I mean?

16:04 But projects that start adopting linters don't always have 2000 warnings or issues, right?

16:10 All right, carrying on.

16:11 But the solution is not to put your hand.

16:12 It feels like nothing but win here.

16:13 Like you want a linter?

16:16 I wouldn't go without it right now, period.

16:18 Yeah, 100%.

16:19 It's just, it's kind of painful to deal with some of the fixes,

16:22 but you know, you get through them and then it's pretty straightforward,

16:24 especially with --fix and a lot of the modern ones.

16:27 Okay.

16:27 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

16:35 it's to make sure the lm tools help maintainers instead of causing them pain we're not for and

16:39 here's the essence of this whole um thing we're not forcing anyone to use it but i will verily

16:44 loudly ignore people who try to argue against other people using it there's no ai is not perfect

16:51 but but blankety blank anyone who points the problems points to the problems that ai had

16:57 better be looking in the mirror and pointing themselves at the same time because people make

17:01 mistakes too all right pretty certainly i did not write this email post yeah this feels very human

17:06 this is very much on brand so i thought i put out there i feel like it's a little bit seminal

17:12 and in terms of this um ars technica has a write-up as as well and it's gathered almost 200

17:18 comments so that's worth checking out yeah yeah i'm curious why folks the folks who are in the

17:23 never AI camp are not using it even for completion do they never use it and I mean I held out on IDEs

17:29 for a long time because I didn't feel like I needed the autocomplete but like that those days are long

17:33 gone like this things have gotten so fast and have helped me like streamline my workflow where it's

17:38 not standing in my way and I feel like these tools will get into that point where it is just like

17:43 wrapping a amazing exoskeleton around your capabilities and going for it and doing more

17:48 and better. Yeah. Yeah. I don't remember the numbers. I don't know. I don't believe they're

17:53 in here, but they might be in a fall. I mean, there's a conversation to be had. You can see,

17:57 if you look at the art, the thread, but I believe it's something like this Shashanko thing is like

18:03 15% false positives, but 85% like, yeah, these are actual bugs that you didn't have to find.

18:09 I just told you they're bugs here. Yeah. And these people have all written helper scripts

18:13 to do these kinds of things. They can't be against this one. Yeah. I mean, they can,

18:17 but it doesn't make any sense.

18:19 Yeah, I just, I feel like if you've got a tool that by the time you get to the PR,

18:23 it has an 85% accuracy rate of finding and dealing with any of the issues.

18:28 Like, that's pretty good.

18:30 Yeah, pretty good.

18:30 Plus you're still expected to operate as a human

18:33 in this case, like bringing the creativity, bringing the original thought,

18:38 just letting it take care of all the mundane, boring stuff.

18:40 Like making sure you cross your T's and dotted your I's in the code.

18:44 Seems like all went.

18:45 All went to me.

18:46 100%.

18:47 Speaking of when, wouldn't it be awesome if HTML did better stuff?

18:51 Like they didn't stop building it when soon as JavaScript was invented in the 90s or whatever it was.

18:57 Yeah, so our third Django-related news item for the day is that the Django Steering Council is backing the Triptych Project.

19:06 So if you're not familiar with the Triptych Project, it is three proposals for the HTML standard to make things a little more native and expressive.

19:16 So adding in, for example, put patch and delete methods to forms.

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

19:37 So this gives us the ability to put those three extra actions.

19:41 The fact that button actions should be a thing.

19:44 So buttons that just can fire HTTP requests without wrapping them in a form.

19:47 How many times have you had a singleton button with form on top, form on the bottom?

19:53 Or worse, like for example, if you're not using a button, but dressing up a link to

19:57 look like a button, for example, like a logout, the logout button could potentially get triggered

20:02 by some of the prefetch operations that are happening by some of the browsers or unfurling,

20:07 et cetera.

20:08 So you may get unexpectedly log out or unexpectedly delete something.

20:11 Be careful when you make a button that says delete, that is actually a link.

20:15 Those buttons should be buttons.

20:17 There was actually back in internet lore, there was a really interesting thing.

20:22 I think at the early days of Wikipedia, that one of the delete buttons was actually just

20:29 an Ahrefs that went to a delete operator, but did a Git and got indexed and deleted a bunch

20:34 of Wikipedia.

20:35 I think it was Wikipedia.

20:36 idea. Yep. So the idea is, yeah, let's, let's resimplify, make things more semantically

20:44 operational in the way that we should expect them to work. The last thing, the last proposal

20:49 is actually around partial page replacements. So if you are taking the ideas from basically HTMX,

20:54 Unpoly, and Turbo, and putting them into the HTML standard itself. So this means if the standard

21:00 gets adopted and the browser start putting this into their HTML parser and engine that's powering

21:07 your web browser, less JavaScript and libraries can actually be shipped to get the same level of

21:13 interactivity on the pages that we're doing right now today with things like HTMX. I really like

21:17 the HTMX library. I feel like it gives people a clean, clear way to do things in Django really

21:24 fast and have like a single page web app like front end without having to rebuild all of your

21:29 Django models in React on the front end.

21:32 Like with a lot of the React patterns, you are building the same models twice,

21:36 the same routers twice, the same application basically

21:39 has to be built and maintained in two separate frameworks.

21:42 Where if you just had these capabilities built right into HTMX or the browser, I mean,

21:47 with this triptych project proposals for the HTML spec,

21:51 well, think about how clean and this is simple that the development could be,

21:57 especially for testing out and running quick little one-off projects.

22:00 They could be so much less dependencies, hopefully less maintenance going on in there.

22:06 So I think that's really nice.

22:07 The piece is relevant for Django.

22:10 Django is here to help shepherd in the better web and new technologies for it.

22:17 So that's why they're backing the Triptych project specifically.

22:20 But also, for example, the Django 6 introduced template parcels,

22:25 which are inspired by these patterns.

22:27 So Django is kind of already ready to have this work.

22:30 So if you're using HTML, you get some benefit that Django helps you generate these partials right out of

22:35 the box, which is another one of the nice things about Django.

22:37 It's kind of that batteries included, all the things just work.

22:41 If you want to help, there's links here to the Triptych project,

22:44 which if you are familiar with the web hypertext community,

22:49 the what we G, I don't know how you pronounce that specifically,

22:53 But this is basically taken over from the W3C for the HTML standards.

22:57 And so they have submitted a proposal to this working group, which is basically the living

23:02 HTML standard, which is where browser companies now build from and based off of.

23:07 That's what they've put forth.

23:09 This has been put forth by Carson Gross and Alex Petros.

23:13 So if you may recognize some of those names, one of them is the creator of HTML itself.

23:17 And if we go into the Triptych project, you can see there's the three proposals here,

23:22 plus a blog post I linked to, and some of the examples of why this is actually important,

23:27 and some of the history around it.

23:30 If you wanna get involved, I think that's actually the more relevant call to action here,

23:34 is they're looking for folks to send non-binding letters of support

23:38 on company letterhead that they would be willing to support

23:42 and sponsor these proposals and help weigh in on that issue.

23:46 So there's a GitHub issue, that whole living HTML spec

23:50 is actually maintained as a GitHub repository.

23:52 anyone can join. It's not an exclusive club of enterprises and corporations anymore driving that

23:58 living HTML spec. It's driven by the community itself. So if you get excited about this, go get

24:03 involved, go check it out. I look forward to this being the future of browsers because we can now,

24:08 especially for simple things, oh boy, would this be just nice to have this built in.

24:12 Yeah. It kind of fills the role that jQuery used to, you know, and we got past it because it's like,

24:18 oh no, we need to build this huge front end stuff.

24:20 And sometimes you just need, when I click this, that thing over there to change,

24:23 but the rest of the page to stay.

24:26 I mean, I've wanted this for like two decades.

24:27 Like the fact that the button couldn't just fire an action,

24:30 like having that wiring, it just makes sense.

24:32 And I think this makes sense for getting things cleaned up

24:35 and having less workarounds means that agentic coding tools can actually operate better

24:39 because they'll have a better understanding of the semantics of this.

24:42 They appreciate semantics where things are wired up

24:45 and work as you expect them to.

24:47 Yeah. And if you like things like HTMX and Datastar and those kinds of frameworks, this just brings it natively to the browsers closer.

24:55 There's still layers to add on top of it, but less.

24:58 I'm excited to see the Django community getting behind this.

25:02 There's still innovation happening on a 25-year-old project.

25:06 Incredible, right?

25:07 Yeah, it is. What do you got for extras today, Michael?

25:10 I have a couple of things here, two things, and just a little bit of a follow-up to what I know

25:18 your extra is going to be, but I'm going to wait. It's going to be a multi-staged extra, let's say.

25:23 All right.

25:23 I am a fan of the Granian web framework, powers Python, bytes,.fm, and many, many other things.

25:30 It's a Rust-based HTTP server for Python, like think G, Unicorn, Uvicorn, that type of thing.

25:38 and it's been around for quite a while.

25:41 It's quite active.

25:42 It's getting a lot of updates on it.

25:45 More importantly, let's see.

25:48 Where will one, this is Nazi.

25:49 I need to learn, work on my Rust.

25:51 Go to the cargo lock.

25:53 More importantly, it wraps this thing called Hyper.

25:55 And if you look at Hyper, that's like, it's a web server out of the Rust world

26:01 that has like 130,000 stars.

26:03 So basically this is like a WSGI and ASGI server that just kind of provides hyper to Python applications, right?

26:10 Cool, cool.

26:11 So what am I talking about?

26:13 I've had Giovanni on the show and stuff before, but there's a pretty big update to it,

26:17 even though it's just a 2.7.9.

26:20 But it sounds like, ah, whatever.

26:23 But, you know, I fixed a bug in the blocking thread pool schedule,

26:28 causing starvation under scaling with WSGI and long running requests.

26:32 Like, so if you're using this, just bump it up.

26:34 That's easy.

26:35 Easy to do.

26:36 you should easy to do it sounds like it would make a big difference you should definitely do that

26:40 the next one i'm going to reshare my screen here okay do a live demo if i can find the stinking

26:47 window there we go so i really enjoy doom doom was originally coded up and created on the next step

26:58 os and the next machine since i actually have two next machines on my desk that have doom installed

27:03 on them. I have Doom installed my iPad, but now I can have Doom installed in the terminal. And

27:08 instead of usually people are saying, does it run Doom? Like that's the joke that people say,

27:13 can that piece of hardware run Doom? This is a little different. This is your Doom running in

27:17 SQLite. So DoomQL, you can see here, select star from hell. So if you're a fan of the game,

27:23 that joke should land. But basically the frame buffer is a SQL query. So if we actually come in

27:29 over here and I'll run the demo make make run. This is Doom running in my frame buffer, but the

27:37 frame buffer is running in SQLite. So it uses the same standard wasad key combos. You can go and

27:43 grab like power ups. There are monsters in here someplace. It is incredible. Yeah, it's tricky.

27:49 It's a little trick. Oh, see, I'm getting like killed by. Oh, there's a monster right there.

27:52 It just is killing me as we go. This is running SQLite. You can actually tail the SQL queries

27:58 and watch all the queries that are happening under the covers

28:01 if you had another window open and ran the make inspect command.

28:04 So definitely check that out.

28:06 It is hilarious to see that we have got Doom running in SQLite.

28:12 So not just on fancy hardware, on crazy databases.

28:15 Now we can run Doom.

28:16 How incredible.

28:17 That is super, super neat.

28:20 So that's what I had to go check it out.

28:21 I don't know how I feel about it, but yeah, Doom.

28:24 I used to play a lot of Doom when I was much, much younger.

28:27 Much younger.

28:28 I also have another real-time follow-up.

28:31 How can you possibly play Doom?

28:33 One of my earliest jobs was working in this place called Eye Tracking,

28:36 E-Y-E tracking, at eye tracking.com in San Diego.

28:40 And we did all this crazy type of research by looking at what people would see

28:46 and how their eyes would react as they were solving problems and so on.

28:50 So we had these weird collaborations.

28:51 And one of the collaborations was this guy, I don't remember,

28:53 it was like a university or something, who did stuff with EEG, I think it was,

28:57 not EKG, the brain bit, not the heart bit, with the wires.

29:02 And so somehow wanted to kind of understand the eye tracking side and the EEG side.

29:08 What does this have to do with Doom?

29:10 Well, he would play it by thinking with an EEG, no hands.

29:15 And he would just think and it would turn left and they would think something else and it

29:18 would shoot a gun.

29:19 But what was really weird was he wouldn't think turn left and it would turn left.

29:23 He'd have to activate different parts of his brain.

29:25 So he's like bacon, bacon, bacon.

29:27 with stars you you know what i mean like because yeah it couldn't just be the same part with motor

29:32 skills it'd have to be like a different part like a like an xbox controller of the brain

29:38 anyway i thought people might find that amazing that's really really weird doom's got quite a bit

29:42 of history with uh the computer world and computer science world too yes exactly exactly all right

29:49 let's talk about jokes i'm sure there's a bug in doom so i named this joke solving all the bugs have

29:53 Have you seen this?

29:55 No, I've not.

29:55 Have you looked at?

29:56 Okay, good.

29:57 I didn't peek.

29:57 Good.

29:58 So I want you to put yourself in the state of, I don't know, some apocalyptic future whenever

30:05 the matrix was set with Neo and Morpheus and all that.

30:09 Okay.

30:09 So how, in this kind of world, how would you solve the bugs?

30:12 Well, it says no production incident ever exists without Jira ticket.

30:20 So what if Jira tickets are the issues all along?

30:23 there is no jira there is no spoon everything is perfect all right oh boy i'm ready to take the red

30:30 pill yeah let's take it thanks there is no spoon yeah you bet you bet that's amazing especially

30:37 your keanu reeves impression uh very i tried i tried yeah thank you very spot well thank you for

30:44 joining us this week for uh python bites all the news all the time and i'm looking forward to seeing

30:50 you all next week we'll see you later

Want to go deeper? Check our projects

Course: Python for the Absolute Beginner course

Beginners

HTMX + Flask

FastAPI

pytest book

Full transcript