Python Bytes - #418 I'm a tea pot

Episode Date: January 27, 2025

Topics covered in this episode: In memoriam: Michael Foord 1974-2025 Valkey (Redis Replacement) 30 best practices for software development and testing mimetype.io 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 10am 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. Brian #1: In memoriam: Michael Foord 1974-2025 Guido van Rossum and others We’ve just lost Michael Foord this last weekend. From Guido: “Michael, an original thinker if there ever was one, started the tradition of having Language Summit events at PyCon, IIRC together with Barry Warsaw. He also wrote and contributed the influential mock library. … “ “PS. Feel free to post your own (positive) memories of meeting Michael – perhaps his children (10 and 13) will read them when they’re older and this thread might help them remember their father.” I’ve added my memories. I think this is a great (and small) way to honor him. My friend Michael - Nicholas Tolervey After 5 years of trying, I did get an interview with Michael. I wish I’d have gotten that followup. Test & Code episode with Michael, ep 145, “For those about to mock” Michael #2: Valkey (Redis Replacement) Thanks Calvin HP An open source (BSD) high-performance key/value datastore that supports a variety of workloads such as caching, message queues. Can act as a primary database. Valkey can run as either a standalone daemon or in a cluster, with options for replication and high availability. Valkey natively supports a rich collection of datatypes, including strings, numbers, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs and more. You can operate on data structures in-place with an expressive collection of commands. Brian #3: 30 best practices for software development and testing Michael Foord (from 2017) Some gems 1 - YAGNI 6 - Unit tests test to the unit of behavior, not the unit of implementation. 8 - Code is the enemy: It can go wrong, and it needs maintenance. Write less code. Delete code. Don’t write code you don’t need. 15 - The more you have to mock out to test your code, the worse your code is. and so many more … Michael #4: mimetype.io I’m always forgetting content types! Also, shout out to httpstatuses.io Extras Brian: Python 1.0.0 released 31 years ago Michael: Python 3.14.0 alpha 4 is out Joke: Tea Time

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 418, recorded January 27th, 2025, and I am Michael Kennedy. And I am Brian Ocken. And this episode is brought to you by us. Check out Brian's PyTest course, check out his course, and a bunch of my courses over at TalkPython Training. And thank you to Patreon subscribers, supporters there. We appreciate all of you. And even if you don't do any of those things, we appreciate that you listen. That's why we get to do this stuff. If you want to connect with us, we're Blue Sky Mastodon mostly these days. Links for Brian, me and the show all in

the show notes. You can join us live, pythonbysteadfm slash live. A few of you are, most of you aren't, that's fine. But we do that if you want to join, usually Monday at 10 a.m. Pacific time. Sometimes things go a little haywire. You can always watch the video replay on the episode page if it's available. And finally, Brian and I are crafting. We're continuing to hone our artisan craft, Brian,

for the artisan newsletter. So if people want to get the newsletter, they can go right to Python by SideFM, click on newsletter. It's the very center of the five buttons in the hero image. And all you got to do is give us your name and email, and we will send you summaries, insights, the joke, and a couple of things we're doing different now. Brian's trying to put the TLDR stuff at the front so you can skim it really quick as well as the joke so people can have fun with that kind of stuff. So if they want that, they can check it out. And with that, what would you like to talk about first today?

I actually want to talk about something that's not really wonderful, but I think we should talk about it anyway. So this last weekend, we lost Michael Ford. And many of you might not know who that is. But he was influential. He's a core Python dev and influential with a lot of the early stuff in Python and PyCon, at least early in my perspective. So one of the things that he is known for is he's one of the contributors to the unit test library within um within python within python and then also um he wrote a a package called mock that was separate for a

while but then i think it was three three or something early in the uh three x's got incorporated into the standard library as unit test. Dot mock. So if you're mocking anything, even if you use, so pie test mock is where I usually use often, but it's a wrapper around that library. So a lot of great stuff from Michael. He was a larger than life character. There is an in memoriam.

He that's up on the python.org discuss site, started by Guido. And a couple of things that Guido mentioned is that Michael was an original thinker, started the tradition of having the language summit events at PyCon. That's pretty big. And if I recall, the IRC was that, if I recall correctly, together with Barry Warsaw. So he also wrote the mock library.

And in memoriam, so Guido suggests that to feel free to post positive memories of Michael. And perhaps maybe he's got kids, 10 and 13. So hopefully later they can look back and see how influential he was. And I really had a hard time with this, actually. I had a couple losses in my family recently, and I wasn't really close to Michael, but I kind of wished I would have been. I did interview him. I tried to interview him early and eventually did in 2021 get to talk to him about mocking on for the Testing Code podcast. So just listen to this. It's a great, again, it's a great episode. He's got some great advice towards software development and testing. So check that out also.

