Transcript #420: 90% Done in 50% of the Available Time

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

00:04 your earbuds. This is episode 420, recorded Monday, February 17th, 2025. I am Michael Kennedy.

00:11 And I'm Brian Okken.

00:12 And this episode is brought to you by us and all of our things. You can really,

00:17 really support us if you check out our courses, if you check out Brian's book,

00:20 if you're a Patreon supporter. All of those things make this possible, and we thank you for it.

00:25 If you want to connect with us, mostly blue sky is where we're flying these days,

00:29 but also Mastodon, of course. So links to all those things, all those accounts,

00:34 all six of them are on the show page in your podcast player show notes and so on.

00:37 You want to join us live? We're actually on regular time, Brian.

00:41 No daylight savings podcast time, none of that business.

00:44 No, although it's episode 420. We probably should have done a 420 episode or something.

00:49 I will, you know, probably should have. But yeah. And we have our newsletter,

00:56 which is getting better and better. And we got a bunch of positive feedback about

00:59 how people are really enjoying the new format. So it's got a TLDR quick catch up,

01:03 and then it's got some deep dives and covers things that maybe we don't even necessarily

01:07 exactly cover on the show.

01:08 Yeah. I really like the feature where it like says, if you're not familiar with this topic,

01:12 these are some links to go feed.

01:14 Yeah.

01:15 Like learn about it.

01:16 Yeah. Like to get the most out of this and kind of set the foundation.

01:18 Here's some resources for you, which is fun.

01:21 Because surprisingly, many, many, many people are new to Python who are listening.

01:26 Makes sense. But at first, that surprised me.

01:28 Yeah.

01:28 Yeah. Well, talking about what's on the show, what is on the show for our first item for

01:33 you today?

01:34 Well, I was going to do this as an extra, but actually, there's a lot to talk about here,

01:38 I think. There is a new PEP, PEP 772. That's a packaging governance process. And it's in the

01:49 draft process. So it's not decided yet, but it just was created January 21st, just recently.

01:55 Authors are Barry Warsaw, Deb Nicholson, and Bradian. And those are some pretty, I kind of trust those

02:02 people. So I'm curious to know what they're talking about. And also, didn't we already have

02:07 the PyPA, the Python Packaging Authority? So that's kind of what this is talking about a little bit.

02:14 Nothing against the PyPA, but I'm going to read a couple bits. The abstract starts with,

02:20 this PEP proposes the A Python Packaging Council with broad authority over packaging standards,

02:27 tools, and implementations. Like the Python Steering Council, the Packaging Council seeks

02:31 to exercise this authority as rarely as possible. Instead, they use the power to establish standards

02:39 processes. And then down in Motivation, it says, this is, I kind of had a chuckle when I read this,

02:45 read this. As Python Packaging has matured, several interrelated problems with the current

02:50 way of managing the technical development, decision-making, and processes have become

02:55 apparent. Yeah, yeah, they have. And I didn't realize this. There's the Python Packaging Authority

03:05 that does a lot of this work and maintains a lot of the tools, but it's not an elected thing.

03:14 It was when, let's see, it was started to take over the maintenance of pip and VirtualM from Ian Bicking,

03:23 led by Brian Rosner, Carl Meyer, and Janice Lytle. But there isn't really a formal process for this.

03:33 So maybe there is a process, but it doesn't talk about who's in the PyPA and who makes decisions and

03:40 whatnot. Then there was a Packaging Working Group. And there's interoperability standards.

03:46 And the Working Group was more focused on pip and PyPI and setup tools and some of the other efforts.

03:55 So all this is related, and it's very critical to how we use Python, is how we deal with packaging.

04:01 So I do think it's definitely time that we have a steering council sort of an idea. And I kind of

04:11 also really like this document. I was looking at the specification and the mandate and responsibilities

04:18 and what to do if somebody disappears for a while, because that happens. That model is sort of lightweight,

04:27 great. And it's a it's but also fairly covers a lot of cases. And so I was even thinking about using this

04:35 in other other situations. Other projects might want to adopt a a kind of a steering council type model.

04:44 And this might be a good model to take a look at. So anyway, I'm all up for talking about possibly

04:52 having a packaging council. So it's quite interesting, for sure. And I definitely trust the folks behind it.

05:00 It feels to me, my first impressions, I've not read anything about this. So PEP772 is new to me.

05:06 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

05:14 we, if 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.

