Python Bytes - #481 Ways to die

Episode Date: May 25, 2026

Topics covered in this episode: Dumb Ways for an Open Source Project to Die How to create a pylock.toml lockfile https://github.com/facebook/Lifeguard Choosing a Python Logging Library in 2026 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 11am 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. Michael #1: Dumb Ways for an Open Source Project to Die Core categories The maintainer left The maintainer is still there Sabotage and capture The release pipeline broke Force majeure The world moved on The project split - Examples Bulma PRs still from 2023, issues and PRs with no maintainer response for years, last release 1.5 years ago diskcache Similar, got hired by OpenAI, crickets after that Brian #2: How to create a pylock.toml lockfile Tim Hopper Tim walks through using uv, pip and pdm to create pylock.toml files. Recommendation: use uv export --format pylock.toml -o pylock.toml He also has How to install from a pylock.toml lockfile with pip but the short version is: use -r because tools treat it like a requirements file Michael #3: https://github.com/facebook/Lifeguard Lifeguard is a static analyzer to detect Lazy Imports incompatibilities and ease the adoption overhead for Lazy Imports in Python. I’m more excited about lazy imports after my Cutting Python Web App Memory Over 31% experience Some Python patterns depend on imports executing immediately. For example: Module-level side effects — a module that registers a handler or modifies global state at import time will behave differently if that import is deferred. The registry pattern — a module that registers itself (e.g., adding to a global dict) when imported will silently fail to register under Lazy Imports. sys.modules manipulation — code that reads or writes sys.modules assumes prior imports have already executed. Metaclasses and __init_subclass__ — class creation side effects may depend on imports being resolved. Project Stage: Beta Lifeguard is in active development. We are aiming to be ready for general use by the Python 3.15 final release. Brian #4: Choosing a Python Logging Library in 2026 Ayooluwa Isaiah " which libraries matter, how they compare, where they overlap with the standard module, and when each one makes sense.” The slant with this article is the need to log json output, which seems reasonable as things like API entry and exit point logging will include json. Covered libraries standard library logging with a hat tip to python-json-logger Same site has a guide to setting up python-json-logger structlog Loguru Logbook picologging Some benchmarks with structlog, stdlib+json, and Loguru, with structlog coming out faster I liked the Loguru example I’m going to have to try @logger.catch and logger.exception() for easily logging exceptions and serialize=True to enable JSON output. Extras Brian: When Women Stopped Coding - Planet Money segment , spotted on BlueSky from Savannah Ostrowski Lean TDD is now leaner Still working on audio version, but some great changes in 0.7.1 version Ch 6, TDD Interpretations, move ATDD and some of BDD to chapter Ch 7, Change name to TDD with Teams: BDD and ATDD Ch 9, Lean TDD, streamline steps and chapter Ch 10, Change name to Lean TDD with Teams: Lean ATDD Ch 11, Lean TDD with AI, Add short discussion about guardrails and security Michael: New course: Python Web Security: OWASP Top 10 with Agentic AI All courses now with Spanish subtitles, see announcement Joke: Stop texting me

Hello and welcome to Python Bytes where we deliver Python news and headlines directly to your earbuds. This is episode 481 recorded May 25th, May 25th, 26, not 1926. And I am Brian Akin. I'm Michael Kennedy. And this show is sponsored by us. Check out the all the Talk Python training courses, the Pytist course. So and thanks to Patreon supporters and also we both written books. So check out books also. And I'll have a little bit of news on the Lean TDD later. We both have something fresh for people that if they want to support us, they can check it out. Something fresh.

Yeah. 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 it's, we're on Massadon and Blue Sky and all the places. So 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.fm. Where there's a link to join the audience. And during the recording, a lot of people, sometimes people drop in questions and we'll answer them on the show. That's fun.

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

Dumb ways to die. Dumb ways for open source projects to die. Oh, and let me count the ways. This one is by Andrew Nesbitt. It's an article. It's a taxonomy, I suppose, is the way you would put it. Pretty interesting. I think it creates some interesting.

