#481 Ways to die

You can, if you've got suggestions or yeah, if you've got complaints, send to Michael, but if you have suggestions, send to either of us and the info is on the show notes, but we're on Mastodon and um and blue sky and all the all the places so um also if you're listening to this and would like to like see what we look like or watch the watch the stuff or show even show up live you can go to pythonbytes.fm live where there's a link to join the audience and during the during the recording

a lot of people sometimes people drop in questions and we'll answer them on the show that's fun and And lastly, you don't have to take notes because all of these, all of the links are, the links are in the show notes, but the links and extra information are sent out in the email newsletter. So you can subscribe at pythonbytes.fm and we will send you a whole bunch of information.

If you don't quite understand what we're talking about, there's some background information there too that will fill you in. With that, let's talk about something dumb.

So there's things like the maintainer left and the maintainer is still there. sabotage and capture, the release pipeline broke and so on. And for each one of those, there's a bunch of sub items that are really good. So for the maintainer left, I'll give you a couple of them. They're all pretty interesting. So I won't read the whole article, but I'll read off a few of them so you'll get the sense and you can come back and use this as a resource.

So under the maintainer left, we have the ghost maintainer, the simple and most common case. The last human commit is some years ago. Issues are accumulated unanswered. The repo is not archived, so it doesn't show up in any filter that would flag it. Usually the maintainer just moved on and it wasn't important enough to formally hand it over or shut it down. And it goes on a bit.

And by the way, Andrew references this weekend that Bernie research, he did, and basically went through different packaging platforms or services or whatever, like PyPI or npm and so on, and said like, well, which one of these are in an active state, a dormant state, a dead state, unknown, and has a percent dead. And PyPI actually has a very low percent dead. Conda is better. Maven is better. But everything else is worse, like quite a few others. So that's pretty interesting.

Yeah, it goes up there at like 20%. I know, that's crazy, right? So it's kind of like, let's take those and then categorize. So we went through and did a bunch of research on these and said, okay, well, why is it dead? What ways can it be dead? So there's the, just, they ghosted, right? The maintainer just ghosted. It's fine. There could be the corporate orphan. A company built and open sourced it with a team to run it.

and then pivoted or laid off the people and nobody updated it because they just, well, they're fired. That's an interesting one. There's the thesis orphan. I created this project as a PhD or master's thesis, and then I graduated and I'm done. I'm not messing with it anymore. I actually didn't enjoy it anyway. Funding cliff, similar, like it has a grant or an NSF grant or something like that. And then when the money's gone, stop and so on. Let's go on the next category.

So this one's also really common. The maintainer's still there, but there's the burnout plateau, still active by any metric you'd run. Typo fixes and dependency bumps get merged with the occasional thanks on an issue, but anything that needs actual design work or serious debugging is open indefinitely because they're just done. Custody battle, two maintainers fighting over it.

Toxic gatekeeping, you know, the person in charge of it just doesn't really want to maintain it, but also to all new incoming work. That happens a lot, I think, actually. Yeah, I think so. there's the sabotage and capture. Captured maintainer. Commit or publish access ends up with someone hostile. XZ is an elaborate version. Remember that two-year social engineering campaign that eventually talked that person into letting the person take over, but they were actually a state actor, we believe.

Addison Ware. And then we've also covered the protest where, this is bad, seems to be more JavaScript, but there it is. The legitimate maintainer deliberately breaks their own package. Colors and Faker were sabotaged by their author in 2022. LeftPad was unpublished entirely. Remember that one was pretty bad.

The platform got stranded, like chained to an end-of-the-life runtime. Python 2 only, or requires a certain node version or whatever. And related to that is the transit of death. So the project's fine, the maintainer's present willing, but something two or three levels down in its own dependency tree can't be swapped out without a rewrite, like think Python 2, right? Why did a lot of stuff not upgrade to Python 3? because something it depended upon was Python 2 only.

And so there's no way to get there. You know what I mean?

And it's one of those things of, like, we could have thrown money at it and just had a corporate, you know, a corporate entity could convert it. But we waited until a university, some university students did it. But, you know, that seems dumb. Why not throw money at it? I think for a lot of, a lot of these.

If he built it, it's amazing. I actually use this. I love Bulma and I decided to keep using it even though it's basically dead in the water because I looked around and all the other stuff. It's like Tailwind, but way less complicated. And it's going to keep working. And in five years, I'll find something else. But right now I

But for example, if I go to the pull request section, I understand what you're saying, Brian, like, oh God, there's so much work here, but he should put some kind of message that says, Hey, listen, I just can't right now. So please don't submit any PR. I don't go do work that I won't even look at.

So if you look at the PRs, like there's one, one on February 20th, one on January 20th, and there's 175 PRs without even a response to them going back, you know, way, I don't know, how far do they go back? You got a page to it, right? Like 2018. You know what I mean? And so I just feel like it kind of bugs me that there's all these people out in the world go, oh, I'm going to help improve this project.

