Python Bytes - #420 90% Done in 50% of the Available Time

Episode Date: February 17, 2025

Topics covered in this episode: PEP 772 – Packaging governance process Official Django MongoDB Backend Now Available in Public Preview Developer Philosophy Python 3.13.2 released Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training The Complete pytest Course Patreon Supporters Connect with the hosts Michael: @[e-mail] / @mkennedy.codes (bsky) Brian: @[e-mail] / @brianokken.bsky.social Show: @[e-mail] / @pythonbytes.fm (bsky) Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Brian #1: PEP 772 – Packaging governance process draft, created 21-Jan, by Barry Warsaw, Deb Nicholson, Pradyun Gedam “As Python packaging has matured, several interrelated problems with the current way of managing the technical development, decision making and processes have become apparent.” “This PEP proposes a Python Packaging Council with broad authority over packaging standards, tools, and implementations. Like the Python Steering Council, the Packaging Council seeks to exercise this authority as rarely as possible; instead, they use this power to establish standard processes.” PEP discusses PyPA, Packaging-WG, Interoperability Standards, Python Steering Council, and Expectations of an elected Packaging Council A specification with Composition: 5 people Mandate, Responsibilities, Delegations, Process, Terms, etc. Michael #2: Official Django MongoDB Backend Now Available in Public Preview Over the last few years, Django developers have increasingly used MongoDB, presenting an opportunity for an official MongoDB-built Python package to make integrating both technologies as painless as possible. Features The ability to use Django models with confidence. Developers can use Django models to represent MongoDB documents, with support for Django forms, validations, and authentication. Django admin support. The package allows users to fire up the Django admin page as they normally would, with full support for migrations and database schema history. Native connecting from settings.py. Just as with any other database provider, developers can customize the database engine in settings.py to get MongoDB up and running. MongoDB-specific querying optimizations. Field lookups have been replaced with aggregation calls (aggregation stages and aggregate operators), JOIN operations are represented through $lookup, and it’s possible to build indexes right from Python. Limited advanced functionality. While still in development, the package already has support for time series, projections, and XOR operations. Aggregation pipeline support. Raw querying allows aggregation pipeline operators. Since aggregation is a superset of what traditional MongoDB Query API methods provide, it gives developers more functionality. Brian #3: Developer Philosophy by qntm Intended as “advice for junior developers about personal dev philosophy”, I think these are just great tips to keep in mind. The items Avoid, at all costs, arriving at a scenario where the ground-up rewrite starts to look attractive This is less about “don’t do rewrites”, but about noticing the warning signs ahead of time. Aim to be 90% done in 50% of the available time Great quote: “The first 90% of the job takes 90% of the time. The last 10% of the job takes the other 90% of the time.” Automate good practices Think about pathological data “Nobody cares about the golden path. Edge cases are our entire job.” Brian’s note: But also think about the happy path. Documenting and testing what you think of as the happy path is a testing start and helps others understand your idea of how things are supposed to work. There’s usually a simpler way to write it Write code to be testable It is insufficient for code to be provably correct; it should be obviously, visibly, trivially correct Brian’s note: Even if it’s obviously, visibly, trivially correct, it will still break. So test it anyway. Michael #4: Python 3.13.2 released Python 3.13’s second maintenance release. About 250 changes went into this update Also Python 3.12.9, Python 3.12’s ninth maintenance release already. Just 180 changes for 3.12, but it’s still worth upgrading. For us, it’s simply rebuilding our Docker base (i.e. —no-cache) with these lines: RUN curl -LsSf https://astral.sh/uv/install.sh | sh RUN --mount=type=cache,target=/root/.cache uv venv --python 3.13 /venv Extras Brian: Still thinking about pytest plugins a lot. The top pytest plugin list Has been updated for Feb Is starting to include things without “pytest” in the name, like Hypothesis and Syrupy. Eventually I’ll have to add “looking at trove classifiers” as part of the search, but for now, let me know if you’re favorite is missing. Includes T&C podcast episode links if I’ve covered it on the show. There’s 2 so far Michael: There's a new release of PyScript out. All the details are here: Highlight is new PyGame-CE support. Go play! PEP 2026 – Calendar versioning for Python rejected. :( PEP 759 – External Wheel Hosting withdrawn Joke: Pride Versioning