ways to talk about and think about just open source projects and supply chain, not mostly not security, although a little bit security, but also just stability, right? So this taxonomy is broken into a two level tree. So there's things like the maintainer left and the maintainer's 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 accumulating 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 Pi Pi 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 PiPi actually has a very low percent dead. Konda is better, Maven is better, but everything else is worse, like quite a few others. So that's pretty interesting.

Yeah, it goes. They're like 20%. I know, that's crazy, right? So it's kind of like, let's take those and then categorize. So 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 is 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 year master's thesis. And then I graduated and I'm done.

I'm not messing with it anymore. 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 hostile to all new incoming work.

That happens a lot, I think, actually. Yeah, I think so. There's the sabotage and capture, captured maintainer, and commit or publish access ends up with someone hostile. XZ is an elaborate version. Remember that two-year social engineering campaign? Yeah. that eventually talked that person into letting the person take over,

but they were actually a state actor, we believe. Addisn't where. 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. Left pad was unpublished entirely.

Remember that one was pretty bad. That was funny. Why is there an entire package that just left pads a string? Like, that's all it does. You know, it's just too fine green. All right. The release pipeline broke, a bunch of stuff around that. Force majeure, like, sanctions.

Some people's accounts have been shut down or blocked because they've been frozen under export controls or other things like that or taken down because of DMCA. The world moved on. This one, we know well from the Python world. 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 willy, 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? Yeah. API Rugpole, I've seen this, like, hey, I depend upon, I wrote something that wraps, like, let's say the Reddit's API or Twitter API, and then those APIs go away, and guess what?

your app or library doesn't work. Or it's just superseded, right? Like there's no reason to do a thing if it's now part of the language or something like that. Project split, yeah, that's pretty much it. Licensing. So what do you think? That's pretty neat, right? Yeah.

And one of the things that's unfortunate is because of the, a lot of the open source, I don't know, that there's a lot of projects, or there at least have been enough projects that has been painful that have had a lot of users and, like, something. happen and it's not maintained anymore and it's not there isn't a really good way to transition away or to something else and it gets messy um i mean we had i had a like even uh at work we had a project that we were depending on that was two by python two only 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 these. You could just pay the person, hey, I know it's on this old version, but would $5,000 make it work on the new version too? A lot of times people say, heck, yeah. Or I've wanted to do it, but I don't have the time and our energy, right? Or get your own people to do the conversion work, take it over. Honestly, I'd rather see companies support the maintainers and get it upgraded. But if that's not an option,

Claude could probably upgrade it too. Well, I mean, in the case where, like, somebody just moved on, They're not interested in the project anymore. Throwing money at them is probably not the right option. Yeah, that's true. It depends on the situation. I'll give you two examples of these in the Python space that both make me say. Well, one's in the front end CSS space.

Is Balma. I really like Balma. Super cool project. It tells itself as a modern CSS framework and all these things. But let's see. When was the last release? Oh, yeah. About a year and a half ago.

Really? Weird. Yeah. Which is really sad. Like there was a commit for something super like so this I think this is an absolute tail-tale sign of this so people out there thinking about projects they want to depend upon this is a mega sign for it so three months ago the maintainer of this fixed issue 4,000 what is issue 4,000 the footer has a broken logo on the website

I'm meanwhile it's got 50,000 GitHub stars 4,000 forks and that's fine like this guy he doesn't owe the world anything 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 all the other stuff it's like it's like tailwind but way less complicated and it's gonna keep working and you know in five years I'll find something else but right now I could see it though so like you get 10 minutes to you know maybe you got a half an hour on the weekend to work on it you open this up and you see 346 issues and 175