I'm like, I'm going to add the view CLI. Like, no, you're not, because it's not going to get responded to and so on. And also there's 36 people sponsoring the project, like paying money monthly to support it. Like, I just feel like at some point you're like, just please use it, please enjoy it, but don't do extra work to it because I'm not in a space where I want to or able to work on this right now. You know, I don't know. What are you thinking on that?

But I noticed that he was hired by OpenAI almost exactly just a little bit after the last release. So he's just, I don't know if this was captured in the taxonomy, but like I've been, it is actually, I can't remember which one, but there's like one of them where, hey, if you get hired at a company that doesn't let you do open source, your projects kind of like de facto die, unless you can get someone else to do it. You know what I mean?

When you add something to your project as a requirement, you should know,

know it's being tested on the latest Python. And that's the bare minimum, I think.

And as of May, um, now of 2026, there's now three ways to create these these guys so uh he he covers um using uv pip and pdm and notes that uv is the only one that says it's in stable status uh the pip lock uh piloc tunnel generation is experimental and so is pdm experimental i didn't know pdm did it i'm not really a pdm user um but the uh yeah just uh sort of sort of running down uh how to how to create lock files with the all these tools and it's kind of just a general neat tutorial with the

recommendation of why not just use uv because it works the incantations a little magic it's uv export --format by lock Tomo with an output of pilot all hmm seems you're done I wonder if there's there are I think there's a

And I was pretty interested in before, but then I did that work where, and I wrote it up, said, we talked about it here, cutting Python web app memory by 31%. A lot of that had to do with imports and changing imports and only using heavyweight libraries when they actually executed the code that needed them. But so lazy imports, good, I think. However, lazy imports also can have incompatibilities in other issues. So this lifeguard library will go through and find those issues.

It's, I don't know if we, it's kind of an interesting juxtaposition. It has 56 GitHub stars. So it's kind of like brand new, which is fine. It's just like a linter type thing made by Facebook. So it's probably something that meta used internally and they just open sourced, you know, a couple months ago. So that's all good. Looks like it is a Rust based thing because it as a cargo folder. And that was two months ago when it was created.

I don't know when it actually came out public on GitHub, right? Because you can have a private repo and then flip it to public at some point. Anyway, it says, what are lazy points? We talked about that in ports. But it says, the idea is obviously, especially in large code bases, this both increases startup time and lowers memory usage, which is great. However, sometimes it doesn't work because there's certain Python patterns that require these things to execute immediately.

So module level side effects, like a module that registers a handler or modifies global state at import time will behave differently if its import is deferred. Think about something that sets sysstat at exit, right? So it wants to run some code at exit to unravel something. But that's only there if you call the function that causes the lazy import to load and so on, right? As opposed to the way it does now. The registry pattern. So dependency injection, I'm guessing.

A module registers itself added to a global dict that when imported will silently fail under lazy imports. Sys.modules manipulations. Code that reads and writes Sys.modules assumes that prior imports have already executed. Interesting. And metaclasses. Class creation side effects may depend on. So you can just run this against your project and it'll tell you how safe are your lazy imports. And you can't be lazy. It's a lifeguard. Looks out for you. So you don't, I guess, drown in lazy imports.

Yeah. Anyway, I just want to put that out there for people because this is coming in Python 3.15. And it's always better to go, hey, let's test our package or our application on this new version before it's actually released. Especially if you have a package other people use, right?

So it's a lot faster.

And it looks like they sort of gave up on some of those. But one of the interesting things about using straight logging was that doing structured output like JSON, like logging JSON information, is a little bit difficult. So their recommendation right off the bat is to use a project called Python JSON Logger, which I didn't know about, which you can use with the standard logging module. And it just makes logging easier.

They even have a, the same, same people that wrote the original article have a setup guide, a practical guide to setting up the JSON logger. So that's, that's cool. And especially I was thinking like, especially for API endpoints or entry points or whatever, that's important, but there's, he's JSON all over the place. So, but so just talking about comparing them all and they didn't really give an example. They actually talked about, well, they have examples, but they didn't recommend anything.

Actually, the recommendation really was use the standard logging module unless you have a reason not to because it's being supported everywhere. But I really liked the Logguru example of just how easy it looks to set up. And we've covered this before, but especially if you have a lot of people that are, you know, logging kind of looks complicated. And if you've got a small team that all understand it, that's great.

But if you have a large team, it might be easier just to have an easier logging system. And that's where I'm kind of leaning. And the setting up JSON output, you can say serialized equals true. Now, I don't know. I think that means that converts every log record to a JSON output. So that might not be. It's not logging JSON stuff. It's actually the output is a JSON thing. So you can read it somewhere else, which also might be kind of cool. But I probably won't do that.

So there's different ways the logger catches a decorator to, uh, to log exceptions, uh, nicely or into your, into whatever log file you have set up. Um, so, or logging stream or whatever. Um, and that looks neat because usually, you know, Michael does no exceptions, but if there is an exception, uh, be able to, might be nice to look at that. Anyway, kind of a good rundown of what the logging libraries look like right now and now how to do structured output.