05:22 Could there be kind of a president of the IPA that who gets elected who has kind of like veto power or you know, I mean,

05:30 I feel like the existing structures could be bolstered rather than like another external structure.

05:36 That said, it's critical, like you said, to the community. So this is probably better than better than nothing.

05:43 Although, like, I don't know, just it seems like it's going to add yet another layer of confusion.

05:47 Like, who do we talk to? Who's actually in charge of this? I don't know. What do you think?

05:50 Well, there is I mean, it does talk about the that the steering council already has a lot to deal with.

05:56 And there was a packaging working group. And basically, this would be sort of replacing and extending the working group.

06:02 There's also the core team by the core team. And how do they how are they involved?

06:06 They should probably have a say as well. Yeah.

06:09 Yeah. And but in the past, kind of we've had we've had a combination of the Python packaging authority, which isn't we don't have a process to elect people or or represent from other groups.

06:22 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.

06:35 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.

06:44 So, yeah, I think that definitely the steering council and the packaging steering council would talk with each other.

06:52 So, yeah, you would think you would definitely think anyway.

06:55 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.

07:06 I think it's an awesome, awesome database. It's so easy to run. Right.

07:11 You generally don't have to run migrations to make changes to it very fast.

07:14 Got an open source free version you can run all sorts of good stuff.

07:17 But it's been very incompatible with Django because Django has been primarily relational based.

07:23 And in particular for Django, because it leverages so much of the database to drive its batteries included features.

07:29 It really matters what the database is like, for example, my project with Court.

07:34 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.

07:41 Right. But the admin back end forms validation, all of these things are based on the database and database models in Django.

07:48 So the announcement here is the official Django MongoDB back end is now available in public preview.

07:55 Cool.

07:56 So you can install this thing and use MongoDB. You can use hierarchical documents.

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

08:12 So there's a bunch of cool features here. Let's see. What's it about?

08:15 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.

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

08:34 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.

08:40 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.

08:54 MongoDB support for query optimization. So field lookups have been replaced with aggregation calls.

08:59 So MongoDB has regular database queries, but a whole aggregation engine in there as well, where you can do kind of data science-y type stuff, right?

09:07 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.

09:16 And that gets used as well. It says it has limited advanced functionality.

09:19 Okay. And it also has aggregation pipeline support. That's the data science-y type of thing that I was talking about.

09:24 Anyway, if you're wanting to use MongoDB and you are a Django person, check it out.

09:30 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?

09:41 It's not for Django.

09:42 Yes. Yeah.

09:43 Yes. Yeah. This is a MongoDB initiative, not a Django initiative.

09:47 Okay.

09:47 Yes, exactly.

09:48 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.

09:55 It says over the last few years, Django developers have increasingly used MongoDB presenting opportunity, blah, blah, blah.

10:00 They say, look, you need to have a deep understanding of Django, how it works, its idioms, its conventions, and so on.

10:08 So they put a lot of work into like trying to make it as Django as they can, right?

10:13 So, but it is a MongoDB thing.

10:15 Yeah.

10:15 I just wanted to be clear about that.

10:17 Also, I think that's good actually, because if it's sort of a core decision, if you're going to go with Django as your application front end and then, or backend, whatever, and then, and then MongoDB backing that, how you're tying those two together, you want to rely on a project, you know, is going to stick around and be supported.

10:38 So if this is officially supported by MongoDB, that's a good thing.

10:42 So cool.

10:43 Yeah, it definitely is.

10:43 And they've been supporting their Python driver library package, whatever you're going to call it, for a long, long time.

10:48 And it's been almost perfect over the last 10 years.

10:52 There was a transition when they deprecated the ability to create async functions using decorators in Python.

11:00 It was like an at async contact.

11:02 I can't remember exactly what the decorator was, because I always thought using the async keyword was better.

11:07 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.

11:16 Right.

11:17 And so when that got taken away, they were like a few weeks behind getting that out.

11:20 And it just started failing in certain ways.

11:23 But that's the only time that I've seen any issues.

11:26 Other than that, they're updating all their stuff all the time.

11:28 So I think they're pretty good stewards of being part of the Python community is what I'm saying.

11:32 Cool.

11:33 All right.

11:33 Back to you.

11:34 I've got those are a couple of heavy topics.

11:37 I've got a lightweight one.

11:38 This comes from somebody that goes by the name of Quantum, QNTM.

11:44 And it's here.

11:46 Are they not there?

11:47 We don't know.

11:47 We don't know.

