#420 90% Done in 50% of the Available Time
27:47 Share

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 Eichen. 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

All of those things make this possible, and we thank you for it. If 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 in your podcast player show notes and so on. If 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. I will. 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 says, if you're not familiar with this topic, these are some links to go feed. Yeah. Like learn about it. Yeah. 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. Right. 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 772. That's a packaging governance process. And, yeah,

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...

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 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 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, 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 does a lot of this work and maintains a lot of the tools. But it's not an elected thing. It was when, let's see, it was started to take over the maintenance of pip and virtualenv from Ian 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 PyPA 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 PyPA

and setup tools 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

have a steering council sort of an idea. And I kind of also really like the this, 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 you know, that happens that that model is sort of lightweight and it's a, it's, but also fairly comprehensive.

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 council 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. It's quite interesting, for sure. And I definitely trust the

the folks behind it. It feels to me, this is first impressions, I've not read anything about this, so PEP 772 is new to me. It feels like we already have a lot of players managing this stuff in another extra

extra group managing it just, it seems like a lot. Like, could we, did 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 what 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 nothing. Although, I don't know, it just seems like it's going to 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? 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

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 a,

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.

MARK MANDEL: 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. You generally don't have to run migrations to make changes to it. Very fast. Got an 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. 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 backend 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 passwordless.

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 science-y type stuff.

So you can use that for a lot of the behaviors. And there's a lookup command that it

It kind of stands in for joins in MongoDB, and that gets used as well. It says it has limited advanced functionality. And it also has aggregation pipeline support. That's the data science-y type of thing that I was talking about. Anyway, if you're wanting to use MongoDB and you are a Django person, check it out. MARK MANDEL: 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, exactly. This is a MongoDB initiative, not a Django initiative. Yes, exactly. It's on mongodb.com, the people who made it are there. But they do point out that, why do they say something?

It says, over the last few years, Django developers have increasingly used MongoDB presenting an 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. But it is a MongoDB thing. Yeah, I just wanted to be clear about that. Also, I think that's good, actually, because if you

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 in

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. 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. Yeah.

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 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 and in certain ways but that's the only time that i've seen any issues other than that they're updating all their stuff all the time so i think they're pretty good stewards of yeah being part of the python community is what i'm saying cool all right back to you i've got those were a couple heavy topics i've got a lightweight one um this this comes from uh somebody that goes by the name of quantum um

qntm and it's here are they not there we don't know we don't know but um also a sci-fi writer so apparently i was looking into it like who is quantum but but

But anyway, developer philosophy. So this is 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 going through these and I think I was like, yeah, a lot of these are good things to just remember. So I'm going to just run through a handful of them. There really only is a handful. But first was avoid it.

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. It's also the commentary is around if you

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 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. Because what usually happens is it doesn't get

All the core people that used to do it just leave and go to another company. So anyway. Okay, next. I love this. Aim to be 90% done in 50% of the available time. And this seems insane, right? Except for it's the right way.

No, it's right. It's the right thing to do. There's a quote that I'd forgotten about that I love this. 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, and those bad at math, the joke is that there isn't 180% of the time you only have 100. Anyway, and like...

Anyway, just that that that's important to to keep in mind the last little bit. I thought this a complete tangent. It's like moving out of a house or an apartment. You can get 90 percent of your stuff out and you're like, there's like a day left to get everything else out. There's a junk drawer.

Yeah. There's junk drawers, there's, 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. Yeah. It's you, you get it working. You, 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, the,

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. All of them. Yeah. All of that. And then you're like, well, now I got to deal with taxes. Oh my gosh. Like, how did we end up on the, we're dealing with taxes.

when I was just trying to like add a to-do thing to the thing and I got it done two months ago, you know, like 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 less time 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 convince people to do it. They'll just want to take the easy way. And automation helps. Think about-- - 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.

Yep. 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 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.

I'll jump ahead. There's usually a simple way to write it. Yes. But sometimes crufty is fine. Write code to be testable. Yes. Can I add one about your testing? Just like a corollary or a lemma? How about a lemma? Okay. Know when to write code that should be maintainable and know when to write throwaway code. Yeah. Yeah, definitely. Okay.

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 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 in its it is insufficient for code to be provably correct. It should be obviously visibly trivially correct.

