#418 I'm a tea pot
20:22 Share

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 pi test course check out his course and a bunch of my courses over at talk python training and thank you to patreon subscriber 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 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, pythonbyst.fm 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. And 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 Side FM, click on newsletter. It's the very center of the five buttons in the hero image. And all you gotta 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 is 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...

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 Python. And then also he wrote a package called mock that was separate for a while, but then I think it was 3.3 or something early in the 3Xs got incorporated into the standard library as unit test dot mock. So if you're mocking anything, even if you use, so pytest mock is what 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, that Michael was an original thinker started the tradition of having the language summit events at PyCon. That's pretty big. And, 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 the in memoriam. So Guido suggests that to feel free to post positive memories of Michael and

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. 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 Nicholas Toller V.

who I've also had on the Test and Code podcast, also a great guy. He's the dude from the MU editor. He wrote up my friend Michael, a post about losing Michael, and there's some great pictures. He was a larger than life. That's a great one. Larger than life 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 TalkPython, and we talked about this deployment process.

system, kind of like cookie cutter, but way more, 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 fit and which of these don't or whatever. But 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. Um, 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, it's main

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, sets, so you can ask for probably like

I want to 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

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, you like see 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 Valkyrie, yeah, check it out. Cool. Cool. All right. Back to you. Let's see. Doing this again. Okay. There are,

I'm going to go back to Michael Ford again, because actually in 2017, he wrote an article called 30 Best Practices for Software Development and Testing. And...

I think I didn't talk about it on this podcast because my intent was to talk about it on Testing Code and interview Michael. 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 really great article, 30 Best Practices –

I'm not going to read all of them, but I want to read like a few of them. Yagney, it's not the only place I've listened, heard the term Yagney, but Yagney is number one. Yagney 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. Right? Like write it so it 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. Tools to refactor. Just test to make sure it works. Yep. Yeah.

I'm going to jump down a little bit. A bunch of great stuff in here. Oh, I love this. 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 test, testability.

tests, 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 Marcus 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. The 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...

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. Gosh, I feel that way about help docs, help strings, doc strings sometimes. Yeah. It's like there's three lines of code and 18 lines of doc string. Like, wow. If that just weren't there, I could read it. 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. Anyway.

Um, 15, we'll jump to 15. Uh,

The more you have to mock out to test your code, the worse your code is. That was one of the things that surprises me coming from him. This is the dude that wrote the mock library. 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-driven 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, they, 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. So yeah. And plus you're going to hurt his feelings if you mock it. It's just not nice. I mean, sometimes you got to just not nice. Come on. Yeah. That's funny. Anyway, a great article. Go have a, go have a read. I've already, I reposted it on a,

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, Bugtied from the Light, you can see there's a image here, and that's the thumbnail from YouTube. And we have...

stuff in Python by Stout 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 thumbnail. Now you might think, why don't you just put the YouTube in bed 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

or whatever it is you're using, right? - Yeah. - 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, it doesn't have a file name, but it's a PNG, or it's a JPEG, or whatever, right?

So back to my item, mime type.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, and 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 is 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 like 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 201 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 the enclosed payload has been modified from that of the origin server's 200 OK response by a transforming proxy. Woo! 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 the takeaway is mimetype.io which i wish were called content type.io but whatever it still works okay i like mine types yeah like the types that are stuck in a bubble like i can't get out i know yeah they really they really do act it out they do act it out

Sorry. No, it's all right. All right. That's it for main items, right? Yeah, I think so. You got any extras? I just noticed just one. I noticed somebody posted online today that Python 1.1 is out. Actually, 31 years ago, as of today, Python 1.1. On January 27th, 1994, Guido posted 1.00 is out. So anyway. I'm tired of deciphering that Perl 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, I don't know. We'll see if that thing takes off. Hope so. It's got a future. Yeah. 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 4 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 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 usually haven't been testing new stuff until we get to betas. But UV has made it so easy to load up

pre-release stuff that I'm testing with 3.14 already. 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. Yeah.

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 ProtonMail for what I've been doing these days. Like ProtonMail is always slow and clunky and even things like archiving. Like they have a hotkey 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 doing? So I've switched my personal mail over to FastMail 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. 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 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 accepted. Yeah, so...

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 were like, we're doing it. Yeah, we just have to keep it. I'm a T-Pod. It's a perfect status code. Yeah.

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, I'm a Teapot. We'll see. We're sorry. Your podcast letter is not short and stout. Yeah, I hope so. No, I hope it actually works. Yeah.

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, and thanks to everyone who listens. Bye. Bye.