11:48 But also a sci-fi writer.

11:50 So apparently I was looking into it like, who is Quantum?

11:52 But anyway, developer philosophy.

11:55 So this is the idea was that I think it was at their work or something.

12:01 Yeah, at work a few weeks ago.

12:03 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.

12:15 So some just like tips.

12:17 And I was going through these, and I think I was like, yeah, a lot of these are good things to just remember.

12:22 So I'm going to just run through a handful of them.

12:26 There really only is a handful.

12:27 But first was avoid at all costs arriving at this scenario where a ground-up rewrite starts to look attractive.

12:36 And at first glance, I thought, oh, this is like, you know, basically, if you ever think you want to rewrite everything, don't.

12:44 Because it's way harder than it looks.

12:46 But it's not really that.

12:47 It's also 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.

13:01 And 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.

13:07 And so it's about like 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.

13:17 Because what usually happens is it doesn't get rewritten.

13:21 All the core people that used to do it just leave and go to another company.

13:25 So anyway.

13:26 Okay.

13:27 Next.

13:27 I love this.

13:28 Aim to be 90% done in 50% of the available time.

13:34 And this seems insane, right?

13:36 Except for it's the right way.

13:38 No, it's right.

13:38 It's the right thing to do.

13:40 There's a quote that I'd forgotten about that.

13:44 I love this.

13:45 It's the first 90% of the job takes 90% of the time.

13:48 The last 10% of the job takes the other 90% of the time.

13:51 Yeah.

13:54 So anyway.

13:56 And those bad at math, the joke is that there isn't 180% of the time.

14:01 You only have 100.

14:02 Anyway.

14:03 And like, anyway, just that's important to keep in mind the last little bit.

14:10 I thought this is a complete tangent.

14:13 It's like moving out of a house or an apartment.

14:15 You can get 90% of your stuff out.

14:18 And you're like, there's like a day left to get everything else out.

14:21 There's junk drawers.

14:22 Yeah.

14:22 There's junk drawers.

14:23 There's stuff in cupboards that you forgot about.

14:27 And the rest of it takes half the time.

14:29 Yeah.

14:30 People are kind of new to these situations.

14:32 They haven't done a ton of big projects.

14:34 Yeah.

14:34 You get it working.

14:36 You get it working pretty quickly.

14:38 You're like, look, it works.

14:39 But it's the error handling, the logging, the retry, the failover, the e-commerce, the email, the reset your password.

14:48 None of the stuff that actually has anything to do with the thing you're trying to build.

14:51 But it's not a product or a proper professional thing until those are all in place.

14:57 And that's like the other 90%.

14:59 Hooking up the payment system so people can actually pay you for it.

15:02 Things like that.

15:03 Yes.

15:03 All of them.

15:03 Yeah.

15:04 All of that.

15:05 And then you're like, well, now I got to deal with taxes.

15:07 Oh, my gosh.

15:07 How did we end up dealing with taxes when I was just trying to add a to-do thing to the thing?

15:13 And I got it done two months ago.

15:14 That's how it goes.

15:16 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.

15:23 Yes.

15:24 Oh, my gosh.

15:25 100% fair.

15:28 Jumping ahead a little, again, automate good practice.

15:31 And this is kind of a big one.

15:34 But this one reminded me of a time where 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.

15:46 And then you don't have to convince people to do it.

15:48 They'll just want to take the easy way.

15:50 And automation helps.

15:51 Think about.

15:52 It could be cookie cutter or copier templates.

15:56 It could be get pre-commit hooks.

15:58 It could be continuous integration.

15:59 Yeah.

16:00 There's all sorts of easy low-hanging fruit there.

16:02 Yeah.

16:03 If you want to make sure that everybody's setting up their environment correctly, write a setup script to just set things up.

16:09 Yeah.

16:10 Or Docker or whatever.

16:11 Yep.

16:11 Docker's a good idea.

16:13 Think about pathological data.

16:15 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.

16:23 The edge cases are the entire job.

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

16:33 And start with your happy path.

16:36 And at least document and test your happy path before you get into the corner cases, at least.

16:42 So, anyway.

16:43 Well, I'll jump ahead.

16:46 There's usually a simple way to write it.

16:48 Yes.

16:49 But sometimes crufty is fine.

16:51 Write code to be testable.

16:54 Yes.

16:54 And then.

16:56 Can I add one about your testing?

16:58 Just like a corollary or a lemma?

17:00 How about a lemma?