There's also a really great write-up from, so, so Nicholas Toller V, uh, who I've also had on the test and co podcast, also a great guy. He's a, he's the dude from the MU or MU editor. Um, he wrote up, uh, my friend, Michael, um, uh, a post about losing, losing Michael. And there's some great pictures. Um, he was a larger than life. That's a great one. Larger thanlife character.

There's a paragraph in here I wanted to read. He was a walking paradox, both completely certain of himself and yet always questioning everything. He didn't shy away from fiercely independent thinking, often about the oddest of subjects, and through the most extraordinary, original, and I dare say weird lines of argument. Anyway, goodbye, Michael. You will be missed. Yeah, thoughts out to the whole community, friends, family. I didn't get a chance to meet Michael, but certainly it looks like he was very influential.

Yeah. All right. Hopefully you got something a little less depressing next for us. Yes. Well, it starts with a real smiley picture, so it's going to start out pretty well. I had Calvin Hendricks Parker from Six Feet Up on Python, and we talked about this deployment system. Kind of like cookie cutter, but way more than that. A whole infrastructure for initially Django apps, but growing from there. Anyway, during that, we talked

about a bunch of the building blocks of those tools and of that framework. And that's how we get to the next one. Something called Valky. Do you remember, I mean, you know, Redis, right? So Redis, key value stores, people sometimes group it in the database category for when you're doing like surveys and what database you use, Redis, JSON, or SQL server. Like, huh, wonder which one I should pick, which of these, which of these fit, which of these don't or whatever. But it, you know, Redis is kind of a key value store, mostly in memory cache, high speed, but can be used for other things for queues. I believe it can persist. Well, anyway, it's gone through some funky licensing.

This is not new, by the way. This is not new. But it's been that way for a little while. And I don't know. I've always had prickly reactions with the folks from Redis. But whatever. I ran across this thing called Valkey, like value key, key value store. And Valkey is a truly open source, no license, no cost, no nothing alternative to Redis.

So an open source in-memory data store that can kind of be a primary database if you want it to be, but it's not its main goal. So here, I'll just give you the quick first paragraph. Valkey is an open source, high performance, key value data store that supports a variety of workloads such as caching primarily right message queues and can act as a primary database valkey can run either as a standalone daemon or in a cluster which is pretty awesome with replication and high availability options it even has native support for well strings obviously numbers probably but hashes lists set so you can ask for probably like I want a query into this dictionary type of thing. Pretty cool.

People can check it out if you go to the GitHub somewhere. There's got to be a GitHub, right? Here we go. And you go to the repositories somewhere. Oh, there it is right there. Finally found it. 18,000 GitHub stars, 700 forks. So it's got a lot of life to it.

And let's see. Does it tell you how old it was? About a year old, I think. Anyway, isn't that cool? I think it's really neat. Yeah, I'll definitely check this out. I do too. I'm pretty excited about it. I'm not using anything like this yet, but there's some situations where I might be able to use this recently. And certainly this is something I would give a hard look at if I was doing a key value in memory cache type of thing, especially with the failover and the replication, because a lot of times you've got to restart these things.

They have to repopulate the cache and that can be really kind of slow. And, you know, like C systems fall down and they can't quite get back up because the cache isn't there and they keep getting killed. And anyway, these are pretty neat technologies if you need them. And Valky, yeah, check it out. Cool. Cool. All right.

Back to you. Let's see. Doing this again okay um there i'm gonna go back to michael ford again because um actually in 2017 he wrote an article called 30 best practices for software development and testing and i think i didn't didn't talk about it on this podcast because my intent was to talk about it on testing code and interview Michael. And, um, and that was a long story as to why we didn't talk about this, but I can't believe we haven't covered this yet. So a really great article, 30 best practices. Um, I'm not going to read all of them, but I want to read like a few of them. Uh, Yagney, uh, it's not the only place I've listened,

heard the term Yagni, but Yagni is number one. Yagni stands for you ain't going to need it. So don't write code that you think that you might need in the future, but don't need yet. Just don't do that. You write it in the future because you might not need it. Yeah. People stress so much about this. Like, oh, we got to plan for the future. We've got to get just right. Or just embrace refactoring. Just embrace refactoring. Rightoring right like right it's what works now and if you need to change it there's all sorts of amazing tools to change it source control does not break it so you can save it we'll refactor just test to make sure it works yep um gonna jump down a little bit a bunch of great stuff in here uh oh i love this when uh When it comes to API design, simple things should be