pull requests I just close my laptop and go outside and mow the lawn or something. I know. No, I know. And so the guy doesn't owe the world anything. He created something cool and that's fine. He doesn't have to do it. But here's something that bugs me. I would just like to put this out there for people. And, you know, if I have projects like this, I consider myself same. I have nothing. I have nothing of the scale. 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 PR is like there's one one on February 20th one on January 20th and there's a hundred and seventy five 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 seven thousand eighteen you know what I mean and so I just feel like it it kind of bugs me that there's all these people out in the world go oh my to help improve this project. 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, 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 thinking on that? Well, I think that sometimes you're optimistic when you originally, like, write up a contributor guideline but need to update it to say yeah i'm i'm not going to accept contributions i guess um yeah exactly i think one sentence on the read me like hey look i just can't like a big bold i can't right now folks so please just hold your thoughts you know and so on because um anyway so the other one is uh discash which i use in love what that's that's abandoned last commit two years ago maybe just works though yeah but here's the thing well i mean there's 20 pull requests 50 issues, no responses. The guy Grant, I don't know him, I don't know his background,

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, yeah, 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? So. Or you did open source to try to be well known enough to get hired by Open AI. I'm not saying there's a negative outcome. I probably is an amazing outcome for Grant.

So that's, you know, congrats to him. And again, he doesn't know the world anything. I think this is a little bit different because it's really a wrapper on SQL Lite. And SQLite is constantly being maintained and updated. So it's, I feel less worried about it. Anyway, dumb ways for open source projects at I. There's just two examples. I think this is important, especially for newcomers to open source and Python to, when

you, when you add something to your project as a requirement, you should know the consequences of doing that, right? I want to add one more thing. There are a lot of packages that really don't need that many updates. Even if they have issues in pull requests, they might be just maybe the maintainer's not that great at saying, you know, I don't feel like it or something. But one way to keep it like to keep it noted that it's alive is once a year, update your tests to the new Python version. Then it's at least a year old and you know it's being tested

on the latest Python. And that's the bare minimum, I think. Yeah. Change your classifier. What are those things called? You know, the classifier to just say new or take out the old Python, put it in the new Python, something like that. You're classifier in here and you're good to go. Yeah. But projects can be done. They definitely can be done. It's just they don't need more changes. But I think it's, I think it's all pretty interesting. But let's take us on to more packaging talk. Yeah, okay. So the, I wanted to talk, this is a brief one, but this is a Tim Hopper article on how to create a

Pylok Tomlophile. And I just kind of forgot that these were sort of rolling in at different times. And as of May, now of 2026, there's now three ways to create these guys. So he covers using UV, PIP, and. in PDM and notes that UV is the only one that says it's in stable status. The PIP lock, high lock, tunnel generation is experimental and so is PDM experimental. I didn't know PDM did it. I'm not really a PDM user.

But the, yeah, just sort of running down how to create lock files with all of 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 incantation is a little magic. It's UV export dash-dash format. Pylactomo with an output of Pyloktomo. Hmm. Seems you've done.

I wonder if there's, there are, I think there's a global config for UV. I wonder if you could put it in there. That'd be interesting. I don't know. And if you, he also has apparently a companion page of how to install. And the how to install is,

the short version is used dash R. Because every, all the tools treat it like a requirements file. Oh, not completely interesting. No depths? Oh, no dependencies. Huh, okay. Anyway, yeah, just creating pylocumophiles.

And, yeah, it's kind of the way we're moving. So that's it. It sure is very interesting. Now, let's talk about Lifeguard. So Lifeguard, we've talked about... Oh, it's a good summer topic. Exactly. A lot of places, at least in the U.S.,

public pools open on Memorial Day, and all the lifeguards go back to work and you need a lifeguard job. And, you know, it's a often a write of passage of high school to work as a lifeguard. So this works for lazy imports. Remember, lazy imports are coming in Python, which is going to be really nice. And I was pretty interested in before, but then I did that work where, and I wrote it up, 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 Star, so it's kind of like brand new, which is fine. It's just a 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 has 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 imports.

