#441: It's Michaels All the Way Down

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

00:04 This is episode 441, recorded July 21st, 2025, and I am Brian Okken.

00:12 Who am I? I am Michael Kennedy. Hello, everyone.

00:14 This episode is sponsored by DigitalOcean. Thank you, DigitalOcean.

00:18 Hear about them later in the show.

00:19 If you'd like to give us some topics for the show or just ask us questions or connect,

00:24 The links to Mastodon and Blue Sky are in the show notes and on our webpage, pythonbytes.fm.

00:31 While you're there, you may as well go ahead and sign up for our newsletter,

00:36 or we'll send you links for the show afterwards.

00:40 And I apologize, because last week was a little late, because I've been sick, but I am bitter now.

00:46 And if you'd like to join the show, we do post it live, usually Tuesday mornings.

00:53 Monday, no, Monday mornings, sorry, Monday mornings at 10.

00:57 It used to be Tuesday.

00:59 But just go ahead and go over to pythonbytes.fm/live and it'll tell you when the next one is.

01:05 And then even if we change it, you can see there.

01:08 Yeah, so let's kick it off.

01:10 What do you got for us, Michael?

01:12 Let's do some follow-up for our first item here.

01:15 So remember, last week I talked about RQ Lite, the lightweight user-friendly distributed relational database built on SQLite.

01:25 And that was pretty cool.

01:27 You could build fault-tolerant relational databases in clusters, even potentially geo-distributed using SQLite.

01:36 Well, as always, our wonderful listeners are like, that's cool.

01:41 Did you know about?

01:42 Right?

01:43 Yeah.

01:43 I love that though.

01:44 Yeah.

01:45 I do too.

01:45 Yeah.

01:45 Thank you.

01:46 So two people wrote in and said, did you know about? And one was Michael Booth. And Michael Booth said, you should check out

01:55 Terso, the next evolution of SQLite. So Terso is interesting in that it is kind of like SQLite,

02:04 but rewritten in Rust with the idea that it can be a distributed database type of thing. Also,

02:12 adding some of these AI features, as in vector search and other things that you need to be able

02:18 to support working with AI.

02:20 So pretty cool.

02:22 If you look through the website, it's like their proper tercio.tech, which it's cool, but I don't know.

02:29 It kind of leaves it a little bit unsure like what exactly it is.

02:34 But like, what is this relation to SQLite, right?

02:38 So it's, go over to their GitHub, it's a little bit clearer, right?

02:42 So it has SQLite compatibility.

02:44 It is not based on SQLite like RQ Lite is, but it has language biodeans for Python

02:52 and other, maybe some of these other languages people have heard of like Java and JavaScript and so on.

02:56 But it has asyncio support, which is really cool.

02:59 And you might say, well, it's SQLite.

03:02 Can it really have asyncio support?

03:04 Yes, at least on Linux.

03:06 It uses IO Uring to make that happen, but it runs on all the server or all the platforms.

03:11 So you can like develop on macOS, but then you get better perf on Linux, for example.

03:16 It also, they're working on adding a begin concurrent operation, like a SQL statement or query statement,

03:25 and indexing for vector search, like probably pretty much required, and better alter support, right?

03:30 So basically think of it as a more modern take, not just because it's rewritten in Rust,

03:37 which seems to be like the thing you do, but as part of that, taking on a lot of ideas like concurrency others. Okay. Big question. Is it ready for production

03:46 use? No, no. But these folks also worked on this thing called LibSQL. So it says that the

03:54 Tarot database is the next evolution of SQLite and Rust. They had previously worked on something

03:59 called LibSQL, which is an attempt to evolve SQLite in a similar direction, but through a fork

04:05 rather than a rewrite. And they're like, we think this new database thing is a better way to go.

04:10 So if what I talked about with RQ Lite inspires you, this also might.

04:15 They also have some kind of what you might expect as open core, but we'll do the infrastructure side of things for you.

04:24 So they've got this thing called Terso Cloud, which is a production or a paid sort of thing, right?

04:30 So serverless access or sync or whatever you want, right?

04:34 Replication, sync, vector search, all that kind of stuff.

04:36 Basically managed.

04:38 All right, so that's thing one.

04:39 the other one comes to it.

04:41 This is like all, it's all Michael.

