Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 419, recorded February 4th, 2025.
And I am Brian Okken.
And I am Michael Kennedy.
And this episode is sponsored by us.
Check out our courses at either pythontest.com or talkpython.com.
No, wait, that's right, isn't it?
Talkpython.com will work.
Yeah, that's right.
Also, thank you to our Patreon supporters.
We don't thank them very much, but they do help with the show.
So thanks.
If you'd like to connect with the show, please hop on Blue Sky or Mastodon.
And the links to both Michael and myself and the show are in the show notes.
And if you'd like to join us live, it's Tuesday today, but normally it's Monday.
Normally Monday at 10 at Pacific time.
Go to pythonbytes.fm/live.
And finally, we are getting some great feedback about our updated beefier show notes with deep dives.
So we, in the email list.
So if you'd like to get some background around all the topics we cover and a little more info than what we have in the show notes, join the newsletter.
Just go to pythonbytes.fm.
And it's really easy to figure out.
So.
Definitely is.
How about.
Check it out.
And there's a lot of great content there.
And you're going to.
It's a email type.
Content.
I was trying to go into the first topic there.
We'll get there.
So, yeah.
If you're going to attach something, maybe we would have a Mime type.
Like a graphic or zip file or something.
So last week, this is like Groundhog Day.
Mime types.
Mime type.io.
Remember I talked about that.
Yeah.
Well, got some nice feedback from folks, including Rafe Guns, who said, hey, you mentioned Mime type.io.
That reminds me of something that happened just last week.
I need to map file names to this.
And I thought, surely someone's already done this.
And it turns out that the standard library already has a built-in Mime types.
And you can ask it, hey, what is given this file name?
What do you think its extension is?
Okay.
So, even better, right?
Yeah.
Well, well, well.
No, not so fast.
This sent me down such a rabbit hole.
Okay.
So, there are weird things that this Mime types library does.
Like, there's not that many.
And especially for the common ones, it's a list of like 100 or something.
You know?
But if you look at the implementation in CPython for Mime types, what it does is it looks at a set of files that come with each different operating system.
Raspberry Pi, Ubuntu, macOS, Windows 7, whatever.
It doesn't have a single built-in Mime type.
Like, it won't tell you what they are.
It doesn't know what text.txt is.
It doesn't know what HTML is.
It just looks at these files, which is really weird to me.
Because that means you get different answers for Mime types based on your operating system.
Like, Docker might, if you run Linux in a Docker container, it might give you different output than, say, Desktop Linux and stuff.
Real just thinking, you know, for like 30 seconds around this, it seems like maybe you should build in all the known ones.
And then if it overrides it, like something special about the machine configuration says this Mime type is something different, maybe consider overriding it with a local file definition.
But just omitting them all, very weird.
Plus, it'll tell you things that are wrong, like that XML should be text slash XML, not application slash XML.
Okay.
So that sent me looking.
I'm like, well, that's not great.
Surely there's something on PyPI.
So I looked for like Python Magic.
And Python Magic is awesome.
What it does is you give it a file.
It's based on libmagic or some kind of C library or something.
So you've got to install that with brew, which is kind of weird.
But okay, fine.
So you got that.
And then what it does is you say, hey, given this file, like this PDF, tell me what kind it is.
And it says, hey, this is application.pdf.
But the way it knows this is it goes and it actually reads the file.
It doesn't just look at the extension.
It goes, ah, you said it's a .jpg.
But when I looked at it, I inspected the binary header for the image.
And it looks like it's a PNG.
So we're going to tell you it's PNG.
Super helpful when you're talking about the file system.
Super duper unhelpful when you're building web applications.
You know, like when you need to specify the MIME type.
Because what if your image lives in S3 storage?
How are you going to ask what I should return if I want to link, just redirect someone to it?
Got to download it from S3, feed it to the thing.
Yeah.
Throw away the temporary file and send it back.
And all these other ones, they all look at the file.
Like, if you don't look at the file, how are you going to know?
It's like, okay, if you want to be super thorough, yes.
But what if the file's in a database?
The file's in, like, remote storage?
Like, you don't want to go get the file.
You want your best guess, right?
So, Brian, this has led me to create GitHub.com /mikeckennedy/ content dash types.
Available on PyPI as content types.
So, it does exactly what you would think.
It tells you, given an extension, what is the MIME types.
It even includes a CLI.
So you can say, like, after uv tool install it, you can just say, type content types anywhere in your terminal.
Give it any form of file name, and it will tell you what comes out.
That's kind of handy.
So, if you're curious, it has way more content types than the MIME types, and they're correct.
That's always good.
We'll talk about that in a second.
But you just say content types, get content type.
You give it some kind of file name, as long as it has an extension.
It doesn't matter if it's a HTTPS to some file, or it's just a file path on your hard drive.
If it has an extension, we'll be able to tell you what its MIME type is.
So, is this just, like, a big lookup of extension to type?
Pretty much.
Yeah, it's like a massive, massive lookup of those things.
But the thing is gathering them all up, right?
So, for example, if you look at the built-in MIME types, like, well, why don't you just have MIME types and use that?
One, it varies.
But two, it's wrong about things like, if you ask MDN, Mozilla Developer Networks, what .xml should be, it says it's application.xml.
It used to be this older text.xml.
It's not anymore.
But the built-in Python one says it's the old style.
It's also missing things like TGZ and GZ Zip and Flack and EPUB and all these types you would expect.
So, anyway, I didn't spend that long.
I spent a few hours building this thing, but I'm like, there, I fixed it.
It doesn't depend on the operating system.
It doesn't have to read the file.
You don't have to download it from S3 storage to tell you what it is.
It just, given a file name, it'll tell you what the content type is.
Or MIME types.
Somebody asked, why don't you name it MIME types?
I'm like, I don't know really how to import something that overrides a built-in as a third-party package and make that useful experience.
You know what I mean?
So, anyway, that's what it's called.
So, hopefully this helps people.
It's built-in Python.
It has something like 180 different types and it has 31 types that are not known to the built-in library.
Common stuff, like I said, like fonts or M4As, audio files, or WebAs for other audio files, or WM.
A lot of stuff, right?
RARS, TTF.
It seems like you should know what that is.
Anyway, I present to the world this project I worked on over the weekend.
Nice.
I like it.
Yeah.
Thanks.
It always threw me that M4As were audio MP4s.
Yeah, I know.
It's M4A.
It's not MP4.
Anyway, but since I work with audio as well.
So, hey, good job, I think.
And let's talk about Django a little bit.
So, Wagtail, Wagtail 6.4 is here.
There's an announcement.
Enjoy a smoother content experience with Wagtail 6.4.
I don't actually use Wagtail 6.4, or Wagtail.
But I play one on TV.
No, but I'm glad Wagtail's here.
It's a really cool platform, content management system built on top of Django.
Why am I bringing this up?
It's great that they've got a release and there's some cool stuff.
But the thing that I really am excited about is, if we go down, it says, this version incorporates Django Tasks library.
And that's the cool bit, according to me.
So, the Django Tasks library.
And there's a release notes, too, that we'll link, too.
It also is pretty excited about the Django Tasks.
So, what are Django Tasks?
Let's see.
Oh, yeah.
Oh, by the way.
Some of the cool things about Wagtail, it's used by NASA and Google and NHS.
Wow.
Some of those are still operating.
So, Django Tasks is a, if we look at it, it says it's a backport.
But it's really the implementation that you can play with right now of a thing defined in DEP 14.
And that's a Django enhancement proposal for background workers.
And this is accepted.
And one of the things, whether you love or hate it, Django enhancement proposals don't happen quickly.
Partly, it's because we really, they do LTS support and they really don't want to break things.
And they just don't happen fast.
But that's okay.
We love you, Django.
But the, so Django Tasks is background workers around, yeah, but just background workers.
So, like, you're not in the normal loop.
There's a cool, I was following this rabbit hole, and there's this cool on the Django Tasks forum bringing background workers into Django Core.
There's a talk that was given at DjangoCon Europe 2024.
And this is a great talk.
Listen to this, talking about how really the normal, the cycle of a web page of, like, you do a request and then a response, that doesn't work for a lot of stuff.
And you need background tasks and other tasks to run at different times, or even just later.
Like, you don't have to wait.
We'll work on it.
So, that's cool.
And so now, the implementation of this is being done in the Django Tasks application.
And you can use it.
And since Wagtail is using it, I think it's pretty stable.
And I think people should feel free to use it and provide feedback if you run into any issues.
So, they're really ramping up trying to get this, get all the kinks out.
So, pretty cool.
Yeah, that's really cool.
I think a lot of times people overthink how much infrastructure you need to, say, run something in the background.
Like, oh, this thing takes five seconds.
And if we do it on the view call, then it's going to slow down the website a whole bunch.
So, let's set up Celery and Redis and a queue and, like, whoa, whoa, whoa.
It was running all on its own until just a second ago.
Yeah.
Things like this where it's kind of just a background thread.
Like, okay, well, we just kick it to the thread and maybe you want to log it to a database or send an email.
But you're going to take a second.
So, just let that happen.
Yeah.
It's great.
And also, for people that are thinking about using this Django Tasks project to put something in place,
I think that's where I would lean, partly because that's where Django eventually is going.
But also, you've got Wagtail as an open source project.
You can look to see how they're doing it.
So, you can look to see how the project's implemented.
Yeah, excellent.
Excellent, excellent.
And by the way, Ryan, are you familiar with all the WordPress drama?
Have you been tracking this?
Yeah.
Oh, it's so insane.
People, if you haven't been tracking this, WordPress has gone off the rails.
So, maybe if you're out looking for, I don't know, a different CMS instead of WordPress, Wagtail.
Check it out.
Less drama.
Or if you didn't want to do that, you could build it yourself, right?
Definitely.
So, there's a really nice article from Armin Roeneker.
And he's doing a lot of great writing lately.
So, I'm really, really enjoying it.
Basically, this is something of a rant and a call to arms, if you will, to depend less.
Depend less.
Saying, look, there's a lot of pressure and encouragement to say, if there's anything that
you can use as a third-party dependency, rather than building it into your own code, do that.
That's how you stay agile.
Unless it's not.
Unless it just becomes a drag.
You know, if you have one function that you need, and there's some library that has 100 functions,
and it does a whole bunch of stuff, but it has that one thing you need, you could depend
upon it.
But then, what if you want to go to Python 3.14 and it doesn't upgrade in time and you're
stuck, right?
And, you know, one library, that's one thing, but then you multiply that times 100 and it
gets real complicated real quick.
So, he pulls out an example and says, look, what about terminal size?
This is mostly speaking in Rust terms, but it equally applies to Python.
So, that's why I'm covering it.
It says, terminal size is a package that you can use and it tells you the size of the
terminal, like 80 by 25 or 47 by 100 or whatever the rows, columns of the terminal is.
It tells you that, right?
Well, that thing has been pretty much unchanged for a long, long time, but it's had 26 releases
because the stuff that it depends upon has been churning and has to be, you've got to, you
know, use the newer dependency of this library so that your thing will build on the new version
of the runtime, right?
Instead of just being basic, right?
Why, you know, if terminal itself, terminal size itself hasn't changed, why do you have
to keep rebuilding it, re-releasing it?
Here's a funny term, but big supply chain will tell you, you must do it this way.
Big supply chain.
Yeah, exactly.
It's like big tobacco, big supply chain.
And as well as open source people, right?
They're like, oh, you know, why are you putting this in here?
You could just use this library and this pull requests or similarly for code reviews at
enterprise places.
And there's one quote I want to read to you all about it and then kind of leave it there.
It says, it's time to have a new perspective.
We should give kudos to engineers who write a small function themselves instead of hooking
in a transitive web of packages.
We should be suspicious of big dependency graphs.
Celebrated are the minimal dependencies, the humble function that just quietly does the job
and the code doesn't need to be touched for years because it was done right.
What do you think, Brian?
I take issue with this.
Okay.
I get the idea and I agree with for some things, like something like terminal size.
I don't know how to determine a terminal size, but I imagine that I would probably pull in
a library or something to do that, but I wouldn't expect that it would have to pull in a lot of
stuff.
Yeah.
So if like, I really, you know, there's a lot of like, there's a lot of stuff I depend
on because I don't want to figure it out.
But I also don't really want those things to be too deep, you know, for instance.
But that's the trade-off.
You either, you know, so what's the problem?
So what's the problem writing yourself is because you don't, you're not, if you're not the expert
in this field, why would you think you got it right?
I wouldn't necessarily think it was right just because there's a package for it, but I know
I'm not an expert at it.
So that's why I grabbed a package.
And also, I don't want to think about like security problems and other things in the future.
If there's an issue with certain packages, like why do people use stuff like Redis?
I'm sure you could just write a caching system on your own.
There's reasons why we use these packages, but.
Yeah.
And to be fair, Armin says, look, it's not black and white.
They're important libraries that solve hard problems like web frameworks and graphics libraries
and things like that.
But I think it's more like left pad.
Yeah.
Do we really need a library with three dependencies to just pad a string?
Probably not.
I don't think we do that that much in Python though, or maybe we do.
Not as much.
But I'll give you an example.
Like, so I started working with Postmark.
I'm trying to move away from SendGrid, not going as good as it could, I suppose.
So I'm like, oh, Postmark.
Awesome.
This is, you know, similarly priced.
Seems to be pretty reputable.
They really cracked down on spammers, which is the problem with SendGrid from what I
can tell, at least my personal experience.
So it says, okay, look, if you want to use it, there's official libraries.
Just go over here and grab one.
Like, boom.
There's a Rails gem.
There's a .NET Postmark library.
There's a Java one.
There's a PHP one.
There's a Kraft.
What the heck is Kraft?
But anyway, there's one of them.
There's a Node.js one.
There's a CLI one.
There's one for WordPress.
There's one for Grunt.
One for Zapier.
The most popular programming language in the world is missing.
But, you know, I don't know, whatever it is.
Whatever.
So probably PyPI.
Probably PyPI has one, right?
Postmark email.
Sure.
That's cool.
Okay.
So there's this one called Postmark, the top one.
Updated 2017.
2017.
It has a single sentence.
No documentation.
If I go to it, I guess I could download it.
Let's see.
Let me try another one.
So what about this Postmarker one?
What versions of Python?
Oh, this is actually pretty.
This works pretty well.
But you start looking through these, and a lot of them are like, oh, man.
I don't know.
It's okay.
Like, here's one something for Django from 2011.
One from Flash from 2020, right?
But I wanted one for Quart, right?
Async.
It doesn't really matter if it's Quart.
I want one that supports Async.
Yeah.
Okay.
Here we go again.
So I could try to work with one of those libraries and go, hey, guys, can we think about adding
an Async API to this?
Or go to ChatGPT Pro.
Do you know what the Postmark API is?
Yes.
Create me one that does Async and an Async.io-based one that uses HTTP X-Rex implementation.
Bam.
Got it.
It works fine.
You can stick that in your code and off the race as you go, right?
And I don't have to worry about whether their library supports Python 3.14 when it comes
out or not.
And there's no security things because it's just me and Postmark having a little chat
and things like that.
So I think, and I'm not saying like, don't use packages, don't contribute packages.
I mean, literally, I opened the show with like, here's my new package.
But I think there are also, it's easier than ever these days to go, I need one function that
does this thing.
I like call this one API endpoint.
Like, give me that function.
Boom.
Here it is.
So I don't know.
I think there's some balance to be had.
Yeah.
Also, good API docs.
Like, it might be that Postmark just has pretty decent API docs and you can just build it
yourself anyway.
Or that's what...
I was going to build it myself.
And then I'm like, well, let me ask chat.
Yeah, sure.
And see if it gets it close.
And I'll tweak it if needed.
I'm like, no, it got it exactly right.
Well, that's cool.
It even made the client not just use HTTPX, but it even made the async client an async context
manager.
So I can say async with Postmark client.
Da, da, da, da.
Off it goes.
I mean, it was sweet.
Yeah.
What I hope, I hope that people like Postmark and other services that have APIs that we're
using, I hope they keep the documentation good and not think that people are just going
to use AI to generate the stuff anyway.
So you don't need the documentation.
We still need the documentation because sometimes it's wrong or we have bugs or something has to
be debugged.
So anyway.
Yeah.
And by the way, if there was an official Python one that had async support, I would have
more than gladly used it.
I didn't want to create my own.
It just doesn't exist.
Right.
And so maybe we could turn this around a little bit and say, if you're out there listening and
you work for a company like Postmark that has an API and you're like, well, it's too much
to create an API client in Python.
I bet it's not if you ask.
Yeah.
And then you have people in-house to review it and say, yeah, that's probably what we
want.
Right.
Then open source it and people can contribute to it.
Yeah.
But I think the zero to one, like, oh, we're not going to create it for this.
We'll just give people the docs and let them rewrite it like a million times across all the
developers.
I don't think that makes as much sense as it used to because it's not that hard to create
one these days.
Yeah.
Agreed.
Cool.
Yeah.
Anyway, thanks, Armin, for the cool article.
Talking about building packages, though, I was curious what backend, build backend you
used.
Do you use setup tools or hatch or hatchling?
I use hatchling.
Okay.
For the build backend, my pyproject.toml.
And I use uvbuild, uvpublish as the workflow.
Okay.
Cool.
I haven't done the uv.
I've done uvbuild, but I haven't done the publish bit before.
Yeah.
However, so pyproject.toml, we've been following it on the rise of pyproject.toml on the show.
And there's this, I'm cracking up.
There's a blog from Bastion Venther.
Sorry, Bastion.
The title of the blog is still don't have a title, which is an awesome title for a blog.
Just saying.
He did this investigation both last year and this year.
And it's about how, with the popularity of build backends for projects using pyproject.toml.
So this is the second version.
Kind of a fun, just little data set.
There's, he actually uses data set.
Nice.
But the results are interesting, I think.
I'm going to pull up from last year and this year so we can get the same graph.
Okay.
So last year, we had setup tools was definitely in the lead.
Poetry next, hatchling, and then flit.
And then other was about the same as flit, maybe a little bit bigger.
And then this year, looking at the graph, again, setup tools, poetry, but there's not as much growth in poetry.
Hatchling is growing a lot more now.
And then.
Yeah, no fact, that's a good job with that one.
Flit's down.
And then the other's actually bigger than flit.
I don't know what all the others are.
But anyway, the takeaway, there's some, and then there's some, the plot shows a relative distribution.
Over the quarters.
And you can really see there that hatchling is really growing.
And, and flits actually on the decline.
Looks like, looks like poetry is kind of on the decline as well, a little bit.
I think I would see, I think there's just a lot more projects now.
But, but I think hatchling is sort of taking some lead.
I, and this, this, this isn't really that surprising to me because I, I, I think that set up what a big decline in set up tools for a while was because flit and hatchling were working so much better.
But set up tools had some updates with being able to use it with a pipe project at Toml better.
And, and those updates, I think have improved things.
So I use both now.
I'm using hatchling for some projects, especially when I want fine control.
But if it's really just a really simple thing, especially if I'm doing it in a corporate setting, I'll probably use set up tools because it's, I don't know, it's more, it's more mainstream.
People know about it more.
I don't have to explain anything.
So just interesting looking at the, the trends for, for backends.
Yeah, that's interesting.
I wonder what the, you know, the, sort of the default behavior for different projects, you know, if there's certain projects that will create like popular cookie cutter templates or other things.
Oh yeah.
That make an outsized impact on this.
I'm not sure.
Nothing comes to mind, but there could be something like, oh, this thing would be way lower except for it's used this, it's used in this project that's used by so many people or something.
Yeah.
It would be interesting to know.
What is, when you say like, I can't remember.
Oh, uv has its own, right?
So if you say, does uv have its own build backend instead of build backend?
Not that I know of.
For the, it just will build any pyproject.toml using the specified build backend as far as I know.
So for mine, I put hatchling in my pyproject.toml, then I just say uv build and it does it.
Yeah.
I'm just like, uv has a uv in it, so you can initialize that pyproject.toml.
I'm curious what backend it specified is.
Oh, I have no idea.
I have to play with that.
You do your extras and I'll tell you the answer.
Okay.
I'll go to the, I've got a couple extras.
First off, I'll jump ahead.
So one of the things that we've got with Python bytes, and I think, I think you do this with talk Python to me as well, is there's a episodes page that lists all the episodes.
I mean, it's one line each.
So why not?
Just list them all.
So if you're curious about an old episode, you can take a look.
I wanted this for testing code.
So testing code used to be something like this.
So if you go to all episodes, it'll show the title of the episode and the information.
And then you see 30 of them.
And then if you want to see more, you go to the next page.
But I've got 225 episodes still.
Why you have to, that's a lot of clicking to go through all of them.
So the update I've got is that I'm handwriting this, but it's not that hard.
I've got an archive page now that has all episodes.
So you can see all episodes of testing code.
They're reverse ordered.
And I think that's right for season one, because there's a lot here.
But for season one was long.
Yeah, I know.
Nine years, 223 episodes.
Yeah, whatever.
Time for season two.
And it'll probably be shorter than nine years for season two.
We'll see.
Probably.
But I might reverse these and have them one, two, three instead of three, two, one.
We'll see.
Anyway, that's my first extra.
The second extra is something completely different.
It has nothing to do with Python.
I just came across this thing called Namegrapher.
And I think it's about US names.
Because I was curious why there weren't any Bryans around anymore.
But the peak of Brian was 1970.
And I looked up Michael also.
Michael's been popular.
I got a little broader distribution, but still extremely 70s kids.
But it was the number one name in the 60s, 70s, and 80s, and 90s, I think, or something like that.
It's been number one for a long time.
So you're popular.
There's a lot of Mike's out there.
My wife always jokes at her.
She yells my name in a supermarket.
Like, three guys will turn around.
Yeah.
Anyway, it's kind of fun to look up some names.
Anyway, that's my answer.
Interesting to apply to yourself.
And if you're going to have a kid, you can think about, you can put your considered names into there and see what you get.
Yeah, we thought we were being clever with a name.
And it was not clever.
Hey, you know, I think the reason, like, if you look at your daughter's name, it was spiked right around her age, right, when she was born.
Yeah.
But I imagine that parents, we think of, like, other parents that we know to a large degree, right?
Yeah.
When you're having a younger kid, you're like, okay, well, I don't know a lot of people with such and such names.
So that must be kind of unique.
I'll do that.
But it's unique for your generation, but not for the coming one or something, right?
Exactly.
So you got to look for something that's unique for both.
So, like, my recommendation for a girl's name, Esther.
Like, no Esthers around.
Well, there's some, but not very many.
And it may be featured in a Jane Austen novel, given that it's, like, popular in the 1800s.
Okay, there you go.
Ethel.
There's not going to be any other Ethels at the school.
Oh, yeah.
The long tail of Ethel is thin.
Okay.
Do you have anything extras for us?
Nothing other than real-time follow-up.
So here's what I got for you.
I did a quick uv init, and I got a very simple thing, Pyproject.tomahill, that just says a readme.
It requires Python 313 and empty dependencies.
And so I added requests, uv add.
And then it added, that made it add an aversion.
That's funky.
Anyway, it added a version because of that.
Oh, nice.
And then it added the dependencies to just add requests or whatever.
But it does not specify a build backend.
Weird.
Because maybe you're not going to publish it.
Maybe it's just, I don't know.
Oh, right.
Yeah.
Right.
Maybe it's just for you.
You just want a little local package, like a mono repo sort of deal.
I don't know.
Yeah.
Also, I think you can just push those up.
Anyway.
I wonder what happens.
Anyway, this is what I found.
This is what I've discovered by using the latest, nearly latest uv.
Yeah.
I'm having fun with uv.
Yeah, me too.
Definitely, definitely.
You know what else is fun?
A joke.
Yeah, let's do a joke.
All right.
This one celebrates, in quotes, getting a job or not getting a job.
And it's entitled, The Long Path to Rejection, in parentheses, for software developers.
So for a normal person, this might be really short.
Send a CV.
Get rejected.
And it has this graphic of stepping on a rake.
Whack.
You know, the face is like, oh.
And then, for the software engineer, you got to do more.
It shows him, like, kind of, this is for you, Brian, like, kind of grinding a rail on a rake
instead of a skateboard.
Send a CV.
Interview with HR.
Interview with the developers.
Technical interview.
Whack.
Get rejected.
This is great.
He's doing a kickflip all the way down the stairs with a rake.
And then gets rejected.
And then get rejected.
I think that would be enough, wouldn't you?
Yeah.
But somehow, somehow it is not.
Yeah.
I never mastered the kickflip, Uli.
But I did master trying the kickflip, Uli, and falling down and getting lots of blood from that.
I mastered the amazing back landing when you go on the skateboard.
Whoop!
And it shoots out in frontwards.
You just land flat on your back.
Like, oh!
Yeah.
Out there yourself.
Last thought of the show.
Christian Letterman says, the default is set of tools.
Okay.
By pyproject.toml, which, you know, defaults are powerful in terms of keeping people doing that.
Yeah.
That might be the 50% maintenance people.
And, you know, to be honest, since uv came around, I don't really think about backends much anymore.
I just kind of use uv.
Yeah.
All right.
And Marco out there says, maybe this is a podcast you could start instead of testing code.
Skating code, Brian.
Skating code.
Yeah.
Skater go home and code.
Skatership.
All right.
Cool.
Bye.