Hello and welcome to Python Bites where we deliver Python news and headlines directly to your earbuds. This is episode 420 recorded Monday, February 17th, 2025. I am Michael Kennedy. And I'm Brian Aiken. And this episode is brought to you by us and all of our things. You can really, really support us if you check out our courses, you check out Brian's book, if you're a Patreon supporter, all of those things make this possible and we thank you for it You want to connect with us?

Mostly blue sky is where we're flying these days, but also mastodon of course So links to all those things all those accounts all six of them are on the show page and your podcast player show notes And so on you want to join us live. We're actually on regular time Brian No daylight savings podcast time none of that business. No, although it's episode 420, we probably should have done a 420 episode or something. But oh well. I will, you know, probably should have, but yeah. And we have our newsletter,

which is getting better and better. And we got a bunch of positive feedback about how people are really enjoying the new format. So it's got a TLDR quick catch up, and then it's got some deep dives and covers things that maybe we don't even necessarily exactly cover on the show. Yeah, I really like the feature where it like says if you're not familiar with this topic, these are some links to go feed. Yeah,

like learn about. Yeah, like to get the most out of this and kind of set the foundation. Here's some resources for you, which is fun, because surprisingly, many, many, many people are new to Python who are listening. Makes sense, but at first that surprised me. Yeah. Yeah. Well, talking about what's on the show, what is on the show for our first item for you today? Well, I was going to do this as an extra, but actually there's a lot to talk about here. I think there is a new PEP, PEP 72, that's packaging governance process.

And it's in the draft process, so it's not decided yet, but it just was created January 21st, just recently. Authors are Barry Warsaw, Deb Nicholson, and Brad Yuen. And those are some pretty, I kind of trust those people. So I'm curious to know what they're talking about. And also, didn't we already have the PyPA, the Python Packaging Authority? So that's kind of what this is talking about a little bit.

Nothing against the PyPA, but I'm gonna read a couple bits. The abstract starts with, this PEP proposes the APython Pack packaging council with broad authority over packaging standards tools and Implementations like the Python steering council the packaging council seeks to exercise this authority as rarely as possible Instead they use the power to establish standards processes and then down in motivation it says This is I kind of had a chuckle when I read this,

as Python packaging has matured several interrelated problems with the current way of managing the technical development, decision making, and processes have become apparent. Yeah, yeah, they have. And I didn't realize this, there's the Python packaging authority that that that does a lot of this work and maintains a lot of the tools. But it's not an, it's, it's

not an elected thing. It's, it was when, let's see, it was started to take over the the maintenance of pip and virtual and when from Ian Bickling, Bicking, led by Brian Rosner, Carl Meyer, and Janice Lytle. But there isn't really a formal process for this. So maybe there is a process, but it doesn't talk about who's in the PIPA and who makes decisions and whatnot. Then there was a packaging working group. and there's interoperability standards. And the working group was more focused on PIP and PyPI and SetupTools and some of the other efforts. So all this is related and it's very critical

to how we use Python is how we deal with packaging. So I do think it's definitely time that we have a steering council sort of an idea. And I kind of also really like this document. I was looking at the specification and then the mandate and responsibilities and what to do if somebody disappears for a while, because that happens.

That model is sort of lightweight, but also fairly covers a lot of cases. And so I was even thinking about using this in other situations. Other projects might want to adopt a kind of a steering cancel type model. And this might be a good model to take a look at. So anyway, I'm all up for talking about possibly

having a packaging council. So. It's quite interesting for sure. And I definitely trust the folks behind it. It feels to me, this is first impressions, I've not read anything about this. So pep772 is new to me. It feels like me, this is first impressions, I've not read anything about this. So pep772 is new to me. It feels like we already have a lot of players managing this stuff and another

extra group managing it. Just, it seems like a lot. Like could we, could we have somebody, maybe the steering council itself has more authority over packaging. It seems like they kind of would actually since they oversee Python. Could there be like kind of a president of the PyPA that who gets elected who has kind of like veto power or something? You know, I mean, I feel like the existing structures could be bolstered rather than like another external structure. That said, it's critical, like you said, to the community. So this is probably better than better than nothing.

Although like, I don't know, it just it seems like it's gonna add yet another layer of Confusion like who do we talk to who's actually in charge of this? I don't know. What do you think? um, well there is I mean it does talk about the That the steering council already has a lot to deal with and there was a packaging working group And basically this would be sort of replacing and extending the working group There's also the core team, Python core team, and how are they involved? They should probably have a say as well, yeah.