04:42 Michael's all the way down.

04:43 So we had Michael Booth recommend that one.

04:45 Got me, Michael presenting it.

04:47 We got Mike Fiedler talking about the next one here.

04:51 And Mike Fiedler says, have you heard, well, listen to the most recent Python bytes and RQ Lite.

04:56 It's cool.

04:57 Hadn't heard of that.

04:57 Something related that might be interesting is lightstream.io.

05:01 Okay.

05:02 Now lightstream.io is more SQLite than before.

05:06 You just keep using SQLite like the one built into Python.

05:09 but you launch a little daemon that watches it and constantly syncs it with S3 or Azure Blob

05:16 Storage or something like that. When you do that, what do you get? You get something pretty cool.

05:22 It just constantly streams changes to AWS S3, Azure Blob Storage, Google Cloud Storage, etc.

05:30 And that means you basically get failover. So imagine you're like, I would love to just have

05:35 a SQLite database that I can run on a simple little app.

05:41 But what if that server goes down?

05:43 What if that server fails?

05:45 Then all my data is lost from the last time I backed it up because my alternative was to

05:50 run some kind of cluster of Postgres or Mongo or whatever, right?

05:54 But then you're into lots of DevOps and managing those things, or you're paying for managed

06:00 databases, which can be relatively expensive to small servers like DigitalOcean has.

06:06 And what you can do is you can just keep on using regular SQLite, but then use this Lightstream,

06:11 which has no real performance differences in terms, like these other two things are like trying to change how SQLite works

06:16 or re-implement the compatible API.

06:19 This one just says, we promise to hook into some, I put a link in the show notes.

06:26 There's a nice write-up about this that they did.

06:30 It's sort of like, why is this?

06:32 And called Lightstream revamped.

06:35 And it also just talks about like, why did they build this?

06:38 How does it work?

06:38 So it says it takes over the wall checkpointing process to continuously stream updates to

06:44 the database.

06:45 So basically as commits are committed to the SQLite file, it just keeps pushing that to

06:51 blob storage.

06:52 Cool, right?

06:52 So if that RQ Lite thing was interesting, but not quite what you're looking for, maybe one

06:58 of these two things is.

07:00 Yeah.

07:00 Interesting.

07:01 Pennies a day.

07:01 I like that.

07:02 Dirt cheap.

07:03 Yeah.

07:03 Dirt cheap.

07:03 only costs pennies a day because it's just blob storage, right?

07:07 So however you do that.

07:09 And the Lightstream, I don't know that they, I don't see pricing.

07:13 How about that?

07:14 So this is just pure open source, whereas the Terso was like, you can do the open source thing yourself

07:22 or we can do our cloud thing, right?

07:24 I don't know which of those makes you happier, but they're not the same in that regard.

07:27 Or they are the same with a wrapper, pay wrapper.

07:30 Anyway.

07:31 Yeah.

07:32 Okay, cool.

07:33 Awesome.

07:33 Over to you.

07:34 I want to talk about project status a little bit.

07:37 So I do want to talk about this new PEP.

07:40 So PEP 792 project status markers in the simple index.

07:45 So project status, what is this about?

07:48 So this is a new PEP that was, well, it's not right, really that.

07:51 It is pretty new.

07:53 So it actually updates in February of this year, and it's now accepted.

08:00 So I'm going to talk about this a little bit, but I want to talk about project status and what this means.

08:05 So if I take a look at a couple of my silly projects, I've got pytestCheck, which is a project I maintain,

08:11 and I actually intend people to be able to use it so it's maintained.

08:15 And so I have added a Trove classifier to say the status of the project is production stable.

08:21 I think you can use it in production, but it's, you know, yeah.

08:24 But this is optional.

08:26 Maintainers don't have to put this in.

08:28 For instance, I also have another one called pytestCrayons i just did for a uh a talk that i gave and um i didn't put the um the status in there so that's

08:39 an it's an optional thing so what we have we have in the current situation there is the trove

08:44 classifiers that you can optionally add to um uh to to your project and you if you like for instance

08:52 start taking it down you can say that it's inactive it's not but i don't think very many people do

08:58 that often inactive just means somebody left but it's still they haven't updated a new one that's

09:03 like please close the door on your way out usually they just walk out the door so and then there's