17:01 Okay.

17:02 Know when to write code that should be maintainable and know when to write throwaway code.

17:06 Yeah.

17:06 Yeah.

17:07 Definitely.

17:08 Yeah.

17:09 And, you know, whenever, when a lot of people say write code to be testable, they kind of mean that units can be testable.

17:15 And I'm, I'm, people that don't know, I'm more of a, if you can test it from the system level, that's good enough.

17:23 Then also in it's, it is insufficient for code to be provably correct.

17:27 It should be obviously visibly trivially correct.

17:31 And then I'm going to add a corollary to be, even if it's obviously visibly and trivially correct, it will fail sometimes.

17:38 So you should write a test for it.

17:40 So.

17:40 Yeah.

17:41 And another one, think about your, choose your dependencies wisely.

17:45 Right.

17:46 Channeling Armin last week.

17:48 Yeah.

17:48 Two weeks ago, last episode.

17:49 Anyway, some good things to think about.

17:51 Even if, even if I disagree with the author in a few cases, I like the, it's good.

17:56 It's a good, nice round topic list.

17:58 I see.

17:59 You're more in the classical physics, physics, not quantum.

18:02 I understand.

18:02 I'm a classicist.

18:04 Yes.

18:04 Yes, exactly.

18:05 All right.

18:06 Well, it's time for another new Python.

18:09 Very, very cool.

18:10 Love it.

18:11 So Python 3.12.13, the second maintenance release.

18:16 Yes, that's right.

18:17 Because the first one wasn't a maintenance release.

18:19 3.13.2.

18:21 3.13.2.

18:22 I don't know what word letters, numbers I use, but 3.13.2 final is out.

18:26 And there are 250 changes.

18:29 Wow.

18:29 That's a lot.

18:30 That's a lot of changes for something here.

18:32 So, you know, it's funny when you go to the blog post and you look at it, it just says,

18:36 it drives me crazy.

18:38 They link to the changes for 3.12 or 3.13 or whatever it is you're on.

18:43 They'll link to that.

18:44 And it'll say, here's what's new.

18:46 Oh, we have a new specialized interpreter feature and stuff.

18:50 And like, that's not the release notes for this one.

18:51 That's just the whole thing.

18:52 So I'm linking to the actual changelog for this one.

18:55 And you can flip through and see every single one.

18:57 And most of them are GitHub images issues.

19:00 gh-whatever, like, fixed pyreple failure when os.environment is overwritten with an invalid value.

19:07 Like, oh, okay.

19:08 I guess you can set that value to something.

19:11 It seems weird, but sure.

19:12 Anyway, you can look through here.

19:14 And probably most interesting to people would be around the security in which there's 1, 2, 3, 4, 5 different issues for security,

19:22 which even if you think Python's working fine for you, you might want to, you know, know about that kind of stuff

19:27 because that always makes me nervous.

19:29 I don't know about you.

19:29 Yeah.

19:30 Yeah.

19:30 They have a performance section.

19:31 Now they just have performance stuff mixed in throughout the other.

19:35 But there's also some performance updates.

19:36 Let's see.

19:38 And for us, Brian, all we got to do to make all of the apps, including Python Bytes, Python Byte Search, some of the other stuff,

19:45 go to the Docker container.

19:46 It has one of the words.

19:48 I have it in the show notes.

19:49 The command is just run uvvnv-python 313.

19:54 Just rebuild that Docker container, which everybody else depends on.

19:57 Rebuild all the Docker.

19:58 It can just say, you know, build everything that needs updating.

20:01 All the apps are now running the brand new version.

20:03 So that's a little bit of that automate the magic.

20:05 You don't have to change them, right?

20:06 You just like, everything depends on this base Python Docker container.

20:10 If you tell uv, which is amazing, to install the new one, then they all get it straight away.

20:14 Yeah, nice.

20:15 Yeah.

20:15 All right.

20:16 Is that all of our stuff?

20:17 I think it is.

20:18 I think it is all of them.

20:19 Yeah, extra.

20:20 Extra.

20:20 Here we are.

20:21 You got any extras?

20:22 I just have.

20:23 Yeah, I just have one.

20:25 Okay.

20:25 Pop it up.

20:26 Let's see.

20:27 I've been thinking about plugins a lot lately still with the top pytest plugin list and trying

20:35 to set up episodes, podcast episodes around them.

20:39 But the plugin list has gotten a couple updates.

20:43 February update, for example, which is the data set that I get this from is pulling from