Yeah, but in the past, kind of we've had a combination of the Python packaging authority, which isn't, we don't have a process to elect people or represent from other groups. And then also, I think a lot of it was just talking with some of the people that led things like talking with whoever's using, you know, creating, you know, hatchling and the person behind flit and things. And if that's really the right, I mean, those people should have a say, but I don't think that they should have an overly large

say in what affects all of Python. So yeah, I think that definitely the Python Steering Council and the Packaging Steering Council would talk with each other. So yeah, you would think you would definitely think anyway. So awesome. All right. Well, on to my first item. It's the marriage of Django and MongoDB, which I'm a huge fan of MongoDB. I think it's an awesome, awesome database. It's so easy to run, right? You generally don't have to run migrations to make changes to it.

Very fast, gonna open source free version you can run. All sorts of good stuff, but it's been very incompatible with Django because Django has been primarily relational based. And in particular for Django, because it leverages so much of the database to drive its batteries included features, it really matters what the database is.

Like for example, my project with Court, it doesn't matter what database I use. I mean, I have to use it, but it doesn't affect anything about how I write the code or how plugins or anything work, right? But the admin backend, forms, validation, all of these things are based on the database and database models in Django.

So the announcement here is the official Django MongoDB backend is now available in public preview. Cool. So you can install this thing and use MongoDB. You can use hierarchical documents. You can use all those things. But when you try to use the Django features like forms, like admin back-end and so on, they just work

because this thing manages the go-between. So there's a bunch of cool features here. Let's see, what's it about? It says the ability to use Django models with confidence. Developers can use Django models to represent MongoDB documents with support for Django forms, validation, and authentication. Excellent. Admin support, like I mentioned. The package allows users to fire up Django admin page as they normally would with full support for migrations

and database schema history. Cool. I know I said you don't really need migrations. You technically can run them if you really want to super transform your data, but it's just less needed. Native connecting from settings.py, just as with any other database provider,

developers can customize the database engine settings like replication, write concerns, cluster sharding, probably all that kind of stuff. MongoDB support for query optimization. So field lookups have been replaced with aggregation calls. So MongoDB has regular database queries, but a whole aggregation engine in there as well, where you can do kind of data sciencey type stuff right so you can use that

for a lot of the behaviors and there's a lookup command that it kind of stands in for joins in MongoDB and that gets used as well. It says it has limited advanced functionality okay and also has aggregation pipeline support that's the data sciencey type of thing that I was talking about. Anyway, if you're wanting to use MongoDB and you're a Django person, check it out. So I got a question. So this, I think I know the answer, but when we say official Django MongoDB backend, it's official per MongoDB, right? It's not per Django.

Yes. Yeah. Yeah. This is a MongoDB initiative, not a Django initiative. Okay. Yes, exactly. Yeah. It's on MongoDB.com. Like the people made it are there, but they do point out that, you know, like it's somewhere they say something. Um, it says over the last few years, Django developers have increasingly used MongoDB presenting opportunity, blah, blah, blah. They say, look, you need to have a deep understanding of Django, how it works, its idioms, its conventions, and so on. So they put a lot of work into trying to make it as Django as they can, right? But it is a MongoDB thing.

Yeah, I just wanted to be clear about that. Also, I think that's good actually, because it's sort of a core decision. If you're going to go with Django as your application front end, and then, or back end, whatever, and then MongoDB backing that, how you're tying those two together, you wanna rely on a project you know

is gonna stick around and be supported. So if this is officially supported by MongoDB, that's a good thing, so, cool. Yeah, it definitely is. And they've been supporting their Python driver, library package, whatever you want to call it, for a long, long time. And it's been almost perfect over the last 10 years. There was a transition when they deprecated the ability to create async functions using decorators in Python. It was like an at async contact. I can't remember exactly

what the decorator was because I always thought using the async keyword was better. But in 3.4, I think there was a way to use, to describe a function as async without using the async and await keywords because they didn't exist, right? And so when that got taken away, they were like a few weeks behind getting that out and it just started failing in certain ways.

But that's the only time that I've seen any issues other than that they're updating and all their stuff all the time. So I think they're pretty good stewards of being part of the Python community is what I'm saying. Cool. All right, back to you. I've got those are a couple of heavy topics. I've got a lightweight one. This comes from somebody that goes by the name of Quantum QNTM. Are they here? Are they not there? We don't know.

We don't know. But also a sci-fi writer, so apparently I was looking into it like, who is Quantum? But anyway, developer philosophy. So the idea was that I think it was at their work or something. Yeah, at work a few weeks ago, they had a talk where they wanted to take some senior developers, including this person, and present for five minutes some personal software development philosophies for junior developers.