09:08 also there's actually three kinds of status so there's that the trove classifiers but then there's

09:14 also uh indices uh can mark uh a district can mark distributions and releases as yanked so you can

09:22 like a version you can yank.

09:25 So it's not there anymore.

09:26 So then it's still like got an entry there, but it's been a yanked, whether it's true or false.

09:34 You know what, I've started seeing that a lot lately, actually.

09:38 Have you?

09:38 At least uv pip warnings.

09:41 So I'll say, you know, update the dependencies of this project, basically uv pip compile, and then I'll install the requirements.

09:48 And it'll say, this thing has been yanked because of, and you don't have some reason, like broken metadata or whatever.

09:54 I'm like, well, I don't know what I'm supposed to do about this because something needed it.

09:58 Yeah.

09:59 Okay.

09:59 I've not seen anything fail.

10:01 I haven't seen the apps no longer run because something got that status,

10:04 but I've seen warnings about this now.

10:06 And then there's another type of status that PyPI itself can have a status for an entire project.

10:14 And the entire project can be quarantined if the administrators of PyPI think that the project has been,

10:22 like, it's got, like, malware in it or something, so they can quarantine it.

10:27 And also, a project owner can archive a project and say, basically, you can disable new releases.

10:35 It's still around, but nobody can update to it, and it's just archived.

10:41 It's there for historical purposes, I guess.

10:43 Anyway, so there's three statuses, And it's a little confusing on how to use those as a as a if you had an alternative index, if you were trying to like do dependency resolution or other things.

10:56 So trying to clean that up a bit.

10:58 So there's really this proposals to have one project always has exactly one status and the status will be it'll be active.

11:08 And then there's some semantics around that active or archived or quarantined.

11:15 and deprecated and this makes sense so it's either either it's it's in use it's active or

11:22 it's not um but it's also what does it not mean it's either you know there's various levels of

11:28 why you can't you shouldn't use it um and i think this is um this is a way for good way forward to

11:33 have like to kind of consolidate these now this is this has been accepted this uh this active

11:40 archived, quarantined, deprecated status, and it can only be one of those.

11:45 But this has been accepted.

11:47 However, it's not implemented yet.

11:49 So don't go out and look in PyPI to try to find this yet.

11:53 So this just was accepted July 8th resolution.

11:58 So we will update you further as we hear from people in the Python community

12:04 that this is all implemented.

12:06 Yeah, excellent.

12:07 I think I'm behind it.

12:09 The quarantine one is good.

12:11 I'm very glad I've never seen that warning.

12:13 And the archive one feels to me like a little bit of a supply chain safety type thing.

12:19 Like, I'm not going to mess with this.

12:20 I will never update this.

12:22 But let's not allow something to happen where someone else could either.

12:25 Well, and I'm not sure.

12:27 So I was trying to read this.

12:28 I was trying to understand kind of how it's going to be set.

12:31 So it's probably not going to be something just in the Trove classifier.

12:36 So it probably is going to be something that outside of the data itself.

12:40 So because there's times where it's clear there's nobody updating it anymore

12:46 and you can't get a hold of the maintainer, you need to be able to say, this one's dead.

12:52 I think it's too bad that we don't have a better way to say, but after the fact, if somebody just stops maintaining something,

13:00 hey, does anybody else want to start maintaining this?

13:02 I know there's security problems around that, But, you know, it might be good to be able to have some things live on.

13:09 But yeah, and just archiving old stuff.

13:12 It's not good.

13:13 Was it GitHub?

13:15 I think that got into a big uproar because they decided that they're going to archive a bunch of stuff if it hadn't been updated in like years.

13:26 Or was it NPM?

13:27 I don't know.

13:27 One of these types of places was like, if stuff doesn't get touched, people are like, hey, it's not unmaintained.

13:33 It's just done.

13:33 There's nothing to add.

13:34 It's perfect.

13:35 works. Yeah. Exactly. Cool. All right. Well, before we move on, let's talk about our sponsor,

13:42 huh? Yeah. Yeah. So super excited to have DigitalOcean back to support the show. As always,

13:50 this episode is brought to you by DigitalOcean. And DigitalOcean is a comprehensive cloud

13:55 infrastructure that's simple to spin up even for the most complex workloads. And it's way better