And then I'm going to 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 Armin 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 answer.

topic list. I see you're more in the classical physics, physics, not quantum. Understand. I'm a classicist. Yes. Yes, exactly. All right. Well, it's time for another new Python. Very, very cool. Love it. So Python 3.12.13, the second maintenance release. Yes, that's right. Because the first one wasn't a maintenance release. 3.13.2? 3.13.2. I don't know what letters and numbers I used, but 3.13.2 final is out.

And there are 250 changes. Wow. 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 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 specialize in 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 changelog.

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.environment is overwritten with an invalid value. Like, oh, okay, I guess you could set that thing. It seems weird, but sure. Anyway, you look through here and probably most interesting to people would be a

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. Now 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, white 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 UVV and V dash dash Python 313. Just rebuild that Docker container, which every else depends on rebuild all the Docker can just say, you know, build everything that needs updating. All the apps are now 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. MARK MANDEL: Yeah, nice. MARK MIRCHANDANI: Yeah. All right. Is that all of our stuff? MARK MANDEL: I think it is. MARK MIRCHANDANI: I think it is all of it. MARK MIRCHANDANI: Some extras? MARK MIRCHANDANI: Yeah, extra.

Actually, here we are. You got any extras? I just have-- yeah, I just have one. OK. I'll 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 couple updates, February update, for example, which is the data set that I get this from is pulling from 15,000, which is plenty. That's a pretty good set. Yeah, you get much more than 200 plugins

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 pi test. And, and then a couple people reminded me that like hypothesis has a has a plugin built into it little one to help with pi test. 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.

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 added links to the podcast episode. So if I've, 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 those are, 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 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. Yeah.

MARK MANDEL: --to do. So especially if you're a young enthusiast creating 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. MARK MIRCHANDANI: Ooh, neat. MARK MANDEL: That's cool. So anyway, give that a shout out. We also got some-- remember Teacup-- Teapot? The Teapot-- MARK MIRCHANDANI: Yeah.

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 followup on that, but I'll do it next time. Cause I didn't write the notes down and they're really long and I don't want to misconstrue them. All right. A couple of 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. Yeah. 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 calendarver minus 12 is what we have. So why don't we just have calendarver 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

like you know 23.04 24.0 instead of actually just the year 2025 2026 if you're going 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 yeah

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 going to have, but we're going to have 14 at the end of the year. So.

Oh my gosh. Yeah. I guess that is interesting. Like when does it actually come out? Right. Yeah. Cause I, yeah. Cause I, yeah, that must've been it because I, Brett Cannon mentioned that you can figure it out by dialing it. It's like the, the spinal tap thing, dial it up to 11. It goes to 11 at the end of the year. It does. Yes. At the end of the year. Yeah.

And more importantly, not for 80% of the year. So anyway, the majority of the year. But I still love the spinal tap angle. 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. Yeah. All right. That's it for my extras. Okay. Sorry, Michael. I'll get to your TPOP follow-up next time. I'll write down butter notes or log into the right website. Joke? Yeah. This is your joke, but I'll put it on the screen for you, okay, since I already have it pulled up. You have it pulled up also? Okay. All right.

I do. Okay, here we go. So we talked about possible calendar versioning, and normally we have semantic versioning. But Bruno Rocha posts, finally a good alternative to semantic versioning is pride versioning.

The first number is your proud version. That's it's like, like 2.7 point whatever you bump that when you're proud of the release. And then so in that case, the two, the two, the two to three or whatever, right? The middle one, like for you go from 26 to 27. 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. 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 on your 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

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 ZeroVer. What does it say about the ZeroVer projects? Right? So this is done by Mamamou Hashemi. And it talks about projects that are just ridiculous. Yeah.

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. Like these guys should have some pride. I think they should have some pride in these projects. Ruff? Ruff is on zero version? Ruff, yeah. Zig, the entire language is only on 0.13. Anyway. Yeah.

React OS? 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. Well done. Well done. Sometimes you got to work a while until you have a lot of pride in what you're working in, but eventually you get there. I like this idea. This is great. This is pride versioning. Pride versioning. Yeah. I like it. All right. Well, thanks for being here, Brian. Thank you. And thanks to everyone who listened. See you later.