simple, complex things should be possible. I can't remember. I don't remember if I got this from him or not, but I live by this, trying to keep the easy things easy. And it can be complicated for the not easy things. That's okay. Number six is unit tests test to the unit of behavior, not the unit of implementation. And these are kind of fighting words. This is pretty much the difference between classical versus mock test driven development. But I stand by Michael's side on this one. Number eight, we've got a couple more that I want to hit.

Number eight. Code is the enemy. It can go wrong. It needs maintenance. Write less code. Delete code. Don't write code you don't need. Less code.

It's true. The less code you got, the less bugs could be in there, for the most part, as a general rule. Last one that I want to cover. I'm all about nine as well, by the way. Oh, nine? Yeah. Inevitably, code comments become lies over time. Yeah, definitely. In practice, few people update comments. I still remember that I had a code base that there's so many comments in them, and there were boilerplate comments that in order to understand the code, I wrote a script to copy

the entire code base into a different directory structure and strip all the comments out. And it was so much easier to deal with. JOSH FRIEDMAN- Gosh, I feel that way about help docs, help strings, doc strings sometimes. It's like, there's three lines of code and 18 lines of doc string. Like, wah.

If that just weren't there, I could read it. DAN LEMONDOTTIRUCCIUOUSA- Yeah, and then that can blow up the entire file. If each function is like that, you've got a few hundred lines of code and 2,000 lines of file. Anyway, 15, we'll jump to 15. The more you have to mock out to test your code, the worse your code is. And that was one of the things that surprises me coming from him. This is the dude that wrote the mock library. And one of the things he discusses in the episode where I got to interview him

is he was developing this when he was on a team that was doing a mock test, a mock test isolation test of development philosophy. And they ran into the issues that I've run into before also is if you're testing the implementation, that means when you have to refactor your code, your tests don't help at all. They just all break. So testing behavior is better. And then also just trying to not have to mock your code. That's not a hard and fast rule. Sometimes it's the easiest thing.

Yeah, and plus you're going to hurt its feelings if you mock it it's just not nice i mean sometimes you got to just that's not nice come on yeah that's funny anyway uh great article uh go have a go have a read i've already i've reposted it on uh on social media and a lot of people have said uh hey this is great so awesome it's good all right i got a question for you brian okay if you're working on a web project and i've been working on some web projects and you have to do direct requests like say for example over on python bytes if i go to say like our latest which is very very close to being not true but our latest episode bug tied from the Light,

you can see there's a image here and that's the thumbnail from YouTube. And we have stuff in PythonBytes.fm that when you load this page, it'll look for the YouTube link and then it'll talk to YouTube, pull that and get the thumbnail. Now you might think, why don't you just put the YouTube embed right there?

Because Google is parasitic. And when you embed a YouTube video, it puts tracking cookies onto you, which means we would have to have a cookie banner. Do you accept our cookies? Because we're making our website better for you by tracking you. I'm like, I'm pretty sure you're not, but okay. Or you could download the image, put it in your database and then serve it out of court or flask or pyramid or whatever it is you're using, right?

When you do that kind of stuff, you need to know what the MIME type is or the content type, more importantly. Like, you need to tell the browser, this is not just binary stuff, but this is an image. I know it came from a database and doesn't have a file name, but it's a PNG or it's a JPEG or whatever, right? So back to my item, mimetype.io, which I would prefer to say is content type.io. But, you know, for example, tell me, what is the content type of a JPEG? Well, it's probably image slash JPEG,

but is there a E in there like JPEG or is it JPG? But you better not get it wrong, right? So there's this site mimetype.io and you just type in whatever file extension you think you can imagine. It'll tell you it's image slash JPEG with an E, not without. And it shows you all the file type extensions for which this applies. And it gives you like the history of it. If there's other things it's known as, like sometimes I think if I put it in JSON, there might be like JSON as application

slash JSON, but there's a deprecated text slash JSON. It might also appear as, isn't this cool? Yeah. Yeah. So if you're doing web projects and you need to send files, you need to specify the content type and here you go. This is how you do it. So I really liked this. I ran across this in hat tip to a very, very similar project for HTTP status codes at httpstatuses.io. So for example, you've seen 200, 201, like 200 is good. 201 is created if you did like a post, a new thing or whatever.

What is about 203? I don't know, man. But if you click on it, it says, this is a, you know, lets you dive into them. It's a 203 non-authoritative information this request was successful but enclosed but the enclosed payload has been modified from that of the origin server's 200 okay response by a transforming proxy whoo but it also shows you like how to get to these as enumerations in say python or the new new python and so on right so