14:00 value than most cloud providers. I've looked at the big three and they're not even close.

14:05 in how much value you get per dollar and how much easier it is to use.

14:10 So at DigitalOcean, companies can save up to 30% off their cloud bill.

14:14 They boast a 99.99% uptime SLA.

14:18 That means they promise to support that level of uptime.

14:23 Our experience, Brian, running Python Bytes and other things on DigitalOcean for many years

14:27 was way higher than four nines.

14:29 Really, really reliable.

14:31 Love them.

14:31 They also have industry-leading pricing on bandwidth.

14:35 Also true, like 10 times, 8 times cheaper than AWS and Azure.

14:39 Really good.

14:40 So it's built to be the cloud backbone of businesses, small and large.

14:44 And now they have GPU-powered virtual machines, plus storage, database, networking capabilities, all-in-one platform.

14:51 So AI developers can confidently create apps that their users will love.

14:56 And devs have access to a complete set of infrastructure tools they need, both training and inference, so they can build anything they dream up.

15:03 DigitalOcean provides full-service cloud infrastructure that's simple to use,

15:06 reliable no matter the use case, and scalable for any business.

15:10 So did I say good value? $4 a month for a server.

15:13 That's yours. Your Linux server, USSH, too. Amazing.

15:16 And GPUs, servers for under $1 per hour.

15:20 So easy to spin up infrastructure to simplify even the most intense business demands.

15:25 That's DigitalOcean.

15:26 If you use the DO4bytes code, then you can get up to $200 in free credit to get started.

15:36 DO4bytes.

15:36 Just click the link in your podcast player show notes.

15:39 DigitalOcean is the cloud that's got you covered.

15:41 So like I said, please use our link.

15:43 You'll find the podcast player show notes, a clickable chapter URL while I'm speaking right now.

15:48 And at the top of the page at pythonbytes.fm for the episode.

15:51 Thank you to DigitalOcean for supporting Python Bytes.

15:55 Indeed, indeed.

15:55 Now, over to you.

15:57 Well, so I want to talk about testing a little bit.

16:03 So Hugo van Kaminade, love you, Hugo, sorry, wrote a post called Run Coverage on Tests.

16:13 And this is something that I've taught everybody to do or taught everybody I can get hold of their ears to do this

16:21 because it's important.

16:23 But I'm glad that Hugo wrote a post about it.

16:25 And this was just going to be an extra.

16:27 However, I was blown away by a few things here.

16:30 And I'm like, oh, we got to make this highlighted a little bit more.

16:34 So the classic reason why you should run coverage on your test is because of the copy-paste-modify problem with pytest.

16:41 Because pytest really kind of, the name of the test is just sort of shows up in the reporting.

16:47 So it's very easy to copy my, you take an old test.

16:53 And since you're not calling the test function yourself, it's easy to copy, paste, modify,

16:59 and forget to change the name.

17:01 And if you do that, the second test just hides the name, it hides the first one.

17:08 And that is the classic reason why I tell people to run coverage so that you don't do this.

17:12 And it's hard to figure out otherwise.

17:16 But a couple of cool things that I learned from this post is that Ruff's rule F811,

17:23 f811 catches that apparently so there is if you run rough on your test code also with at least f811

17:32 turned on you'll it it checks for variables which the function name is officially a variable

17:41 that are defined and and redefined or otherwise shadowed and unused so if you used a variable

17:49 didn't use it and redefined it um that's just that's similar to defining a test twice so um i

17:55 didn't know that so i will make sure that i've got rough running on my test code also so that's cool

18:01 also a tip to say hey if you're really just copy paste modifying a test maybe think about py test

18:06 parameterization which i agree um you might want to just parameterize the test but this is also

18:11 pretty common it's so common to copy paste the second example is what the one that i really was

18:17 like oh my gosh we have to cover this because i would have never i wouldn't have caught this so

18:21 his second example is this weird okay so it's like a he's got an image some image stuff that he's

18:29 testing and it's like i don't know it's i guess i'm just it's a little bit of a complicated thing

18:35 you've got some colors and images and you're trying to test in the in the end you're asserting

18:40 whether or not images are similar of a reloaded image versus an expected image and i don't really

18:46 understand what's going on here but um this isn't terrible but one of the things in here is that um

18:53 when he ran coverage it said that uh these two lines at the bottom are not being run at all and