20:50 15,000, which is plenty.

20:52 That's a pretty good set.

20:54 Yeah.

20:54 You get much more than 200 plugins and it starts getting into the weeds of stuff that's not

21:00 useful for a lot of people.

21:01 So that's good enough.

21:04 However, I was just looking for the name pytest and then a couple people reminded me that

21:11 Hypothesis has a plugin built into it, a little one to help with pytest.

21:17 And then there was another one called Syrupy, which I want to check out, which is...

21:22 I never use that one.

21:22 It's real sticky.

21:23 Yeah.

21:25 But it looks cool.

21:26 So I'm going to check that one out too.

21:27 So there is other ways I could figure out if it's a plugin.

21:32 Like I could look at the Trove classifiers and I probably should, but I'm not.

21:36 So if there is something that doesn't...

21:39 That's a plugin that doesn't have pytest in the name, let me know.

21:41 And I will add it to the list of possible inclusions.

21:45 It still goes by order.

21:47 And then I also added links to the podcast episode.

21:52 So if I've covered one of these things on a podcast episode, you can just get to the link

21:57 right from...

21:58 Oh, that's a good idea.

21:58 I like it.

21:59 And that's really what I wanted to cover.

22:02 So, yeah.

22:03 Excellent.

22:04 I got a few additional things to cover.

22:06 Not too many.

22:07 PyScript.

22:07 You know, PyScript where you can run Python, but in the browser on the front end using WebAssembly.

22:13 That's a really cool project based out of Anaconda.

22:16 They had a new release.

22:17 And primarily, this adds better support for PyGame.

22:21 So imagine this, Brian.

22:22 You create a PyGame game, and then you want to share it with people.

22:26 Back to your very original item, like packaging Python to give to somebody is tremendously hard

22:32 to do.

22:33 So especially if you're a young enthusiast creating a platformer 2D scroller game, and you build

22:39 it, and you're like, well, now how do I send it to my friends?

22:40 That's going to be frustrating, right?

22:42 So with this, you can just write it in PyGame using the PyGame CE library, and then say,

22:47 the way you get it is I publish it to Netlify or any other static site place.

22:50 Now you have the game.

22:51 Ooh, neat.

22:52 That's cool.

22:52 So anyway, give that a shout out.

22:55 Now, we also got some, remember Teacup, Teapot?

22:57 The Teapot?

22:58 Yeah.

22:59 What?

23:00 I have some follow-up.

23:02 Oh, boy.

23:03 I don't have the, I don't think I'm logged in.

23:06 I don't want to mess with logging in right now.

23:07 So we'll come back to this.

23:09 So first name is, I thought it was Michael.

23:11 Yeah.

23:12 Michael Bayon gave us some awesome follow-up on that.

23:15 But I'll do it next time, because I didn't write the notes down, and they're really long.

23:18 And I don't want to misconstrue them.

23:20 All right.

23:20 A couple things around peps.

23:22 Coming back to the peps we've talked about.

23:23 Pep.

23:24 I love the name, 2026.

23:26 It's so good.

23:26 Pep.

23:27 We have 2026, which was supposed to be calendar versioning for Python.

23:30 Yeah.

23:31 Rejected.

23:32 Sad face.

23:33 I really wish this would have, this was done by Hugo.

23:35 And I really wish it would have gone through.

23:37 Because we already have calendar versioning.

23:40 We just have that offset by 12 years.

23:42 Like calendar-ver minus 12 is what we have.

23:45 So why don't we just have calendar-ver, where it's more straightforward?

23:48 The one thing I wasn't super psyched about with this proposal was it was going to be like Python 3.26 or something.

23:54 For 2026 instead of just like 23.04, 24.04.

23:59 Instead of actually just the year, 2025, 2026.

24:02 If you're going to make it's calendar version, make it really clear, like this means the year.

24:06 You know what I mean?

24:07 Not like, oh, if I interpreted that right, that means the year.

24:09 But whatever.

24:10 It got rejected.

24:12 Well, you said 12 years, but I was thinking it's 11.

24:15 I think it's 11 years.

24:16 It's 11.

24:17 So 2025 minus 11 is 14.

24:21 That one, we're at.

24:21 Well, we're at 13.

24:22 Oh.

24:23 But we're going to have 14 at the end of the year.

24:27 Oh, my gosh.

24:28 Yeah.

24:28 I guess that is interesting.

24:30 Like, when does it actually come out, right?