There was a performance benchmark, which was interesting, that it compared the standard lib plus the JSON stuff with struct log and Logaroo. And Logaroo is about the same as the standard lib with JSON. And struct log is about twice as fast as in some cases. So that's interesting.

We took two and a half weeks of just grinding on translations to get it done, but there it is. I think it's going to be really great.

But German people are pretty good at English, especially tech-oriented ones. And so I was looking around and it turns out that I think Portuguese people are a little less comfortable with English than maybe German folks or I don't know, French. So I'm like, all right, then subtitles in their native language would be more helpful than not. So anyway, that's the kind of thing I'm trying to balance. So Portuguese is next.

Apparently there's a lot of like Python is one of is super popular in Brazil and other places. So excited for that. All right. So that's, that's one Spanish subtitles, not Portuguese, but Portuguese maybe in three or four weeks, something like that. And a brand new course. I'm super excited about this. Python web security is the course. And it comes in two components.

The OWASP top 10. So it goes through every one of the OWASP top 10 categories with two to three examples, sometimes in Flask, sometimes in Django, sometimes in FastAPI, the bad version, the good version, just purely learning the security issues. And then we turn it into an agentic AI course and start searching for bugs in your own code using agentic AI.

So we talked about how Mozilla found a bunch of bugs with Cloud, similar to that with some really custom OWASP and Python web app focused things. Yeah. So if you're publishing web apps or APIs on the internet, you definitely want to look at this because it basically gives you tooling and a blueprint on how to completely check your app for OWASP violations and beyond using things like Claude Code and others.

So you can, instead of hiring pen testers, you can do a first pass with this and then maybe find just a few more things. If, if you're that kind of company that can afford $25,000 or whatever for a pen test, or, you know, you could at least do this if you were going to do nothing. So I think it's really helpful. Thanks. All right. That's it for me.

And also in the percent compared with other fields, like other physical sciences, law school, medical school. So it's an interesting comparison. But in the mid 80s, it was at its height at like 36% or something were women. And it's just been going down since then. And, you know, it's leveled off in like around 2008 or something like that. But this isn't good. And so I think we need more women in computer science.

And the analysis of this was really thought that this was because of the personal computers showing up in homes. And I guess families and teachers encouraging boys to play with computers more than they taught girls. And also a commentary from one woman that when she first went into her first computer science class, she asked a question. And the professor stopped and looked at her and said, you should know that by now. But it was like the first class.

And so I actually, my wife had the same experience. She took CS101 or something like that, or a basic class in high school. And all the rest of the kids had already played with it on their Macs at home or something like that. And she was an intro. So I think we need to change this. I think hopefully it's changing because I think there's less actual personal computers in homes now than there were in the 90s. So I think maybe, hopefully it's leveled the playing field. But who knows?

I'm glad that my daughter has already taken my, has taken some Python in school, but this is bad. I mean, software is not a boys or girls thing. If anything, the women started it. So we're, we're late comers to the, to the, to the game. Anyway, we need to fix this as a community. So the, the next thing, the other thing I want to share is that I am.

You start in programming and you end in this location, right? Whereas with Python, it's got a much more diversity of sources, not necessarily people or genders, but like a diversity of different backgrounds that you come from to get into it. So I think that might have something to do with it as well, which is good.

I know we need to move on, but I remember when I was doing teaching at university, having some of the older students come in and not knowing i would i i was guilty of just expecting a lot of people to know a lot of the basics um know how to do word or excel or something like that and um and you don't people don't necessarily do that you can't assume anything really so yeah anyway um i am still working on the audio version of the uh the lean tdd book um and it's uh it's

coming along well but during in the process of doing a lot of the audio i've made some changes to the actual book. That's why I'm holding off on the official release because I want the audio and the official release to match. But a lot of changes have come in. Just, I published this morning, one of the things is separating out TDD with teams because the team aspects are different.

So I both have an emphasis on acceptance tester and development and then also how to apply those sorts of ATDD stuff to the lean concept. I also beefed up the AI chapter to talk about guardrails and security. So just a little bit. Anyway, it's coming along well. And I don't know. Who knows how long it'll take? My original plan was last January. So we'll see. Or, you know, January a few months ago. Congrats. That's awesome. Thanks. So it's still going.

Thanks to everybody that's contributed and helped out.

yes humble humbleness yes uh speaking of persistence our joke is titled stop texting me so it's just a um just a screenshot of a chat conversation somebody has clawed in their they've clawed in their iphone i think it's an i it's an iphone um on their their messages right it says claude build a one billion dollar b2b sass platform from scratch make no mistake then it says red dude for the thousandth time this is Claude from the pickleball league i am not ai

ah that's funny and then of course there's comments there are definitely comments so instead it doesn't i think i said it this way but it's not spelled out dude for the thousand time this is Claude it's not the thousandth time so someone comments is it a legal requirement that someone named Claude should be able to spell correctly. And then, yeah, I don't know. It just goes on and on. This is funny. Yeah, anyway, comments are kind of fun too.

But for the thousandth time, this is Claude from the Pickleball League. I am not AI building this.