18:59 he's got a a some images a set of images that he's iterating over and apparently there's nothing in

19:06 them so what's going on um and the thing that's going on apparently is uh this his his images are

19:15 a generator is what's going on so he's got some images that are being uh set up as a generator so

19:22 like a uh you know for i in a generator comprehension yeah generator comprehension

19:29 and then he passes that to a function that consumes the generator um and then uh and then when he tries

19:36 to use it as the as in the assert section there's nothing there anymore and i would have never like

19:42 obviously this is this is highlighted because i use generated way more than in generator

19:48 comprehensions more than i used to um because they're cool um and they're efficient and if

19:53 you've got huge things they use up less memory so i'm using them more and more and i probably am

19:58 using in my test i better make sure that i'm not like mucking up with things like this um so uh

20:05 pretty cool reason to use um uh use coverage on your test code to make sure that you don't do this

20:11 Oh, yeah. The fix, by the way, of doing this is just instead of using a generator comprehension, just use a list and pass it to a desk.

20:19 Square brackets, not parentheses.

20:21 Yeah.

20:22 Problem solved.

20:23 It's subtle, though. I agree. Very subtle.

20:25 Oh, yeah. That's the difference, really? Yeah. A parentheses for those brackets, and then it works.

20:31 Well, yeah.

20:32 Okay. Anyway, thanks, Hugo.

20:34 Yeah. Thanks, Hugo.

20:35 All right, let's talk about something simpler than all that SQLite distributed async business.

20:44 Here's a problem, Brian.

20:45 You have a program, probably in our case, often a Python program, and you want to give it to somebody and let them run it.

20:52 How do you do that?

20:54 Still, to this day, there's no amazing options to do that.

20:58 I know we have Py2.exe and Py2.app, but those things are, while awesome, they're not consistently

21:08 reliable and all sorts of things.

21:10 So this is a little bit more dev-focused than that.

21:13 But if you have Docker installed on the machine, right?

21:17 So if Docker is like Docker Desktop or OrbStack or whatever, and I guess even in the upcoming

21:24 macOS. We're supposed to have a built-in Docker equivalent built straight into macOS,

21:30 which should be interesting. Anyway, if you have any of those, there's this project called Docker

21:34 to EXE. Too executable. I believe it works on all the platforms. I don't think it's just

21:39 Windows EXE, even though, you know, yeah, it absolutely works on Windows, Linux, and Darwin,

21:44 aka macOS. So just too executable, right? And the idea is that if you have a Docker image

21:51 with an entry point or something like that that will start an app running,

21:55 you can simply build that as an executable, either a.exe on Windows, a.app.

22:02 You have to rename it, I think, more or less.

22:04 They're just executable binaries, right?

22:06 So you can take that Docker image and build it into an executable, which is pretty awesome.

22:12 So you could, you know, the example they give is kind of, it's a bad, I'm going to call it as a full-on bad example because it says,

22:18 here is a bare Linux image.

22:21 You can distribute that as a binary.

22:23 It's like, okay, great.

22:25 That's not exactly the use case.

22:27 You know, the use case is I have something I want to give to someone and run it, right?

22:32 So as a Docker thing, so maybe a better example would be like, here's copying over my source code,

22:37 building a Docker image, and then turning that base Docker image into an executable that I can distribute, right?

22:42 But this thing would do that.

22:44 It's just the example doesn't show that.

22:46 So I think that is pretty neat.

22:48 And if you want yet another way to distribute a more durable tool to somebody, if they have Docker, then you're good to go.

22:57 That's pretty cool.

22:58 Well, do they have to have Docker?

23:00 Yes.

23:01 Okay.

23:01 Because basically somehow this thing just bundles up the Docker image and then just executes it using Docker in the same way that you would just say Docker run, etc.

23:11 The other thing that's not clear to me is if there's a way to pass through mappings, for example, map port 8000 to 2722, whatever, you know what I mean? Or map this volume to this folder. Probably you can in the exit, like when you run the executable, can you pass that kind of stuff to it?

23:32 Also, again, the reason I don't like this example here, boy, they just like bundle up Linux.

23:37 In the Docker file itself, you can say expose this port and do other type of things like that in the Docker file.