you're not programming with magic numbers like 203 or quote 203. Sometimes these are representative strings, and I don't know why. But yeah, anyway, we're going to come back to this for our joke. But the takeaway is mime-type.io, which I wish were called content-type.io, but whatever. It still works. Okay. I like mime-types. Yeah.

Like the types that are stuck in a bubble. Like, I can't get out. I know. Yeah, they really do act it out. They do act it out. Sorry. No, it's all right. All right. That's it for our main items, right?

Yeah, I think so. You got any extras? Just one. I noticed somebody posted online today that Python 1.1 is out. Actually, 31 years ago, as of today. Python 1.1 is out actually 31 years ago as of today uh python on january 27th 1994 guido posted 1.00 is out so anyway i'm tired of deciphering that pearl code you got last week sick of cgi let's go frustrated with born shell syntax yeah yeah yeah yeah yeah yeah funny cool well anyway i don't. We'll see if that

thing takes off. Hope so. It's got a future. We'll see. All right, cool. I got a few extras. I'll keep it quick. I don't got a lot. Speaking of releases, Python 3.14.0 alpha four came out last week, minutes after we recorded our last episode so since last time something to announce people can check it out it's coming along this is alpha 4 that means there's three more alpha releases then we hit beta then you can start to treat it seriously as a fixed item right chances are no new features just bug fixes and polish before it goes although i'm sure they could decide you know this this is too rough we're not going to make it. We'll take a feature out. But the idea is that the betas are fixed. Yeah.

And actually, so I, I usually haven't been testing new stuff until like we had to betas, but UV has made it so easy to load up a pre-release stuff that I'm testing with 3.14 already. So that's awesome. And it's not just easy. It's also low impact. It's not like you're taking over your machine's latest Python is now this alpha thing. Yeah, right. Yeah, yeah.

Same goes true for free threaded Python, right? You can get that with Ruby. Pretty cool. All right. This wasn't even going to be here, but then I was thinking about it as we were setting up. I just set up a FastMail account. And wow, FastMail is so much better than proton mail for what i've been doing these days like proton mail is always slow and clunky and even things like archiving like

they have a hot key to archive your mail and you're viewing the mail and you press archive it's like three seconds later before it archives it and it goes away like what is it's doing so i've switched my personal mail over to fast mail and so far, I highly recommend it. Yeah, I've been using it for a while. I love it. You like it? Yeah, I'm really enjoying it as well. Okay.

Well, that brings us to our joke. Okay. And back to HTTP status codes. What episode is it, Brian? I don't remember. 418. 418. Well, let's go down to status code 418.

And there was somebody in one of the socials, Mastodon or Blue Sky, I can't remember, I believe, who said, it's coming up. It's coming up. You got to do this. And they were still right. They were still right. And they gave us a picture. And I can't find the post again. So I'm sorry. I can't shout out credit, but thank you for sending that in. H2Pstatuses.io slash 418, 418. Client error, 418. I'm a teapot. This is literally in the HTTP spec. You can return it for whatever value it serves. 418, I'm a teapot. Any attempt to brew coffee with a teapot should result in an error code. 418, I'm a teapot.

The resulting entity body may be short and stout. I am quite disappointed in Python. I am disappointed. There's a.NET enumeration, status code status, status 418, I'm a teapot. There's a RustNET enumeration, status code status, status 418. I'm a teapot. There's a Rust. I'm a teapot.

There's a Go status teapot. There's no Python. I'm a teapot. They didn't implement all of the status codes. Come on, people. Oh, dear. This could be my first pep, right? Yeah, I think you should do this as a pep.

I got to get this. I got to get this accepted. Yeah, so one, it's funny. But also, do you think it's in place just for something for people to debug their status codes or something? Yeah, possibly. I'm pretty sure it was an April Fool's joke that got into the spec, and people are like, we're doing it. Yeah, we just have to keep it. I'm a teapot.

This is a perfect status code. So this is I'm a teapot episode. I mean, show title right there. What do you think? Yeah, definitely. Number 418, I'm a teapot. Let's go. Hopefully the RSS readers will still get it.

I know. Will they read the 200 okay on the RSS or will they read the title? The 418, we'll see. And they will go, we're sorry, podcast flutter is not short and stout yeah i hope so well i hope it actually works uh awesome we'll see where it goes but that was a lot of fun as has been doing this show for 418 episodes so thanks for being here yeah thank you yeah thanks to everyone who listens bye