Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 477, recorded April 20th, 2026.
I am Brian Okken.
And I'm Michael Kennedy.
And this episode is sponsored by us and you guys.
So there's a bunch of courses over at Talk Python Training.
There's pytest courses over at PythonByte, wait, Pythontest.com, my own site.
I forgot the name of it.
But thanks to everybody for the Patreon supporters and a lot of people encouraging me and grabbing copies of LeanTDD.
And I've gotten some good feedback.
So I'll plug that later in the show as well.
Yeah, if you'd like to reach out, send us topics.
One of the topics I'm covering is from somebody that sent it in.
And we really appreciate that.
So get a hold of us through Bluesky, Mastodon, or through email or the contact form on pythonbytes.fm.
And all of that info is at pythonbytes.fm.
If you are listening and you're thinking, hey, I'd like to watch this live sometime, you can just head on over to pythonbytes.fm.
Or just look around.
You can find links to watch us live on YouTube or watch the past episodes.
And finally, please join the newsletter because we send out links and information and background information.
And some people have mentioned to us before that some topics are a little over their head.
But we don't want that.
So we send you some background information so that you can understand every topic we talk about.
And with that, I'll take a rest and it'll be your turn.
You know what?
I need to take a rest too, honestly, Brian.
I've had a long weekend, big party for my wife and had a bunch of our friends in.
We rented this party van bus thing.
I drove around a bunch of wineries.
And I just need to rest.
But, you know, the Django rest type?
I don't know.
I need legit rest.
But I'm going to tell you about Django rest.
In fact, modern rest, which is a framework for Django that is type-based.
So all the classes use runtime type information to do all of their magic, right?
Not just autocomplete or blending.
And it has true async support.
So think Django Ninja-like, but with a different take, okay?
So this is a pretty cool project here.
And, you know, I just looked at it and thought, you know, this looks like something that's really fun.
It actually, one of the differences than, say, Django Ninja is it supports multiple model foundations, I guess.
So Pydantic, which is the first one listed here, which is great.
But also msgspec and Attrs.
Remember Atters?
Like Attrs is still a thing.
Yeah.
From Hennick and, you know, kind of data class style.
And one of the things that's interesting here is it says if you use msgspec, it allows you 5 to 15 times faster APIs than the alternative.
msgspec is all about ultra-compact exchange on the wire type of thing.
Okay.
Also has true support for ASGI, ASGI, async applications.
But one of the things that's interesting is it's just good old Django.
Like nothing too new.
Nothing that you wouldn't expect.
So if you're doing Django, it feels just like, yeah, that totally fits in.
There's a getting started page here, which is a little zoomed for all of us, that we can go down and sort of go through.
It's pretty interesting.
One of the things that's interesting also supports PyPy, P-Y-P-Y, not the mispronunciation of PyPy, but literally PyPy, which I think is interesting.
And Django 4.2 or above.
Hat tip to an upcoming topic.
The default recommended way to install it is uv, then Poetry, and then Pip.
So that's pretty cool.
So you've got to do things like when you install it or you set it up, you'd say, I want Django modern rest as a package bracket Pydantic or bracket adders or bracket msgspec so that you get your various dependencies installed that you're going to need.
Or, you know, just whatever.
Just put Pydantic as a dependency as well.
Then you're good to go.
Also interesting.
Remember I talked about LLMs.txt and how I added that to Talk Python so people can get better.
LLMs understand better how to work with Talk Python.
They also understand how better to work with my courses.
So this does this as well.
It has explicitly a LLMs.txt and a LLMs-full.txt.
So if you just say, hey, Claude or whatever I'm working with, I'm going to start this project.
And it's using Django modern rest, a pretty new framework.
You might not know it.
So you can actually just drop that URL and say, please read this before you begin this project and make a note that this is a resource for you.
It also has support for Context 7.
Are you familiar with Context 7?
No.
So Context 7 is, I honestly don't really know what to make of Context 7.
I thought I understood it, but I kind of don't necessarily.
But what it does is Context 7 is a website where you can enter different libraries into.
And then they parse it and turn it into something that AIs can use to understand that library better.
I'm not sure how great it works, but you come in here and it has different skills, for example.
Like it has a Django modern rest from Django rest framework skill.
So you could give it this skill and say, hey, use this agent that understands both of these frameworks because I want to upgrade from Django rest framework DRF, which has some of the craziness that we talked about last week.
Remember?
Or two weeks ago, but last episode.
Anyway, this is a pretty cool project.
Interesting.
Yeah, yeah, yeah.
It's got stuff for, hey, for mine.
Let's see what it says about it.
I don't know.
Actually, it just takes me to it.
But, you know, it's got, you can submit your own library to this, by the way.
So that's, I think, how this got here.
I think I may have submitted this and so on.
But, yeah, anyway, you can say, hey, I want AIs to understand my library better.
And this also has a MCP, which you can install.
Actually, I'm not a super huge fan of it.
I got other things that I do for this.
But, anyway, it's interesting that they explicitly went to that effort to help you get started, both converting and just working with.
All right, so let's look at this showcase.
Like, notice here, oh, actually, I gave them some short shrift here.
Look at this.
They do message spec, which is cool.
So you can do msgspec.
But they also do Pydantic, Atchers, Data Classes.
We're going to be coming back to that.
Typed Dict.
Now, that I did not see coming.
In Typed Dict.
And straight named tuples as one of your foundations, if you like.
How interesting is this?
Okay.
All right, so let's go down.
If you scroll down, I didn't want to do the, I'm going to do message.
I'll do Pydantic, whatever.
So we can go down a little bit further.
And there's a full example here.
And it just shows you, like, a one file Django thing.
So it shows you how to set up your Django app, your templates, et cetera, et cetera.
And then you just can create, you create these models for data exchange in your web app, which I think is pretty interesting.
Because a lot of people think of the model exchange to be, like, basically database classes.
But that's not really what you want.
You want, like, what does this form submit?
Or what does this API receive as data, regardless of how we store the database, right?
Yeah.
So as user create model, which just has an email, or a user response model, which just has a UUID, which is the ID of the created user, right?
So then you can create an endpoint.
And you say this thing accepts a post.
It is, you derive the class from controller of Pydantic serializer or controller of actors serializer.
And then for your signature of your function, you say, hey, I want body of user create model.
And then it automatically parses and validates that Pydantic style.
And then you just use it.
So you'll never get to your code if your Pydantic model doesn't validate, parse, all those things.
So you don't have to check that kind of stuff.
Pretty neat.
Yeah, that is cool.
Yeah.
So there's a lot more to this.
People can dig into it and explore it.
But it looks like a pretty strong contender.
If you bump over to GitHub, it's got about 1,000 stars, 100 forks.
Pretty active.
How old does it look?
A month?
No, six months.
It was created six months ago.
So I think that's still, that's pretty good growth.
1,000 stars in six months.
I mean, it's not open claw, but that's.
It looks like there's a lot of active development going on still right now.
Yeah, let's, yeah, a commit an hour ago.
Let's look at the commits.
What's going on here?
Four hours, five hours, seven hours, 11 hours.
Yeah, that's just, those are the active commits of today.
That's pretty solid, honestly.
Really good.
Yeah.
So anyway, I throw it out there as another Django area that people can pay attention to.
Another Django framework.
It's very similar to FastAPI and very similar to Django Ninja, but it seems like it's a little more flexible in the way you work with it.
Yeah.
Interesting comment here from SendPos.
Django Ninja, Django Bolt, Django Modern REST.
I guess people get back to Django and enjoy it.
Nice to see.
And I think that has, I think there's a lot to be said for using LLMs and AIs because Django's been around for a while, so they know how to deal with it.
Yeah.
Django is very well understood by AI.
So that's actually, that's actually a huge bonus in my mind.
Yeah.
Well, should we shift gears?
What's new?
Well, what's new is Python.
So.
I think it's been on for 30 years.
What are you talking about?
Well, so Python, I'm, I'm looking forward.
So there's a Hugo von Caminad.
I'm sorry.
I always mispronounce your name, but we love Hugo.
So, so 315, three, there's 315, alpha eight is out plus a release of 314, 314, 4, and also 313, 13 are out.
There's a post about that, but I, I'm looking forward to 315.
So when does 315, we're, we're looking at the status of the versions.
we get, we still have like six months to go before we can really solidify the start using it.
But, but I think that I'm excited to get started sooner anyway.
So we've got what, a beta has come out in May.
CR is in September and the final is planned for October.
But, look at it.
What, what, what's already in there all already in the alpha, we've got, explicit lazy imports.
and that we would, we've been talking about that on the show.
and that's, that's already there.
Frozen dict built-in type.
anyway, what do I have up here?
I've got, yeah, the frozen, frozen dict built-in type.
This is pretty cool to be able to, to by default do a, like a dictionary that can be used as that's hashable.
You assign it at instantiation time and, or when you define it and, and you can't change it after that.
so it's hashable.
So that's, that's pretty cool.
Yeah.
And one thing I'd like to add to this frozen dict that I think is super interesting, we've had other frozen types like set, I think, and list, but in this Python T, the free threaded
Python world, one of the things that can really unlock concurrency is not having to worry about locking on different objects.
If you work with frozen dicts, it's read only, and you can just have all the threads ram on it all at once, right?
You don't have to worry about locks once it's created.
So people just consider adopting immutable data types in general when possible.
Like if you're creating a dict, but you're not going to change it, frozen dict seems like something cool to put in place that like adds a little more security.
So like if you don't expect it to change, like you can set it up now.
So it cannot change.
Yeah.
And even things that generally we think of changing, we, you can use data flows like algorithmic stuff to do.
That's functional.
Like, like you said, it's a functional model for some part of your system that can be easily async asynced because it's all, it's all immutable types.
So yeah, pretty cool.
We got unpacking of comprehensions better.
So that's kind of fun.
Star and star star are working better for that stuff.
Let's see.
What did I have here that I wanted to talk about?
I don't remember.
Anyway.
Yeah.
Lots of great stuff.
Let's see.
Annotated type forms.
Oh, Python now uses UTF-8 as default encoding.
Can't wait for that because I'm tired of typing UTF-8.
Did you shout out lazy imports?
Yeah.
Well, explicit lazy imports.
That's, that's probably what I'm most excited about is, is being able to just say, just say lazy import Jason or lazy import whatever.
And it doesn't actually get imported until somebody actually uses it at runtime.
That's going to make, that's just such a clean interface and it's going to make everything, a lot of stuff so much faster.
In my world, it's the testing stuff because so much you, because pytest imports everything to start with and, but it doesn't need anything.
Like the tests only need this stuff when they're, the tests are actually running.
So having test runs will be a lot faster with lazy imports.
And can I add that that's a little bit of foreshadowing right there?
Is it?
It is.
Carry on.
Okay.
No, I just, just a lot, a lot of exciting stuff going on in, in 3.15 that I'm, I, I'm art.
Oh, I'm already excited to play with it.
And, and it used to be, I think like, I don't even remember how far ago it was where it was sort of hard to grab an alpha release.
But now with uv, I just said uv self update and uv Python install 3.15 and bam, I had the alpha.
So it's pretty great.
That's awesome.
Yeah.
You can even just say uv, V, E, and V, and just say, you know, dash that, like give it a version of the Python.
And if you don't have it, it'll just go and say, okay, we're getting 3.15.
Yeah.
Pretty cool.
Yeah.
Anyway, that's all I wanted to say, but just, I'm excited about 3.15.
Cool.
I am excited about 3.15 as well.
And that is because I just, I'm excited about a lot of the things there, but I'm extra excited about this, this lazy, this PEP 810 lazy imports, because I've discovered that it can make a mega
difference and it lets you write a lot of clean code, a lot of cleaner code than you would right now.
So I wrote an article that was sort of a, a guide of some project I did a couple of weeks ago.
And I would have talked about it last week, but we skipped last week because I was at a conference.
So we're talking about this week and the title of the article is cutting Python web app memory by over 31%.
And that's across the entire server, running Python bytes, running talk Python, Talk Python Training, all those things.
So I just sat down and said, you know, it's kind of ridiculous how much memory these apps use, like Talk Python Training alone.
I'm just going to focus on that, but like apply to this, to most Python web apps or APIs.
It alone was using one point, almost 1.3 gigs to run.
Like that seems a little ridiculous.
And there's a separate little search daemon process.
And it was using 700 megs.
Just chilling.
Why do you need so much memory?
Bad Python app.
Who wrote you is what I want to know.
So I set about the process of going like, at least let me understand what, where this memory is going.
And if there's any way that I could do something to make it better.
Okay.
It's not like we were running out of memory, right?
I have a 16 gig server running in the cloud and I think it was using nine or 10 gigs.
So there were six gigs left, but at the same time, it's what if I want to run other apps?
Like I want to self host something that would maybe power the web apps or, you know, be like a CRM or some other thing that I just want to run and not have to set up other infrastructure.
It'd be great if there's like, oh, there's so much RAM.
It doesn't even matter.
You know what I mean?
And RAM by far is by far more critical and scarce than CPU.
Not, you know, put this RAM crisis aside, this stuff that AI is triggering.
Just straight, you get 16 gigs RAM, you get eight CPU for most people, most workloads.
The CPU is pretty chill and the RAM is a lot higher.
You got to get a lot of traffic before CPU becomes the problem, right?
So thinking about the RAM, I think is important.
So I started working on this and said, well, what can I do?
And the starting point was 100, 1,280 megabytes.
And the little search daemon thing that I told you about that once an hour, once every day, I can't remember the schedule, I think it's a few times a day, it'll pull all the content of Talk Python training and turn it into a search engine.
So like you go over here and you're like, hey, I'm interested in, you know, taking some class.
And in your class, you can say, oh, I'm not logged in, but you could just go over and search and say, well, do you talk about pytest?
Let's see.
Well, why, yes, we do.
And it has like all these really nice, deep understanding of like the hierarchy of stuff.
It's not just like a regular search, right?
Like it's something I put together, but it's still, this is a ridiculous amount, 700 megs for something that just like reads from the database and writes to the database and otherwise is doing nothing.
So I'm like, well, how can I do this better?
The first thing I did, there's five things I'm going to talk about.
Number one is I was running two to three worker processes to scale out web requests because everything was still based on Pyramid.
It's synchronous.
It's WSGI.
I'm going to have fewer worker processes than I really want to have better concurrency in the one worker process that's there, right?
I don't want like one slow request to be just like, well, that's it.
The site's not responding, right?
Because of the kill.
I decided the first thing to do was to rewrite everything in Quart and it could be other languages, anything that's async.
I could have rewritten in FastAPI, but I really like the Flask model and Quart is the true async version of Flask, right?
So that's what I did.
And that let me turn it, turn the other worker process off, which right there just cuts your memory straight in half, right?
Because they both use the same amount of memory and there's two of them.
And you know, people think like, oh yeah, whatever.
Like Michael, your site's just a, it's just a blog.
Like dude, what are you talking about?
Like you seem to think like there's a lot going on here, but I work on a real app.
So it doesn't apply to me.
I ran my little tallyman thing against Talk Python training, not the, any of the podcasts of just the courses.
178,000 lines of Python, 300,000 lines total.
Like that's enough to like spend some time figuring out what's going on, right?
That's complicated enough for most apps I imagine, at least to be somewhat representative.
But you're like running courses and podcasts and stuff.
This is more complicated than just a blog.
Yeah, that's true.
That's true.
Yeah.
But tell Reddit that.
So then the next thing, the number two was I'm going to rewrite this in that the raw plus DC design pattern that I talked about just using straight queries, not ORMs or ODMs.
Although I have something interesting to say my extra about that, but still.
So just straight queries and then mapping data classes, or it could be pydantic or adders, right?
It doesn't really matter.
Pick a model, a simple data model.
And that actually made a pretty big difference.
That dropped 200 megs, 100 megs per worker off just switching away from an ORM to just raw queries and data classes.
Makes sense.
And it almost doubled the request per second, which is wild.
Okay.
So then number three, well, once I had done the court thing, I was able to just tell Granny and like, I want one worker or not two or three.
For a while it was three or four.
And I've been like dialing it back.
It's just got faster.
So that saved 500 megs there.
So now we're down to, yeah, we're down to 530 megs for this process.
And then for the search thing, what was happening is it would load up a bunch of imports, PEP 5, 8, 8, 10, getting exciting here.
It would load up a bunch of imports and then it would run a bunch of code that would like get all, I don't know exactly where the memory was going, but a lot of stuff that it would work with by doing, interact with the database and so on would get cached or just left in memory.
So it was using 700, 708 megs of memory.
So I said, well, what if like really the main core loop of the app is just start, look at a timer after a certain amount of time, run a really complicated set of queries, and then
write a bunch of structured data indexed back into a certain structure so I can query ultra fast, right?
That, that main part doesn't need, it was importing like all the library, like all of Talk Python training, which would pull in everything that Talk Python training's main dunder.
And it would pull in, which would pull in all the libraries that every, you know, it would cascade into this mega import.
So I said, well, what if you just had the loop and then in a separate file, you ran, you would start a process that ran that separate file that did the indexing and then stopped and like just finished, like, cause it didn't need a response.
It was like, okay, I'm done indexing.
And that temporary sub process would be the thing that did all the imports.
And when it shuts down, those imports go away.
So that took it from 708 megs to 22.
That's great.
That's insane, right?
And all I had to do is change where, sorry, go ahead.
The sub process is still getting like 700 megs or whatever, but, but it goes away.
But for like 30 seconds to a minute, not constantly.
Right.
And these spikes are, I mean, they're fine, but it's like, you know, not everything is spiking in memory at the same time, just like they don't in CPU.
It's just like, it's not a fixed cost, which is pretty interesting.
You know, the work was just like, I'm just going to do the index, move the indexing function to a new file, move the imports that it needs to a new file and just do a sub process to call it instead of calling it directly done.
Yeah.
And it made, I don't know what that division is, but like 20 times, 30 times better.
You know, it's incredible.
And the last thing, this one I think is going to surprise people.
And this is the one that really hits the point home for lazy imports.
If you type the words import Boto3, because you're doing something with S3 or something similar, your working memory goes up by 25 megs per process, per worker.
If you type the words import matplotlib, your working memory goes up by 17 megs.
If you type import pandas, your memory goes up by 44 megs.
Those three imports right there are almost a hundred megs of memory usage.
Yeah.
It's a lot.
So are they needed?
If you're doing core data science, they are.
But for me, there's like an admin section where I can go and view some reports.
If I view the reports, I run, I use these libraries, but if I don't view the reports, which I really don't look at them hardly ever, just like maybe once a month, like, Hey, I wonder what that looks like.
Let me go hit it.
It pulls all that stuff in and then it generates the report.
But the worker process recycles a couple of times a day.
Yeah.
So even if I view the report five hours later, that stuff's unloaded again and I get a new version and it's not another month until I load up that a hundred megs.
So I went from like 500 megs to 450 just by saying, well, instead of importing the top of the file, let's import in the function that generates the actual picture, you know, the report that I need from this.
And boom, a hundred megs less memory usage.
And if that had the word lazy in front of it, I wouldn't have to rewrite my code.
It would have effectively the same behavior.
It wouldn't import until I actually run the function, but I could do PEP 8 magic and put it at the top.
What do you think of that?
That's pretty cool.
So now I'm thinking that like lazy imports, it imports when it needed, but it doesn't, it doesn't ever unimport.
And I'm wondering if like a future Python will add like, you know, some, something to the lazy import that like caches stuff out of memory.
Right, right, right.
Like the runtime could see nobody is caring about it being imported anymore and no one has set a value on it.
So maybe it could just go away a hundred percent.
But that means, I mean, people I think often think of lazy import as something that's a speed, a speed up like, oh, it's faster because you don't have to do all the imports until you use them.
I'm sure that's true.
I don't have numbers around it.
But what's really interesting is there are some imports that are mega in amount, how much they actually increase your working memory.
If they're lazy and you don't use them very often, they will not run very often.
And I think it'll actually make a pretty big difference.
So, you know, like you just write code, like just do import inside the function instead of at the top.
Like your lenders will go, you shouldn't do this.
Like you leave me alone.
I'm doing this.
This is, this is really good for me.
So the final thing, I just moved a bunch of caches to disk caches instead of memory caches, which is good.
And so I put a little picture in there, but it, it saved a ton of memory across 3.2 gigs, less memory used on the server by applying that to Python bytes, talk Python and Talk Python Training.
There's a bunch of other apps, but they, oh, and the search thingy.
But yeah, those were the four big ones.
Cool.
Pretty cool, huh?
Yeah.
Yeah, it's very cool.
So a little bit long there, but I thought that people might appreciate some kind of a roadmap and how you can do that yourself.
Like, so the total savings was 190, 1,988 megabytes to 472 megabytes used across the apps.
That is a lot of difference and you can get a way, you can run more apps.
You can scale out more and get way better performance because now you can like run more workers if you really needed to or whatever.
I think there's a lot of, a lot of benefits there.
So cool.
A lot of excitement out in the audience.
They're talking about this topic.
I think it's cool.
All right.
Well, one of the things that I get excited about is testing.
You don't say.
Pick that up about me a little bit.
So I want to talk about trike right now, like as in a tricycle.
So this is a new, a new project.
And how new?
So it's got four stars, but it, I mean, it just went up like last month or something.
Very recent.
So taking a look at this, this was submitted by the person that created it, Justin Chapman.
But, but I'm, you know, I like the idea of like thinking outside the box.
So for testing.
So this is trike is a rust based Python test runner with a just style API, which is, so I'm not, I'm not familiar with just, but that's what said, said JavaScript just.
I don't remember.
Anyway, maybe.
I don't know.
I think so.
Yeah.
So yeah, you, you can tell how Python focused I am most of the time.
But so what is it going to look like?
It's let's, let's zoom in a little bit.
Getting started.
So the, it, it looks like it looks way different than by tests.
So we've got a, what a, let's say we've got a normal function that's add, for example, and we want to test that.
We'd say like with describe and add.
So with describe and then some comment with this, like your test name, I guess.
And then decorators of tests.
And then another, I think that's just a description, but it's saying.
Yeah.
First I thought it was a string that was being parsed to make it run.
Yeah.
Whereas this one plus one.
I think that's just the message that comes out.
Yeah.
It's just the test case.
And so this is a very basic, we're going to get more from Justin to describe this.
I've like reached out to him and said, this is really interesting.
I'd like to know more.
So I'm going to do more research.
I haven't really played with this yet, but, but I, but I, I'm intrigued by it.
I kind of like pytest.
pytest is, has, uses just assert.
And for async for, for things that soft asserts, I guess I use the, my pytest plugin called check, pytest check.
But this is different.
All by default, all of these are soft asserts.
So it doesn't stop the test.
You can, you can expect a lot of things.
It uses the expect keyword.
So what do we got here?
We've got a watch mode so that watches, watches to see if, if you have new things to, to test.
Native async support, fast test discovery in source testing.
So you can, the ability to just put tests right in the source code, instead of having to have a separate test.
You can do that with pytest, of course, but mostly people don't.
Doc test support, kind of like pytest.
Client server mode, which is, that's, this is an interesting one.
So the client server, they're all interesting, but this idea that you can have a server running.
So why would you do that?
So one of the things like I was just talking about for memory wise, if you run pytest, it has to import everything, imports a lot of stuff, and then you're running tests.
The server is just doing that so that it's, it's, while you're doing watching, it's, it's done that.
It's got a warm cache of everything so that, that the individual tests can go faster.
So you get client server mode, you know, pretty assertion of diagnostics.
Of course, we would expect no less from a new test framework.
So does it basically parse all, do the test discovery once and then just rerun it?
Unless, is that, is that why that, then?
I think so.
So it's doing, like, for instance, it's doing a changed mode.
Oh, like there's, I think it's for picking up new tests.
So as you're like, if you're doing test and development and you're modifying a test and modifying code, it'll pull in the stuff that changed into the, into the server.
But it can probably skip discovery or limit discovery, like the change file or something like that.
Yeah.
That's interesting.
Well, right.
And it's using, I think it's using Git information to find out which, which, which elements have been modified and are, yeah, why not?
Most people are using Git anyway.
So I think that's how it's using it anyway.
Oh, interesting.
I commented that I just sent him information about pytestCheck and, and he added that to the, Oh yeah.
Soft decisions like pytestCheck.
Pretty cool.
And I'll throw out there that I also, I'm plus one for them on the fluent API instead of the raw assert.
I really like the expect this to equals dot.
And like, you kind of like put it together as kind of an English like sentence where, you know, you can say like in list and give it an item and a list or something like, rather than, you know, just doing the exact rule.
I don't know.
I like that fluent API.
Do you?
Okay.
Yes.
Cause that's not something.
I don't know.
No, it's not weird.
It shows up a few times in a, I've seen it in a couple of different test frameworks and it's, and even some, there's a, there's a, there's an extension for unit tests to be able to do this.
And then I think I've seen pytest extensions to do this, but I, it's not something I am.
I, I could get used to it, but, it reads in English fairly well.
So yeah, that's why I like it.
It's more writing, but the truth is if your editor is not auto completing when you type two, you're probably doing it wrong, right?
You're not writing all those words, those characters you're, you're selecting them from a short list.
Yeah.
And for me, I like the readability rather than looking in a search statement and go, what is it really trying to get out with this like combination of something that resolves to a Boolean?
You can say like, you know, expect this value, like to be in the list or to not be in, you know, like something like that.
Right.
Or, yeah.
I don't know.
I like the readability of it.
I, I would just, just notice also this is made by Zensical, tie into previous conversations.
At least the website is.
So, anyway, I think that I'm, I think there's some interesting, interesting work here.
I like the async support.
I definitely want to play with this because I think that's, it's an interesting idea.
so anyway, cool, cool.
Well done.
It's very new.
We'll have to, we'll have to see where it goes.
and I sent him some, I haven't, I'm sorry, Justin, I haven't, haven't read your reply yet.
He's, he already responded to me with some questions.
I sent some questions yesterday.
kind of like I was curious about startup.
Apparently there is a setup, setup, tear down sort of fixture.
Like there is a fixture feature.
I just haven't figured it out yet.
So it's somewhere in the documentation.
so anyway, exciting things and I'll keep, keep an eye on this, keep, in, on this space.
So indeed, let me throw out a meta topic before we get to our extras, Brian, sort of inspired by this, but more broad.
I know people are hesitant to adopt new frameworks, like a new testing framework or a new web framework or a new database thing or something.
But with the agentic AI stuff that we have these days, if you pick one and you're like, Oh, it turns out it's no longer updated or I don't like it anymore or whatever, you know, it's so much easier to just go make that back into one of these or, or convert it onto the next thing.
Instead of having some huge, like, Oh no, now we've got to take, you know, two weeks and we're all rewriting the tests.
Like you probably could get two from pie dust pretty quickly.
Yeah.
We probably could.
And also, yeah, that, that, the questionable thing that the scary thing is like, like, this is pretty new.
Is it going to stick around?
Like, that, that, that's the big one.
A lot of people have excitement around something.
I was a little bit, so I took a look at this is under the Jay chap.
and he's the current CTO of a new V.
So he's got a, he's probably using this at work, with his, on his day job.
So this is a good thing.
he's contributed to ty and uv, which is kind of cool.
So that's cool.
There's some hints that maybe this will stick around and, maybe in, especially if he's using it, on a regular basis, he's probably using it and supporting it himself.
So, a little bit more.
Yeah.
So I do check these, these sort of things out.
I've seen a lot of new projects that are, probably assisted by you, AI to get created.
It might just be a fun toy for somebody.
And that's not something I really want to cover in this, on this podcast, but something that looks like maybe they're serious about it.
Yeah.
We'll cover it.
It doesn't matter.
So cool.
Yeah.
It looks very, very neat.
All right.
I've got a handful of extras.
You want to hit your extras next or go ahead.
Go ahead.
Okay.
let's see.
I, I saw this came up in a couple of newsletters and I was intrigued by an article called why aren't we uv yet?
talking about it did, did some analysis of different, not sure how they got them, but like some top Python projects, stack over.
I don't know, that, you know, uv is popular.
Why isn't it being used more?
The interesting thing, I just, I'm not, I will, we'll link to it of course, but, I think one of the reasons why this, this gap looks so big is that a lot of people with requirements.txt are, are you using, are still using UV?
we, I have a lot of projects at work that, are requirements.txt based and everybody I know, I'd like that our instructions are to use uv, that you just because it doesn't,
we're not publishing, uv lock file doesn't mean that we're not using uv.
So every single one of my projects, no, that's not true.
Almost every one single one of our, my projects has a requirements.txt and no uv lock and it's all uv.
Yeah.
So I don't know if the assumptions of this study are correct is all I'm saying.
Yeah.
That's a really good point.
I very much prefer requirements.txt with pinned stuff and like then the uv lock.
I don't know why I just do.
Well, I don't know why.
Well, right now I, I'm, I'm leaving it open for the develop, the developer to choose, if they want to use uv or not.
Yeah.
we probably get to the point where we're not making that a choice, but, anyway.
I find that requirements.txt diffs a little nicer.
It's like, it's easier to read and especially get diffs to look and go, oh yeah, okay.
This is what changed.
Whereas the uv lock has got like so much, especially with the hashes and so on that it's like, ah, you know, there's so much noise in the uv lock versus the requirements.txt.
So yeah.
But I, I'm, I, mine are pretty noisy though.
Cause I'm using like, requirements.in and, like using uv to publish a more detailed requirements.txt.
Yeah.
That's, I do the same thing, but I don't include the hashes.
Maybe I should.
I don't know.
I think according to listening when I was listening to Python bytes recently and we are supposed to save ashes there.
Okay.
what else?
the PyCon us, talk schedule is up.
if you're going, you can check it out.
One of the things that noticed that I knew, I knew as a, as a submitter, I did notice this, but there's an entire AI, channel, like what are they track an AI track?
And I don't, I don't know how I feel about that, but yeah, whatever.
I think I'm excited about it.
Honestly.
Oh yeah.
Okay.
Yeah.
I think so.
I won't be there, but everybody that does, you're going to be there.
I think you will be there in spirit and I will hand out Python bytes stickers and they will be carrying some of you with them.
Cool.
let's see.
Oh, I wasn't going to cover this, but now that I've already have it up, Justin Jackson, has a, what has technology done to us?
blog post.
I was just reading about that recently.
Oh, that's it for my, Oh, I have one other extra.
Here it is.
the lean TDD book, I hinted at that earlier.
I, in a couple of days ago, put out version 0.6.1.
I'm still on, on track.
So I, this is really close to what I want to read.
So I'm, I, when I, I'm taking a trip business trip.
And then when I get back from the business trip, I'm going to start recording the audio book for this, but I've got new, new cover art with the, little rocket.
I like rockets and, I'm pretty excited about the state of this right now.
I'm happy with the flow.
the first, the first iteration of it, I didn't enjoy reading it.
And why would I want somebody to buy a book that I'm not enjoying reading it?
But now I'm like reading it all the time.
I don't want to read other people's books anymore.
I'm, I'm liking my, anyway, enough about me.
that is my extras so far.
Awesome.
Congrats on making progress on the book.
So I was going to cover that three 14 four Python three 14 four is out, but you kind of already talked about that before.
Well, we just zoomed by 14 four though.
So I'm glad.
Yeah.
There's some nice stuff out here and I'm not going to go into detail.
It's just an extra and all those kinds of things, but there are fixes CVE such and such.
There's two, two security vulnerabilities address.
Actually three.
Sorry.
I missed one.
So at least, there's at least three security CVE things fixed and just three 14 four.
And there's a couple of other security issues as well that don't seem to have CVEs.
So that's alone.
It's probably worthwhile.
So I will instead tie back to your, why aren't we uv are, why aren't we uv yet?
And just point out that if you just type uv Python upgrade, it will do now an in place upgrade of three 14 three or two or one into three 14 four.
And so your virtual environments and all that stuff just should pick that up at the bank.
If not, at least a minimum of you can now recreate the virtual environment with it.
Yeah.
Well, not only that, any of them that you have installed, if you've got all the, all the versions of Python, you've got to install.
Well, if you say uv Python upgraded upgrades all of them.
So yeah, it's excellent.
And in true uv style, it does it in parallel because it should.
Yeah.
Actually, after you mentioned that, I just went over and clicked and did it and it's done already.
So yeah, that's awesome.
All right.
One more release.
I just want to give a shout out to you.
I've been kind of like bagging on Beanie a little bit, although I'm a huge fan of Beanie.
Bagging on Beanie.
Beanie bags.
Just saying, like, remember, I've been talking about my raw DC pattern.
Like there were two reasons I was moving to it.
One, because I think AIs are much, much better understanding raw query syntax instead of ORMs or ODMs wrapped around something, which wrapped around classes, which, and then results somehow sometimes into raw queries, like that kind of thing.
Yeah.
So I've been talking a lot about that and so on, but also that it was some of the libraries I was using were no longer updated.
And I'm like, ah, that's such a, such a hassle.
Like you looked at the releases for Beanie and you waited for that to come out.
You'd see that like seven months ago, it was like, oh yeah, we fixed a couple of things.
And then a while ago, we made some changes that introduced like some weird breaking changes, but like we kind of fixed the breaking changes later.
You know, it was not really getting a lot of love.
So there's actually a major release to Beanie that has like a ton of fixes and a ton of contributors, a ton of stuff.
So if you're using Beanie 2.1.0 is out.
You should definitely check that out.
Nice.
Yeah.
I feel like we got a joke maybe.
What do you think?
You want to take this one?
Yeah, I'll take this one.
But on the topic of updates, I am, that's one of the things with agents that I didn't realize that I was going to enjoy is that I think I want to write it, write this up for next week or the next time we record.
But the maintaining an open source project is easier now with, when you can offload some work to an agent.
I'm actually a better maintainer now than I was before.
Me too.
There have been some projects.
I'm like, gosh, that's kind of tricky.
I don't know.
It really justifies the effort.
Some people are asking for features.
I'm like, yeah, we really should support that new feature.
Hey, Claude, how hard would it be?
And that'll sketch it.
I'm like, okay, yeah, this is totally doable.
Yeah, I was doing some gardening this weekend and having an agent work for me while I was doing my own thing.
So anyway, let's have something funny.
And I was going to bring this up.
This is, I think, an April Fool's joke from Mother Duck, which is a great for their Duck DB company, I think.
Right.
Mother, they're the company behind Duck DB.
And this is like their commercial offering.
So you can run Duck DB better, basically.
Okay.
Well, they put out Human DB instead of Duck DB, Human DB.
And they did like Human Feet instead of Duck Feet.
And it says, blazingly slow, emotionally consistent.
The world's first human-powered analytical database.
Why pay for compute when Dave is right there?
This is just pretty darn fun that you can just, you can do pip install Human DB and import Human DB and do queries.
And it just, and it just like plays for you.
And it plays an audio.
Dave is squinting at this.
And it's like, yeah.
Can you actually install it?
Yeah, I did.
I did install and ran it.
And it's pretty funny.
Dave is, yeah, contacting Dave for this query.
The website is very complete about how this all works.
It's got in-brain storage, post-it indexing.
Suboptimal but colorful.
Each index is handwritten and stuck to the monitor bezel.
Yeah.
Hola processing, online analytical humans.
Eventually consistent.
Dave will get back to you.
He'll get back to you.
SLA is one business day.
Or three if it's quarter end.
Or five if Dave's on PTO.
We'll circle back.
SQL or natural language.
Yeah.
Dave learned SQL first, then English.
He understands both.
Just ask him anything.
So, yeah.
I did pip install this.
Played with it.
And it's pretty funny to watch.
Oh, you can do.
There's examples.
So, select average salary from employee where or whatever.
It just runs it.
Borrowing Gary's ledger pad from the query.
And then you have to wait for it.
The average engineering salary is somewhere between, somewhere around $87,000, give or take.
I ran those numbers using Gary's ledger pad.
But he wants it back.
So, you know, rounding.
So, I just had a lot of fun with it.
I probably spent 20 minutes playing with HumanDB a couple weeks ago.
Yeah, that's really funny.
Benchmarks.
Oh, it's got benchmarks.
So, DuckDB is 0.003 seconds.
HumanDB, two to four business hours.
Nice.
DuckDB is pennies to run.
But HumanDB is $49 a month plus snacks.
Nice.
The vibes.
Clinical versus immaculate.
Gut feeling.
A built-in gut feeling.
That's great.
Remembers your birthday.
Dave is thoughtful.
And DuckDB will not remember your birthday.
But it probably will if you put it in the database.
Anyway, that's funny.
Oh, wow.
They've got pricing.
They have an enterprise tier.
Enterprise.
Let's talk.
Unlimited human analysts.
On-call overnight human.
We'll figure out the SLA.
Dedicated Slack workspace.
Quarterly team pizza party.
This is funny.
Dave gets equity.
The $0 one for the free one.
Emotional support not guaranteed.
So, that's funny.
I wonder, can you just buy it?
Upgrade to Pro.
No.
Because it is a joke.
But it's funny when people carry it farther.
And they actually take a credit card or something.
Yeah, it's pretty funny.
I love it.
Anyway.
I have one really quick thought to close things out.
Okay.
That's a little bit practical.
For those folks out there that are interested in this, why aren't we uv yet study, you could look at the requirements.txt file.
And if it was generated with a pip compile sort of thing, a uv pip compile, it would say the command is uv pip compile.
It'll say generate with command.
And that command will start with uv.
So, you could parse the requirements.txt files and get greater visibility.
But only for the ones that pip compile, not install just unpinned versions.
Well, and also, if that's how they're, if they are generating the requirements.txt with uv.
So.
It would raise the numbers.
I don't know by how much.
Anyway.
Yeah.
Oh, also, so many projects or libraries that are not, they don't have either.
Like.
Yeah.
True.
That's true.
Libraries just have their dependencies in piproject.toml.
So, there's no, there's not uv lock or requirements.
You know.
The world's complicated, Brian.
Do you know what's not complicated?
What's that?
We are at the end of the episode.
So, thanks everybody.
I'm going to press the goodbye everybody button.
Goodbye everybody.
Bye.