24:32 Yeah.

24:32 Because, yeah.

24:33 Because, yeah.

24:34 That must have been it.

24:35 Because Brett Cannon mentioned that you can figure it out by dialing it.

24:40 It's like the spinal tap thing.

24:42 Dial it up to 11.

24:43 It goes to 11.

24:44 At the end of the year, it does, yes.

24:46 At the end of the year.

24:46 But not at the beginning of the year.

24:48 Oh.

24:48 And more importantly, not for 80% of the year.

24:51 Right?

24:51 So, anyway.

24:52 Okay.

24:53 The majority of the year.

24:53 But I still love the spinal tap angle.

24:56 So I'm here for it.

24:57 All right.

24:58 And then external wheel hosting.

25:00 This is another one of those high PA things.

25:03 PEP 759 has been withdrawn.

25:05 And it also was being put together by Barry Warsaw, who is participating in the original one that

25:11 you talked about, the Packeting Council.

25:13 Yeah.

25:14 All right.

25:14 That's it for my extras.

25:15 Okay.

25:16 Sorry, Michael.

25:17 I'll get to your T-pop follow-up next time.

25:19 I'll write down butter notes.

25:20 Or log into the right website.

25:22 Joke?

25:22 Yeah.

25:23 This is your joke.

25:24 But I'll put it on the screen for you, guys, since I already have it pulled up.

25:26 You haven't pulled up also?

25:27 Okay.

25:27 I do.

25:28 Okay.

25:28 Here we go.

25:29 So, we talked about possible calendar versioning.

25:33 And normally, we have semantic versioning.

25:36 But Bruno Roca posts, finally, a good alternative to semantic versioning is pride versioning.

25:43 Pride.

25:44 The first number is your proud version.

25:46 That's like 2.7 point whatever.

25:49 You bump that when you're proud of the release.

25:52 Right.

25:53 So, in that case, the two.

25:54 The two.

25:55 The two to three or whatever, right?

25:57 The middle one.

25:57 The middle one.

25:57 Like, you go from 2.6 to 2.7.

25:59 That's your default version.

26:01 It's just normal and okay releases and whatever.

26:03 And the last digit is the shame version.

26:06 You bump when fixing things.

26:09 You're too embarrassed to admit.

26:10 Yeah.

26:10 You know what?

26:12 I think I might have been using pride versioning.

26:13 I think I might have.

26:16 I think a lot of people use pride versioning.

26:18 So, yeah.

26:19 It's like, ah, just little fixes, whatever.

26:21 Throw it on the end.

26:22 And then releases are the middle on your right.

26:24 And then, like, something awesome is happening.

26:26 And I've been meaning to, it's on my back burner of things to do is to document random versioning.

26:32 Because I think most versioning schemes are more random than they like to admit.

26:36 Yeah.

26:37 I know.

26:38 So, anyway.

26:39 Very good.

26:39 Very good.

26:40 You know, it's interesting.

26:41 We compare this with ZeroVer.

26:43 What does it say about the ZeroVer projects?

26:45 Right?

26:46 So, this is done by Mamu Hashemi.

26:48 Yeah.

26:49 And it talks about projects that are just ridiculous in terms of how they've not released a version.

26:56 Like, React Native has had 580 releases over 10 years, but it's still zero version.

27:01 Yeah.

27:02 FastAPI has 203 releases, but it's still zero version.

27:07 Like, these guys should have some pride.

27:09 Guys and girls should have some pride in these projects.

27:11 Rough.

27:12 Wow.

27:12 Rough is on ZeroVer.

27:13 Rough.

27:14 Yeah.

27:15 Zig, the entire language is only on 0.13.

27:17 Anyway.

27:19 Pretty fun stuff.

27:20 React OS.

27:21 Oh, geez.

27:22 Anyway.

27:22 And out in the audience, Christian points out, I'm so proud when I bumped the version to one after 14 years.

27:29 Love it.

27:30 Yeah.

27:31 1.0.

27:31 Yeah.

27:32 Well done.

27:32 Well done.

27:33 Sometimes you've got to work a while until you have a lot of pride in what you're working.

27:36 But eventually, you get there.

27:37 No, I like this idea.

27:38 This is great.

27:39 This is pride versioning.

27:40 Pride versioning.

27:41 Yeah.

27:42 I like it.

27:43 All right.

27:43 Well, thanks for being here, Brian.

27:44 Thank you.

27:45 And thanks to everyone who listened.