So some just like tips. And I was like going through these and I think, and I was like, yeah, a lot of these are good things to just remember. So I'm gonna just run through a handful of them. There really only is a handful. But first was avoid, avoid at all cost arriving at this scenario where a ground up rewrite starts to look attractive.

And at first glance, I thought, oh, this is like, you know, basically, if you ever think you want to rewrite everything, don't, because it's way harder than it looks. But it's not really that. The commentary is around, if you got to that point, there were a whole bunch of decisions along the way where people could have seen red flags and said, we're adding something horrible to this system. Let's maybe back up and do it a little bit more carefully so that we don't have

to rewrite it in the future. And so it's about thinking about that warning signs of watching for technical debt and cleaning up as you go along instead of waiting till the end and you're ready to throw it away. Because what usually happens is it doesn't get rewritten. All the core people that used to do it just leave and go to another company. So anyway, um, okay. Next. Um, I love this aim to be 90% done at the 50 at in 50% of the available time. And this seems insane, right? Except for it's the row. No, it's right. It's the right thing to do. Um, there's a, the quote that I'd forgotten about that. I love this. It's, It's the first 90% of the job takes 90% of the time. The

last 10% of the job takes the other 90% of the time. Yeah. So anyway, in those bad at math, the joke is that there isn't a hundred 80% of the time you only have 100. Anyway, that's important to keep in mind the last little bit. I thought this complete tangent, it's like moving out of a house or an apartment. You can get 90% of your stuff out and you're like, there's like a day left to get everything else out. There's junk drawer. Yeah, there's junk drawers. There's stuff in cupboards that you forgot about and the rest of it takes half the time.

Yeah. People are kind of new to these situations. They haven't done a ton of big projects. You get it working. You get it working pretty quickly. You're like, look, it works, but it's the error handling, the logging, the retry, the failover, the e-commerce, the email, the reset your password.

None of the stuff that actually has anything to do with the thing you're trying to build, but it's not a product or a proper professional thing until those are all in place. And that's like the other 90%. Hooking up the payment system so people can actually pay you for it, things like that. Yes, all of them, yeah, all of that. And then you're like, well, now we got to deal with taxes.

Oh my gosh. How did we end up dealing with taxes when I was just trying to add a to-do thing to the thing and I got it done two months ago? That's how it goes. I just saw a post the other day that said, I'm so glad that we spent so much time on parallelograms in school and not very much time on taxes. Yes. Oh my gosh. 100% fair. Okay. Jumping ahead a little again, automate good practice. And this is kind of a big one, but this one reminded me of a time where I basically in

developing processes for teams, you automate the right way to do things so that the right way to do things is the easy way. And then you don't have to right way to do things so that the right way to do things is the easy way. And then you don't have to convince people to do it. They'll just want to take the easy way. And automation helps. Think about- Right. It could be cookie cutter or copier templates. It could be get pre-commit hooks. It could be continuous integration. There's all sorts of easy low hanging fruit there. Yeah. If you want to make sure that everybody's setting up their environment correctly, write a setup script to just set things up.

Yeah. Or Docker or whatever. Yep. Docker's a good idea. Think about pathological data. I'm going to actually like, I'd like to kick this one out because I think too many people think about the, it says nobody cares about the golden path. The edge cases are the entire job. And while that's true, I think too many people think about the, it says, nobody cares about the golden path. The edge cases are the entire job. And while that's true, I think that people stop writing tests because they want to just write, they like focus on all these edge cases and start with your happy path. And at least document and test your happy path before you get into the corner cases, at least. So anyway, what I'll jump ahead.

There's usually a simple way to write it. Yes, but sometimes crafty is fine. Write code to be testable. Yes. And then- Can I add a one about your testing? Just like a corollary or a lemma. How about a lemma?

Okay. No when to write code that should be maintainable and no when to write throwaway code. Yeah. Yeah, definitely. Yeah. And you know, whenever when a lot of people say write code to be testable, they kind of mean that units can be testable. And I'm, I'm, uh, people that don't know. I'm more of a, if you can test it from the system level, that's good enough. Then also it is insufficient for code to be provably correct. It should be obviously visibly trivially correct.

And then I'm gonna add a corollary to be, even if it's obviously visibly and trivially correct, it will fail sometimes. So you should write a test for it. So, yeah. And another one, think about your, choose your dependencies wisely Right channeling arm in last week. Yeah two weeks ago last episode