But it says why, you know, 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 SIST stat at exit, right? So it wants to run some code at exit to unravel something. But that's only there if you call it the function that causes the lazy import to look. 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 it to a global dick that will, when imported, will silently fail under lazy imports. SIS dot modules manipulations. Code that reads and writes to write Sys dot modules assumes the prior imports have already executed. Interesting. And meta-classes, class creation side effects may depend on it.

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. It looks out for you. So you don't, I guess, drowned in lazy imports. Yeah. Anyway, I just want to put that out there for people because this is coming in Python 315,

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? Yeah. And I guess I think, like, testing is often pretty safe to do lazy imports, so I just want to throw out, I don't have a link or anything,

but a reminder to people that if you're loading something, fairly large for testing purposes and you have a big suite, you can throw that into a conf test, or not a conf test, we could do it be in a comf test, but you can throw the import into a fixture and even an auto use fixture and it'll load it runtime instead of test collection time then. So it's a lot faster. Yeah, that's very good. You focus on just some category test or something like that. You don't have to do it. All right. Let's log it. Let's log it. So there's a, I ran across this article called Choosing a Python Library, choosing a Python logging library in 2026.

And, and I, this just kind of came up at the right time because I've got a project that I'm switching to use. My plan is to switch it to use log guru, log, log, I don't know, log, I don't know, log, I don't know, L-O-G-U-R-U. And the, but, but so I was looking at this just because it's interesting. So the comparison is to the straight logging module, struct log, loggeroo, logbook, and pico logging. 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 Logging.

which I didn't know about, which you can use with the standard logging module and in 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 Jason all over the place. So but so just talking about comparing them all and they didn't really 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 logger, logger 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 I'll understand it, it'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 adjacent thing, so you can read it somewhere else, which also might be kind of cool, but I probably won't do that. You could have two logs. You could set up a logger to a file that logs without serialize and one that logs. Oh, yeah. Right. So you have like a parallel, like a structured and an unstructured version. And when you just say log, it just hits all the attached destinations or whatever.

But the easy setup is what I'm looking for, which, but there are some caveats. It's like it's harder to have multiple loggers apparently. Or at least multiple configurations of different loggers. I don't know if that's true or not, but that's what the article says. One of the things that I didn't know about with this is that there's a logger catch and a logger exception. So there's different ways. The log catch is a decorator to log exceptions nicely or into whatever log file you have set up. So or logging stream or whatever.

And that looks neat. because, you know, my goal does no exceptions, but if there is an exception, be able to, it 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 Jason stuff with Struck Loggeroo, and Loggeru is about the same as the standard lib with Jason, and Struck Log is about twice as fast. well, as in some cases. So that's interesting. Cool.

I use Loggeru by default these days. I really like it. But I've also used Logbook. I don't really use the built-in logging. It just seems complicated than needed to me. I've been doing the built-in logging mostly lately. And I figured, you know, once I figure out like some, and I think I'm like with a lot of people that use it,

I figured out one way that works for me and I just copy and paste and do that. All right. Well, those are items. Do you have any extras you want to talk about? Sure do. I sure do. Hold on. I have two fun things.

So, first of all, let's do this order. A while ago, I told everyone that I have German subtitles available for all 283 hours of courses over at Talk Python training. The courses we got. Well, now we have Spanish as well. So I'm very excited to announce if Spanish is your language and you want Spanish subtitles to accomplish. and you want Spanish subtitles to accompany the English spoken version. Well, look on Espaniel, and you'll be good to go right there. How about that?

That's cool. We took two and a half weeks. We're just grinding on translations to get it done. But there it is. I think it's going to be really great. So what do you have German and Spanish now? Is that? German and Spanish.

Okay. Nice. Now I'm working on Portuguese. Actually, I've done a lot of research, and I feel like Portuguese will be the most beneficial for the tech folks. Because you've got to intersect. You've got to look at two things. you've got to look at how confident is the group of people who speak a certain language in English, right?