23:44 So you can bake in, like if you're saying, my thing is a little Flask app that runs using maybe SQLite for the database.

23:51 It exposes this port so that you can then, you know, it could print out a thing like click here to like talk to the server

23:57 and launches a URL, the web browser to like a local URL.

24:00 So you can do that with, I'm pretty sure, with expose and other stuff in the Docker file.

24:05 But yeah, anyway, you want to ship a Docker image as just an executable binary?

24:10 Check this thing out.

24:10 Cool.

24:11 Very neat.

24:12 All right.

24:12 I know that you have extras and I don't.

24:15 Okay.

24:15 I've got some testing code news.

24:18 So testing code has sort of been on pause.

24:19 When was the last time?

24:20 May 7th.

24:22 It's July now.

24:24 It's been on pause for a while because of life.

24:26 But life has got a little bit of room in it now.

24:29 So I'm going to do a little bit of testing code.

24:31 So there is a, there's three episodes in the queue and hopefully more to come.

24:37 So at least, and so this week there will be an episode and I'm pretty excited because the,

24:42 this week's episode is covering pytest Django with Adam Johnson.

24:46 And a lot of people have asked me about pytest Django.

24:48 And since I am not a Django expert, I, and Adam is, Adam was willing to talk with me about it.

24:56 And it's a, it's a really great discussion.

24:58 So I'll be excited to get that out.

25:01 I'll be excited to get that out this week.

25:03 And then also I went ahead.

25:05 So I'm using a hosting provider I'm using for this is Transistor FM.

25:11 And Transistor has the ability to push things to YouTube, but it's a little bit wacky.

25:16 So I have went ahead and turned that on.

25:19 And so everything now is for testing code.

25:22 Well, not everything yet.

25:24 207 episodes are now up on YouTube.

25:27 The catch is they sort of show up in random order.

25:32 They push, I think, 80 episodes a day or something like that.

25:37 They do a lot.

25:39 So by the time you probably hear this, if you don't hear it on the first day,

25:45 they'll probably be all up.

25:46 But anyway, they're there, but they're just in weird order.

25:50 That's a lot of content to be pushing up there.

25:52 I suspect, though, after it sort of bulk uploads, Once it does, as you start publishing, it'll go in the right order.

25:58 Yeah, well, it's because YouTube orders, I'm pretty sure YouTube orders in the upload order of when you uploaded it.

26:06 And there's no way to backdate it to say, this was actually two years ago or something.

26:11 Yeah, and probably Transistor just batch processes them.

26:14 And the order in which they complete is the order in which they upload.

26:17 Luckily, when I transitioned to Transistor, though, They do have a, it just uses your old post dates.

26:27 So even though I transitioned like, I don't know, a couple of years ago or something like that,

26:32 I still was able to, you know, like some of the early episodes still show up

26:37 as like being happening in 2016, even though they got transferred later.

26:42 But anyway, a lot of content.

26:44 Good deal.

26:45 So no extras for you?

26:46 No, I'm not very extra.

26:48 Just been working hard and stuff.

26:49 I'll share, I'll have things to share eventually, but right now, no extras.

26:53 I do have a joke I've brought for us.

26:54 What do you think?

26:55 Oh, yeah.

26:56 Let's do a joke.

26:56 Are you here for it?

26:57 Yeah.

26:57 Okay.

26:57 So, Brian, what if programmers were doctors?

27:02 You know, the old joke.

27:03 Hey, doctor, my leg hurts.

27:05 Well, stop.

27:07 My leg hurts when I lift it like this.

27:09 Well, stop lifting it like that, right?

27:11 Yeah.

27:11 There's a fun variation on that joke for programmers, and it's basically the doctor equivalent of it works on my machine.

27:20 It says, doctor, my leg hurts.

27:22 That's weird.

27:23 I also have a leg and it doesn't hurt.

27:24 The issue must be on your side.

27:29 Yeah, that's definitely true.

27:32 Yeah.

27:34 I like it.

27:35 That's dumb, but funny.

27:36 I know.

27:36 It's short and sweet.

27:39 I like it.

27:39 Cool.

27:40 Well, thanks for the joke, Michael.

27:42 And thanks, as always, for this wonderful episode.

27:45 You bet.

27:46 Bye, Brian.

27:46 Bye, everyone.

27:47 Bye.