Hello and welcome to Python Byte, where we deliver Python news and headlines directly to your earbuds.
This is episode 410, recorded Monday, November 18th at 7.37 a.m.
Again, an unusual time for our live streaming, but here we are.
I am Michael Kennedy.
And I am Brian Okken.
This episode is brought to you by us, our courses, the podcast, all those things, Brian's book, etc.
Check them out. Links are in the podcast show notes there.
You can find them right in your podcast player.
And we have a standard introduction, Brian, of, hey, follow us on Mastodon.
But you know what? This is not news to you.
You created us a Python Bytes Blue Sky account. How about that?
Yeah, Blue Sky.
So you can still follow us on Mastodon. We're still very active there.
But if you're one of the many people that never really made your way to Mastodon, but decided to make your way to Blue Sky,
well then make your way over to the Python Bytes.bsky.social account where that is the jumping off point to stay in touch with all of us.
So follow the podcast there.
You can follow Brian.
He's linked in the profile there.
You can follow me over there as well.
And once you click on me, you can find Talk Python, all those things.
Follow the chain.
So follow us on Mastodon and Blue Sky.
I'm enjoying Blue Sky, Brian.
What do you think about it?
I think the default, I like it.
Also, I like that the default experience is pretty good.
Mastodon, I love Mastodon, but I had to get to, I'm using the Mona client on my iPhone, and it works.
It's a really comfortable thing, but it took me a while to get there because there really isn't, I don't, if there is a default Mastodon client, it's not great.
Yeah, there is a default one, but I tried it for a while and I switched to Mona as well.
Yeah, so.
Yeah.
I'm liking it.
If a bunch of people want to move over there, you know, we should be part of that community.
There's a ton of familiar faces.
Many of the people we talk about on the show are pretty active over there, so.
But it doesn't, you know, one thing, it doesn't have an edit feature.
When you post, you're done.
You can't edit it later.
Just prepare people, prepare to receive a lot of typos from me.
For some reason, I like type fast on my phone and I don't really look and just hit send.
That may be on me.
But I think it's bad form to call people out on typos on social media platforms.
You know, that's just.
Yeah.
Anyway.
Cool.
Indeed.
And, you know, final bits of introduction.
Check out the live show.
We don't know when it is.
Maybe Monday at 7.
You'd like to say normally.
What?
I don't remember.
No.
Well, what?
There's what we normally say is Monday at 10 a.m.
Pacific time.
But then there's what we normally do, which recently has been 7.30 a.m.
All over the place.
Yeah.
Blame Brian.
No, it's fine.
It's fine.
We'll figure out a time.
But you can always find the next episode pretty much right as this one ships.
So if you just click on there, it'll take you to YouTube.
That has the time.
Yeah.
Finally, subscribe to the newsletter.
You guys know the deal.
Handcrafted.
Artisanal.
From Brian.
By the pythonbytes.fm newsletter.
And with that, what do we got?
Let's talk about Django for a bit.
So Carlton Gibson, who was the Django fellow and has stepped, I think, last year.
I believe he did step down.
He is a Django chatter, though.
Django chat.
Yeah.
Django chat's awesome.
Another podcast.
But so he has thoughts on Django core.
And it's kind of a long article, but it's well written.
And it's talking about Django core versus Django plugins and the longevity of Django and everything.
And the whether or not batteries included and things like that and how to sustain it.
So one of the things that I guess I kind of forget that Django will be 20 years old.
Nick's birthday is 20 years ago or 20 years.
That's a pretty long time.
So it must be 19 now.
And that's a long time.
And so one of the sustainable abilities, sustainable parts is that there's lots of stuff there.
There's like this idea of the it's the web framework for perfectionists with deadlines.
And it's also the batteries included framework, but not too many batteries.
So there's a small core.
And then also talking about like a lot of people understand that the power of Django isn't really just the core.
It's that you can get something up quickly with the core, but it's the all the plugins that are available because the ecosystem is a plugin architecture.
And the so what is this talking about?
A lot of people don't realize that there's just a few people working.
I mean, it's not a huge team for how many people are using Django.
There's one and a half.
I'm trying to find it.
I like this.
Anyway, we'll get to that.
There's one and a half.
Wait, wait, we can't just go right past it.
This is a this is a this is great.
Pinky in the brain reference.
Amazing.
Yeah.
Pinky in the brain.
I love them.
OK, so G brain.
What are we going to do tonight?
Same thing we do every night.
Pinky.
Try to get our package into Django core.
This is hilarious.
So the idea is it's difficult to get features into Django core, but maybe you don't want to.
Somebody I can't remember the attribution.
It's listed in here, but somebody mentioned that core is where plugins go to die and which is a little harsh.
But I people need to understand that if you get your feature in core, it doesn't change very frequently.
Then they do.
They do a deprecation release like every two years.
So if if you want to deprecate a feature, it's two years.
If you want to add something new, it's a slow process.
There's a lot of testing involved.
It's going to be way easier to get a new feature if it's in if it's in a plugin also.
And if we look back, I mean, thinking in the future, like we might.
One example here was I'm not going to try to find it, but one example was XHTML or X.
Yeah, that's right.
XHTML.
Super awesome.
A lot of people are using it.
Should that be part of supported natively in core?
Well, we look back a few years.
It would have been like React or something.
Should should Django natively support React?
Glad they chose no.
Now, XHTML might be the next no in a few years.
We never know.
Also, yeah, there's a lot of examples around that.
Django REST framework.
I kind of forget that that's not a core thing.
That's a it's just one of the really popular plugins.
But there's like Django Ninja that is that is awesome also.
And maybe it wouldn't exist if Django REST framework was part of the core.
So the ecosystem is great.
But there is there is a tension there that I like this.
The discussion of is that Django, even the Django website doesn't like the team doesn't like to to like pick the plugins that everybody should use or the winner plugins, because that's kind of like bringing in a decor.
That's that kind of reduces the competition and the ecosystem.
But at the same time, it's hard as a beginner to jump in and say, OK, so what know really what plugins should I be using?
And there isn't a should for everybody, of course.
But I think there I guess this I enjoyed this discussion.
It's around how how should we support the ecosystem while not squelching the ecosystem?
So anyway, I I saw corollars between this and pytest as well, because pytest has the same sort of issue that it's there's a there's a core.
And there's things in the core that I wish weren't there.
And there's things that are out of the core that I think maybe should be.
And and so everybody's going to have those opinions and dealing with whether or not you sanction a plugin or not.
That's a it's a troubling thing for every every system.
So anyway, it's a it's a tough tension.
So anyway, out in the audience, we got you have any says it's great to see Django now got task you feature added.
No need for celery anymore.
Here it is.
Right.
Yeah.
It's awesome to be able to just say, no, we can run stuff asynchronously.
We don't need a mega infrastructure like maybe just an async loop or a thread or, you know.
Yeah.
On the other hand, it's it's weight that's permanently on Django now.
Right.
Yeah.
And another little comic that was in there is this is this comic of how you think happens open source apps are maintained.
And there's a picture of like tons of people hanging out, drawing on whiteboards and talking and stuff.
And the reality is one dude in a basement saying just one more ticket before I go to bed.
So.
Yeah.
Yeah, absolutely.
Let's go to the future.
Okay.
Where we're going.
We don't need roads.
We're going to go to the future pool.
This one comes to us from Pat Decker.
Thank you, Pat.
So this is an interesting idea about library that allows you to do multi processing type of work, but with asyncio.
One of the challenges with asyncio is you can overwhelm the system and it does not.
What's the term?
I think you would say it doesn't feel back pressure.
So let me give you an example.
If you're doing regular programming where you call a function in a blocks, I'm calling it writing a database query and it stays there until the response until the database gets back to you.
Right.
Well, the database is busy.
That slows down the part of the code that's calling the database.
Right.
The code is calling the part of the code that's calling database in.
It kind of backs up the entire system and slows it down.
But with asyncio, you're just sort of throwing more work at it and then carrying on.
So you can go make even more work for it.
Right.
So one of the challenges of asyncio is you can just overwhelm the system.
If you know, Hey, we really can only take 10 concurrent requests, but if it gets over that, it's going to be a problem.
It's challenging to set that limit.
Okay.
So that's kind of what this feature pool thing does.
It's, it's cool.
It's a small use case because the way that you use it, but still it's, it's cool.
So in multi-processing, this is the traditional, I create the processes because Python has this thing called the GIL and we can't really do computational parallelism.
So we're going to do it this way.
So what you can do is say, Hey, maybe we only have two cores or I only want to consume two cores or whatever.
So you can say with pool of two workers, create no more than two processes, just sort of like start processing as many requests as you have, but only take them two at a time.
As one gets done, get the next and just keep going until you're out.
Right.
Yeah.
So that's what this idea of future pool is, but for asyncio.
So you can say async with future pool of however many you want.
And then you can await future pool map, some function over some block of work.
Simple, but interesting, right?
Yeah.
And this way it will stop the caller.
Can't go on anymore.
Then while it's, it's sort of limiting.
So why do I say this is pretty limited and why, why would it be better?
How could it be better?
So this is a local little thing that you create in one function once and it, it does the work.
Also, you can't just say, run this task asynchronously.
You have to use this map reduce pattern on it.
Yeah.
Which is not a normal programming thing.
It's not like I'm calling this function.
I'm awaiting that.
I'm calling that function.
I'm awaiting that.
What would be awesome is if some way you could go and say for this program or, or this thread,
or maybe not ideal, but maybe even for this event loop, I don't care how work gets to it.
Let's limit it to five at a time.
So if a web request kicks something off, awesome.
It's, it, it goes into that thing that's limited by five concurrent requests.
If I say, await something I call, it's also participating in this, this pooling, throttling,
limiting type thing.
But asyncio, as far as I know, doesn't have that concept.
So maybe this could both be useful for some folks and motivation for someone to create
something really interesting that is a little more broadly useful.
Yeah.
It's probably dangerous to architect on the fly here, but isn't there like something that
you've used before that is async sometimes that.
Yeah.
I used unsync, U-N-S-Y-N-C, which is pretty interesting.
And that would be, that would certainly be possible to do that because what that does is that converts
or processes all the asynchronous requests everywhere into a single loop on a single background thread.
No.
Yeah.
Possibly that.
I was just thinking a similar model of you'd want to, you'd want to like give work to this,
this system.
Exactly.
And have it be async until it can't be, and then have it block.
Mm-hmm.
I see.
Yeah.
That would be great.
The problem is I think it really needs something a little bit lower level than people can build
packages for.
Yeah.
It kind of needs to be part of, you know, part of Python itself.
There is uv loop.
Part of the cohort.
Yeah.
Part of the, wait, here we go again.
So it needs to be something that is the loop itself almost as work gets added to it.
Right.
But, you know, uv loop can replace the regular asyncio loop, which is generally a good idea
when possible.
But so maybe, maybe it's, it's that level that you got to work at.
Maybe we could look, look in that realm and, and see what we could do.
Because it would be really cool to say, hey, this thing can handle all, all the concurrency
you want to throw at it, but it's only going to pass it on or you execute it more 10 at
a time or something like that.
Yeah.
Anyway.
Oh dear.
People can go to the future with future pool and check it out.
And maybe it's useful for your project.
Yeah.
It's funny.
You said uv loop and I'm like, uv has loops.
Oh no.
UV loop was a thing way before uv.
Yeah.
UV loop was a, yeah.
Magic stack, right?
UV loop's been around.
I don't know how long it's been around, but at least three years.
At least eight years.
Oh, sorry.
Yeah.
At least eight years.
So that's longer than uv.
Yeah.
Anyway.
Okay.
Yeah.
All right.
Over to you.
I want to go to an article called, from Brett Cannon, called Don't Return Named Tuples
in New APIs.
It's a simple sort of thing, but it's, it's a good thing to, to remind people of.
So first off, I want to thank Brett for using the term API in a sense of the API for a method
or for a function or for a class or module and not necessarily an API for a REST API.
We're not talking about REST APIs or web APIs, talking about good old function, just good
old APIs.
Anyway.
So the idea is named tuples are kind of awesome and they're fun because you can just in one
line say, Hey, I've got like, say a point and it's, it's cool.
And why would I return that where I turn a named tuple is because something like that, like a
point.
So that it's obvious that people can access X, Y, Z or whatever.
And, and in some things like point, it's easy to, you know, or get mouse position, you know,
it's an X, Y coordinate.
So X and Y are probably there.
However, so why, why would you not want to use this?
And he's arguing that, and I kind of agree is that it's really easy to implement something
with a named tuple.
But now you've got to support both index based index access, like a tuple or named access as
if it was a dictionary.
So having both index access and name access is probably not what you meant.
And I think I've seen this a lot of people assume once it's a named tuple, people are
going to use the name, but it's also a tuple.
So you can use it, you can slice it and I'll do all sorts of stuff.
So the, and it's really just to get around like to not have to do a class, but classes are
easier now.
So there's some alternatives to alternatives to named tuple.
You can return a data class and that would be something I'd grab possibly data class or a
dictionary, dictionary would work fine or typed dict.
The, one of the things that is nice about a typed dick is dict is that you get editor
support as well, because you've got the types defined in there.
Um, and then something new to me, which I'm going to have to play with is a simple namespace,
um, which gives us the ability to, to access the names, but, it's not indexable.
I haven't played with a namespace, simple namespace.
So I'll have to do that.
I haven't heard a simple namespace either.
And I haven't really used type dict.
Um, well, they both are good options.
I haven't either.
I like kind of jumped on the, data class, bandwagon, and use data classes a lot
now, because I do think about that is, is actually, I, I need to think about it more,
but I, I haven't really been using named tuples to return stuff.
Um, but so the, so what's the recommendation really is just be careful.
Um, and, I'll read his quote.
He said, my key point in all of this is to prefer readability and ergonomics over brevity in your
code.
Um, that means avoiding named tuples, except when you're expanding or tweaking in an existing
API where the named tuple improves over the plain tuple that is already being used.
So if you're art and that's, I guess that that's something I think I have done.
If, if you are, the return value was a tuple before it's been a tuple for a long time, there's
existing code using it, but it really should have been a named something.
Um, adding, adding a named tuple allows people to use both.
Um, and that might be ergonomically better.
The, but, the caveat really is you've got a lot of testing to do because you've got
to test both accesses now.
So, test more.
So, okay.
Awesome.
Yeah.
That's a good article blog, Brett.
No surprise there.
No surprise.
Okay.
Let's talk about a different programming language, but I think this is interesting and interesting
perspective.
Okay.
So the Zig programming language, are you familiar with Zig?
No.
I, it's kind of new to me as well.
If you go and look at some examples here, it looks, I think it looks a little like rust
like, I'm not sure, but we go down, it's, it does a lot of, simple things like
it interoperates really quickly and easily with, either C or, or windows APIs or stuff
like that.
But yeah, it looks, it looks pretty approachable, but it's a low level level, low level programming
language like here arrest.
Right.
What are those, what are all those, semicolons and curly braces doing in my code?
I know I, you probably delete them.
I don't think you really need it.
So here's the interesting thing.
They recently were spending quite a bit of money on AWS and they've decided that they would be
better off not spending their supporters money on hosting.
So for example, they said the rust foundation reports that it spends $404,000 on infrastructure
websites and stuff like that.
And probably mostly packages.
And it says, we don't really know anything about PI PI and Python.
Like what does python.org cost to run?
And mostly because that's a lot of the infrastructure costs are donated.
They said, look, as this language is growing, we don't really want for that to be our issue.
So they were getting upwards of a thousand dollars a month for their AWS bill, which is
not insane, but for an open source project.
Yeah.
It's kind of up there.
But what they said is look, zigling.org.
That's their equivalent of python.org.
It says, this is not an essential service.
It's not an emergency if it goes down and 99% uptime is perfectly fine.
It's the last 1% of uptime that represents 99% of the costs, which is pretty interesting.
So they said, look, we got a $36 Hetzner server.
Which comes with 20 terabytes.
I think 20, at least 20 terabytes of bandwidth, which is about $2,000 of AWS bandwidth included
for the $36.
And maybe someday we'll go crazy and spend a hundred or 200 bucks, but we don't need to
do more than that.
Like this, this is enough.
Right.
And so what are they doing instead?
They're saying one, they're encouraging and setting up a system that has package mirrors.
Right.
Remember we talked about that PEP that would basically sign wheels and then allow them
to be hosted somewhere else as long as the signature still matches.
So they're doing that kind of stuff from the start.
They're like, we can spread this out in a distributed style.
So no single thing has taken a huge hit.
And if it fails in one place, the equivalent of pip could say, well, let's try a mirror
or something like that, you know?
Yeah.
And yeah.
Anyway, so they're like, all right, well, 36 bucks a month.
And on top of that, what were they doing before?
AWS is what they were doing before, I believe.
So on AWS, if they wanted to push out a new website deploy, it took five minutes to push
it out, deploy, go through all the stuff just to get it up.
And on their little Hetzner server, it takes zero, takes two seconds.
It's so crazy.
To set up the job.
Yeah.
Basically to call start and then off it goes, right?
There's probably something like check every second.
There's a new job or whatever.
Anyway, I think this is a, you know, packaging is a big conversation.
Cloud, no cloud is a big conversation.
Costs and risks like the black swan of, well, what if the people backing Pythons, especially
PyPI, that infrastructure, what if they decided to stop?
Like how do you get a hundred thousand dollars a month all of a sudden?
Yeah.
You know, that's a big deal.
I think people would figure it out, but it would be a big disruption where like, okay,
what are we going to set up?
And this PEP with self-hosted wheels is like a done, a bit of a deposit down on that.
But anyway, this is interesting from a growing, but not yet super popular language.
Yeah.
Interesting.
Cool.
Indeed.
And all the curly braces and stuff were because it's mentioned by Corky that it's also interoperable
with C.
So that's interesting.
Cool.
Yeah.
It says it's more like C.
I suppose so.
It's, it's an interesting link.
All right.
Well, that's it for our main topics.
Got any extras?
I just have one extra that's going on.
I wanted to let people know about.
on, at the testing code, Python test.com.
I've got courses and, and that's, they're going well and I'm glad people are getting
value.
But I also had a community and the community have a community, but it, it used to be on Slack,
but it's one of those growth things.
Slack was, it was free on Slack and now it's not.
Um, and so we switched to a Podia based forum and it's just not fun.
So, and, I mean, great that Podia offers a forum since the courses are on Podia,
but the, I'm going to say after several months of being on Podia and only like five
comments on there, it's not, it's just not cutting it.
It's not sparking joy.
No.
So we're going to, we're going to try discord and, and so just, I guess,
hang in there, everyone.
I'm trying to trying to get it associated so that everybody has that has community access
will get access to the discord server.
And, I'll probably, I don't know what we're going to do.
I want it to be sustainable.
So it can't just be completely free.
Um, but I also want it to, and, but I want it to be something that's easy for everybody to
get into.
So I guess, just stay tuned.
Um, we'll get that all ironed out as soon as we can.
So anyway, any extras from you?
Yeah, I got a few.
It's, it's tricky, right?
You want to pick something where people already are.
Like they've got some app like Slack or discord or something open.
There's a lot of cool options that you could pick even some neat self hosted ones.
But if it's a completely different app that people have to remember to open instead of
just another tab next to the thing they're already in, I think it's, it changes it, you
know?
So there's a problem.
Like, for example, they got to go to podium versus like, oh, I'm over on this thing.
And now I just go to the next tab open to see what's happening in this community.
Yeah.
So, and I even like when I mentioned it to my, so my daughter's in healthcare, she's not
even like my oldest daughter.
And, and, and I mentioned it to her and she's like, oh, I can help you with that.
I'm on discord all the time.
I'm like, oh, okay.
Um, great.
So that's awesome.
I love it.
All right.
I got some extras.
Okay.
One, still, still living the Zen, Zen browser lifestyle.
It's, it's pretty good.
So I'm going to keep going with that.
That's fun, but that's not actually an extra.
First extra is I was on the work item podcast talking with Dan over there for an hour about
Python and business and stuff.
And people can check that out if they want.
That's fun.
Neat.
Yes.
Uh, I feel like I, let me know if I talked about this before, Brian, I searched and searched
and couldn't find it, but in my mind, we talked about, did, did I talk about the fact
that you can subscribe as an RSS to GitHub releases?
I don't know.
I don't think so.
Cause I couldn't find it in my mind.
I did.
But anyway, if you go to any release and you just type dot Adam on the end, what you get
is a popular download window instead of showing it, but it gives you an RSS feed.
So go to your project.
You like click on the releases and put dot Adam on the end.
And you can put that in your RSS feeder reader.
So that'll pop up if you like, Hey, there's a new release of this thing that I'm interested
in.
That's pretty cool.
And then let me make sure I attribution, right.
This is Jamie Thompson.
So this over and said, there's a new release of PI test BDD behavior driven design in not
just a new release, but 8.0, which is a big release.
Right.
And probably the most interesting thing is the data tables.
Have you seen these data tables?
That's neat.
It's kind of like a parameterized query, but it's also kind of like a markdown table.
Given the following users exist.
And then you just have pipe, you know, a header pipe name, pipe email, pipe Twitter,
and then values just row, row, row, row, row.
That's pretty neat.
Yeah.
All right.
So anyway, if people like their BDD, they can check out my test BDD.
That's pretty cool.
Also last week I rewrote all the code.
I did a little terminal CLI magic and there are a little over 10,000 lines of Python code
that don't involve blank space.
So meaningful lines for talk Python and Python bytes a little bit less, but not tremendously
less.
I rewrote that in court, which is asynchronous flask, which was pretty awesome.
So this thing is, is running a little more efficiently, a little bit faster, a little bit better than
it was before.
And completely rewriting 10,000 lines of code in two days is, is quite a, quite an undertaking.
You're tired at the end of that.
Let me tell you.
But it's awesome.
It came out really, really well.
I did it in two rewrites, actually.
One rewrite to just convert it from pyramid to flask, and then a second rewrite to convert
it from sync to async for almost every endpoint and all the code below it and all that, all the
database queries and stuff like that.
So did it affect like everything or did it, what were the main parts?
There were, there was, there's certain parts that it doesn't affect, but anything with database
access required it.
And then there's, there's all in, in web frameworks, when you're writing web apps, you're always
dealing with little aspects of that's frameworks API.
So I need to get the, the URL of the current request to see if I should do a redirect or
not.
Well, the way you get the URL is completely different in pyramid versus flask.
So anything that kind of touched headers, cookies, URLs, you know, if you want to know if somebody's
logged in and that's, you know, that's also a cookie, right?
There's, it's surprisingly knock on effects and flask and quartz a little bit funky in
some ways where there's this thread local requests that you can just access out of thin air,
which is cool.
Unless for some reason the call started here and it ends up over there.
Maybe there was a thread or some kind of delay where that's become disconnected that it'll
complain to you that it doesn't know what the request is, even though you have a request
object.
Like there's a lot of weird changes.
So yeah.
But anyway, it was really fun.
I'm doing a write-up on that, but I just thought I'd throw that out there and that's going
well.
Cool.
And that's it.
Shall we, shall we tell a joke?
A joke would be wonderful.
This one, we've done short form jokes and we've done long form jokes, Brian.
This might be the best long form joke.
So y'all are going to have to stick with me for just a second here, but check this out.
Here's the breaking headline.
Breaking.
JavaScript developer commits to a framework for a record-breaking three weeks.
Of course, it comes with a picture of a clown luring JavaScript developers into some shady
spot.
But let me read the press release, okay?
Simi Valley, California.
In an unprecedented display of consistency that has left the tech world reeling, local web
developer Alex Chen, 28, has reportedly stuck with the same JavaScript framework for an astonishing
three weeks.
Chen, known in the local dev circles as the framework whisperer, or his abilities to adopt
and discard JS frameworks at breakneck speeds, has been using Svelte without interruption since
August 1st, shattering his previous record of four days set with Vue.js back in 2022.
I don't know what came over me, Chen said, visibly shaken by his own stability.
I woke up one morning and I just don't feel like switching to Angular or React or that new
framework that was released during the interview.
The news has sent shockwaves through the JavaScript community.
Framework creators are reportedly in crisis mode, with one ace anonymous source from a
major tech company stating, if developers start sticking with one framework, how will
we justify our jobs?
Chen's colleagues have expressed a mix of awe and concern.
Senior developer Lisa Patel noted, I'm worried about Alex.
Yesterday, I caught him reading the documentation instead of immediately rewriting our entire
code base in a new framework.
It's not like him at all.
The unprecedented event has not been without its challenges.
Chen admitted to suffering from withdrawal symptoms, including uncontrollable urges to
create new NPM packages and a persistent eye twitch triggered by the site of a stable
well-maintained code.
Despite the difficulties, Chen remains committed to seeing this through.
Taking it one day at a time, he said, his fingers twitching as he resists the urge to type
NPX create next app.
But I've heard whispers of a revolutionary new framework that's only been downloaded 50 times.
Maybe I'll check it out, you know, just to stay informed.
Good, right?
That's funny.
Yeah.
You got to appreciate the stability.
Appreciate the stability of Django, of Python, of a lot of things that we got.
I mean, it's a joke, but it's also true that there's a lot of churn on that space.
Yeah.
I mean, like how many people here are like, should I stick with Python or should I go to
Zig now?
Yeah, I know.
Well, we might have just, we might have sent a whole bunch of people over there unintentionally.
That wasn't the intention.
I mean, Zig has a lot less.
I mean, I don't think tractor when I think Zig, but Rust kind of.
Yeah, true.
Well, and if you want to make sure you're alphabetically sorted to the very end, right by the comment
section, Zig.
Yeah.
So people just like change frameworks by the alphabet and then they turn out.
You get to the end.
They're like, well, there's nothing left to change.
They're over here.
Nice.
Well, always, always lovely to have you here.
Thanks.
Thank you.
Yep.