So, for example, German, I did German first because I speak some German, so I could kind of spot check it a little bit, and it made some sense to me, you know. 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 a not. So that's the kind of thing I'm trying to balance. So Portuguese is next. Apparently there's a lot of, like Python is super popular in Brazil and other places. So excited for that.

All right. So 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 OWAS top 10 categories with two to three

examples, sometimes in FLAS, sometimes in Django, sometimes in Fast API, 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 Clod, similar to that, with some really custom OWASP and Python web app focus 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 in a blueprint on how to completely check your app for OSP 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 you're that kind of company that can afford $25,000 or whatever for a pentess 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 okay um i um i noticed this there's an article that um was on what npr or uh planet money but um i noticed it because on blue sky um a shout out to where i got the information from if my tabs work savannah astrovsky so um posted this said it was surprising. This is a disturbing article, actually. It's what happened to women in computer science, and I didn't realize this was going on so long. So basically modern computer science is dominated by men. The percent of women in computer science was, 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, what, it was at its height at like 36% or something, that were women. And it's just been going down since then. And, you know, it's leveled off in like, what, 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 that from some, 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 a computer, C.S. 101 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 max 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 don't, I think there's like 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 late comers to the game. Anyway, we need to fix this as a community.

So the next thing, the other thing I want to share, There is that I am. A field report, Brian. So at PyCon, I spoke to, I was speaking several women, and they said just talking to each other, something like, there is a very good representation of women at this conference now. And 10 years ago, it wasn't like that. And I feel the same way. Oh, that's great.

And it's so it's really encouraging, at least in the Python space. But in general, I agree that the graph is bad. It doesn't need to be that way. I also wonder, like a lot, we get a lot of programmers from other fields, though, not necessarily computer science. So I wonder if maybe we need to, but it does say physical sciences, maybe we're getting a lot of our women coders from other fields. I don't know. I do think so. You know, my daughter was learning to do like data sciencey stuff in her psychology field.

And psychology, I think, has more women than men in it, right? And so to the extent that like the data science side brings people in, I think there's a really interesting, Python is super interested because it brings people in from all these different disciplines. And it's not just unlike, let's say, go or C, right? That's like a straight path. You start and programming and you end in this location, right? Whereas with Python, it's got a much more diversity of source. It's 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 this well, which is good.

Um, different generational things too. I know we need to move on. But the, um, I remember, uh, when I was doing teaching at university, um, having, 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 office. audio version of the lean TDD book. And it's coming along well. But 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 TDDD with teams because to team aspects are. 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. And 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 you'll take? My original plan was last January. So we'll

see. Or, you know, January a few months ago. But, uh, congrats. That's awesome. Thanks. So, it's still going. Thanks to everybody that's contributed and helped out. What skill do you need to be an author? Persistence. Yes. Humbleness.

Yes. Speaking of persistence, our joke is titled, Stop texting me. So it's just a screenshot of a chat conversation. Somebody has clod in their, they've clod in their iPhone.

I think it's an iPhone on their messages, right? And it says, Claude, build a $1 billion B2B SaaS 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. That's funny.

And then, of course, there's comments. There are definitely comments. So, 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. Someone comments, is it a legal requirement that says, someone named Claude should be able to spell correctly. And then, yeah, I don't know, it just goes on and on. That's funny.

Yeah, anyway, comments are kind of fun too. But for the thousandth time, this is Claude from the Pickle of All League. I am not AI. I believe this. That's funny. I would totally build them a really crappy B2B SaaS and just charge them a billion dollars. I can give you a billion dollar company. You pay me a billion dollars.

I'll give you something that earns at least a dollar. Just because you spend a lot of money building the company. I mean, it's going to make a lot of money. Exactly. There's no guarantees there. Yeah, but anyway, as always, it's fun. And we'll talk to you later. Yep, thanks.

Bye.