Anyway, some good things to think about even if even if I disagree with the author in a few cases I like the it's good. It's a good nice round topic list. I see you're more in the classical physics physics not quantum Understand I'm a classicist. Yes. That's exactly. All right. Well, it's time for another new Python. Very, very cool. Love it. Um, so Python 3, 12, 13, the second maintenance release.

Yes, that's right. Cause the first one wasn't a maintenance release. Three, three, three, 13, two, three, 13, two. I don't know what word letters, numbers I use, but three, 13, two final is out and there are 250 changes.2. 313.2. I don't know what word letters and numbers I use, but 313.2 final is out. And there are 250 changes. Wow. That's a lot. That's a lot of changes for something here. So, you know, it's funny when you go to the blog post and you look at it, it just says, it drives me crazy. They link to the what the changes for 312 or 313 or whatever it is you're

on, they'll link to that. And it'll say, here's what's new. Oh, we have a new specialized interpreter feature and stuff and like that's not the release notes for this one, that's just the whole thing. So I'm linking to the actual change log for this one and you can flip through and see every single one and most of them are GitHub images, issues, GH dash whatever, like fixed Pyreple failure

when OS.environ environment is overwritten with an invalid value. Like, oh, OK, I guess you can set that value to something. It seems weird, but sure. Anyway, you can look through here. And probably most interesting to people would be around the security in which there's one, two, three, four, five different issues for security, which even if you think Python's working fine for you, you might want to know about that kind of stuff because that always makes me nervous.

I don't know about you. Yeah. Yeah. They have a performance section. They just have performance stuff mixed in throughout the other, but there's also some performance updates. Let's see. And for us, Brian, all we got to do to make all of the apps, including Python Bytes, Python

Bytes Search, some of the other stuff, go to the Docker container. It has one of the words, I have it in the show notes. The command is just run UVVNV dash dash Python 313. Just rebuild that Docker container, which everyone else depends on. Rebuild all the Docker can just say, you know, build everything that needs updating. All the option are running the brand new version. So that's a little bit of that automate the magic. You don't have to change them, right?

You just like, everything depends on this base Python Docker container. If you tell UV, which is amazing, to install the new one, then they all get it straight away. Nice. Yep. All right. Is that all of our stuff? I think it is.

I think it is all of it. Yeah, extra, extra. Here we are. You got any extras? I just have, yeah, I just have one. Okay. Pop it up. Let's see.

I've been thinking about plugins a lot lately, still with the top PyTest plugin list and trying to set up episodes, podcast episodes around them. But the plugin list has gotten a little, a couple updates, February update, for example, which is the data set that I get this from is pulling from 15,000, which is plenty. Because you get-

That's a pretty good set. Yeah, you get much more than 200 plugins and it starts getting into the weeds of stuff that's not very useful for a lot of people. So that's good enough. However, I did get, I was just looking for the name PyTest and then a couple people reminded me that like Hypothesis has a plug-in, the built into it little one to help with PyTest. And then there was another one

called Syrupy, which I want to check out, which is- I never use that one. It's real sticky. which I want to check out, which is. I never use that one, it's real sticky. Yeah, but it looks cool. So I'm going to check that one out too. But so there is other ways I could figure out if it's a plugin, like I could look at the Trove classifiers and I probably should, but I'm not. So if there is something that doesn't,

that's a plugin that doesn't have PyTest in the name, let me know and I will add it to the list of possible inclusions. It still goes by order. And then I also added links to the podcast episode. So if I've covered one of these things on a podcast episode, you can just get to the link right from... Oh, that's a good idea. I like it. And that's really what I wanted to cover. So yeah. Excellent. I got a few additional things to cover, not too many.

PyScript, you know, PyScript where you can run Python, but in the browser on the front end using a WebAssembly. That's a really cool project based out of Anaconda. They had a new release and primarily this adds better support for PyGame. So imagine this, Brian, you create a Pygame game and then you want to share it with people. Back to your very original item like packaging Python to give to somebody is tremendously hard to do. So especially if you're a young enthusiast creating a like a platformer 2D scroller game and you build it and you're like, well, now how do

I send it to my friends? That's going to be frustrating, right? So with this, you can just write it in Pygame using the Pygame CE library, and then say the way you get it is I publish it to Netlify or any other static site place. Now you have the game. Ooh, neat. That's cool. So anyway, give that a shout out.

We also got some, remember Teapot? The Teapot, what, I have some follow up. Oh boy, I don't have the, I don't think I'm logged in. I don't want to mess with logging in right now. So basically, we'll come back to this. So first name is... I thought it was Michael. Yeah. Michael Bayen gave us some awesome follow-up on that, but I'll do it next time because I didn't write the notes down and they're really long and I don't want to misconstrue them. All right. Couple things around PEPs. Coming back to the PEPs we've talked about. PEP, I love the name, 2026. It's so good. We have 2026, which was supposed to be calendar versioning for Python. Rejected. Sad face. I really wish this was done by Hugo and I

really wish it would have gone through because we already have calendar versioning. We just have that offset by 12 years. Like calendar ver minus 12 is what we have. So why don't we just have calendar ver where it's more straightforward. The one thing I wasn't super psyched about with this proposal was it was going to be like Python 3.26 or something for 2026 instead of just like, you know, 23.04, 24.0 instead of actually just the year 2025, 2026. If you were to make it calendar version, make it really clear, like this means the year, you know what I mean? Not like, Oh, if I interpreted that right, that means the year, 2025, 2026. If you were to make its calendar version, make it really clear, like, this means the year. You know what I mean?

Not like, oh, if I interpreted that right, that means the year. But whatever, it got rejected, so. Well, you said 12 years, but I was thinking it's 11. I think it's 11 years. It's 11. So 2025 minus 11 is, 25 minus 11 is 14. That one, we're at.

Well, we're at 13. Oh. But we're gonna have 14 at the end of the year. Oh my gosh. Yeah. I guess that is interesting. Like when does it actually come out? Right? Yeah. Because yeah, because I, yeah, that must have been it because Brett Cannon mentioned that you can figure it out by dialing it. It's like the spinal tap thing dialed up to 11. It goes to 11 at the end of the year it does, yes.

At the end of the year. But not at the beginning of the year. Oh, and more importantly, not for 80% of the year. So anyway, the majority of the year. But I still love the spinal tapping also. All right, and then external wheel hosting. This is another one of those high PA things, PEP 759 has been withdrawn.

And it's also was being put together by Barry Warsaw, who is participating in the original one that you talked about, the packaging council. All right, that's it for my extras. Sorry, Michael, I'll get to your T-pop follow up next time. I'll write down butter notes or log into the right website. Joke? This is your joke, but I'll put it on the screen for you

guys since I already have it pulled up. You haven't pulled up also? Okay. I do. Okay, here we go. So we talked about possible calendar versioning and normally we have semantic versioning, but Bruno Roca posts finally a good alternative

to semantic versioning is pride versioning. The first number is your proud version. That's like 2.7 point whatever. You bump that when you're proud of the release. And then the- Right, so in that case, the two. The two. The two to three or whatever, right? The middle one, like you go from two six to two seven, that's your default version.

It's just normal and okay releases and whatever. And the last digit is the shame version. You bump when fixing things, you're too embarrassed to admit. Yeah. So, um, you know what? I think I might've been using pride versioning. I think I might have. I think a lot of people use pride versioning. So yeah, it's like, ah, just a little fixes, whatever, throw it on the end and then releases are the middle one. You're right. And then like something awesome is happening. And I've been meaning to, it's on my back burner of things to do

is to document random versioning. Because I think most versioning schemes are more random than they like to admit. Yeah, I know. So anyway. Very good, very good. You know, it's interesting. We compare this with zero-ver.

What does it say about the zero-ver projects, right? So this is done by Mamu Hashemi, and it talks about projects that are just ridiculous in terms of how they've not released a version. Like React Native has had 580 releases over 10 years, but it's still zero version. Yeah. Fast API has 203 releases, but it's still zero version. Yeah. Uh, fast API has a hundred and 203 releases, but it's still zero version.

Like these guys should have some pride. I think I'll have some pride in these projects. Yeah. Rough is over. Rough. Yeah. Zig, the entire language is only on zero. 13.

Anyway, uh, geez. And out in the audience, Christian points out, I'm so proud when I bumped the version to one after 14 years. Love it. Yeah.

Point O. Yeah, well done. Well done. Sometimes you gotta work a while until you have a lot of pride in what you're working on. But eventually you get there. No, I like this idea. This is great.

This is pride versioning. Pride versioning, yeah. All right. I like it. All right, well, thanks for being here, Brian. Thank you. And thanks to everyone who heard, listen. See you later.