Transcript #418: I'm a tea pot

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

00:05 This is episode 418, recorded January 27th, 2025.

00:10 And I am Michael Kennedy.

00:12 And I am Brian Arkin.

00:13 And this episode is brought to you by us.

00:16 Check out Brian's pytest course.

00:18 Check out his course and a bunch of my courses over at Talk Python Training.

00:22 And thank you to Patreon subscribers, supporters there.

00:26 We appreciate all of you.

00:27 And even if you don't do any of those things, we appreciate that you listen.

00:31 That's why we get to do this stuff.

00:32 You want to connect with us?

00:33 We're Blue Sky Mastodon mostly these days.

00:37 Links for Brian, me and the show all in the show notes.

00:41 You can join us live, pythonbysetfm.com slash live.

00:44 A few of you are, most of you aren't.

00:46 That's fine.

00:46 But we do that if you want to join.

00:48 Usually Monday at 10 a.m. Pacific time.

00:50 Sometimes things go a little haywire.

00:52 You can always watch the video replay on the episode page if it's available.

00:56 And finally, Brian and I are crafting.

00:59 We're continuing to hone our artisan craft, Brian, for the artisan newsletter.

01:05 So if people want to get the newsletter, they can go right to Python by Setup M.

01:10 Click on newsletter.

01:11 It's the very center of the five buttons in the hero image.

01:14 And all you got to do is give us your name and email and we will send you summaries, insights, the joke.

01:21 And a couple of things we're doing different now.

01:23 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.

01:30 So if they want that, they can check it out.

01:32 And with that, what would you like to talk about first today?

01:35 I actually want to talk about something that's not really wonderful, but I think we should talk about it anyway.

01:40 So this last weekend we lost Michael Ford.

01:43 And many of you might not know who that is, but he was influential.

01:48 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.

01:57 So one of the things that he is known for is one of the contributors to the unit test library within Python.

02:08 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.mock.

02:24 So if you're mocking anything, even if you use, so pytestMock is word I usually use often, but it's a wrapper around that library.

02:32 So a lot of great stuff from Michael.

02:35 He was a larger than life character.

02:37 There is an in memoriam that's up on the python.org discuss site started by Guido.

02:46 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.

02:57 That's pretty big.

02:58 And if I recall, the IRC was that, if I recall correctly, together with Barry Warsaw.

03:04 So he also wrote the mock library.

03:06 And in memoriam, so Guido suggests that to feel free to post positive memories of Michael.

03:18 And perhaps maybe he's got kids, 10 and 13, so hopefully later they can look back and see how influential he was.

03:25 And I really had a hard time with this, actually.

03:28 I had a couple losses in my family recently.

03:32 And I wasn't really close to Michael, but I kind of wished I would have been.

03:38 I did interview him.

03:40 I tried to interview him early and eventually did, in 2021, get to talk to him about mocking for the Testing Code podcast.

03:51 So just listen to this.

03:53 It's a great, again, it's a great episode.

03:55 He's got some great advice towards software development and testing.

03:59 So check that out also.

04:01 There's also a really great write-up from Nicholas Tollervie, who I also had on the Testing Code podcast.

04:09 Also a great guy.

04:10 He's the dude from the MU editor.

04:14 He wrote up my friend Michael a post about losing Michael.

04:20 And there's some great pictures.

04:22 He was a larger than life.

04:24 That's a great one.

04:24 Larger than life character.

04:26 There's a paragraph in here I wanted to read.

04:29 He was a walking paradox, both completely certain of himself and yet always questioning everything.

04:35 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.

04:45 Anyway, goodbye, Michael.

04:47 You will be missed.

04:48 Yeah, thoughts out to the whole community, friends, family.

04:53 I didn't get a chance to meet Michael, but certainly it looks like he was very influential.

04:57 Yeah.

04:57 Indeed.

04:58 All right.

04:59 Hopefully you got something a little less depressing next for us.

05:03 Yes.

05:03 Well, it starts with a real smiley picture, so it's going to start out pretty well.

05:07 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.

05:18 A whole infrastructure for initially Django apps, but growing from there.

05:24 Anyway, during that, we talked about a bunch of the building blocks of those tools and of that framework.

05:29 And that's how we get to the next one, something called Valky.

05:32 Do you remember, I mean, you know Redis, right?

05:35 So Redis, key value store, it's people sometimes group it in the database category for when you're doing like surveys and what database you use.

05:45 Redis, JSON, or SQL Server.

05:48 Like, huh, wonder which one I should pick.

05:50 Which of these fit and which of these don't or whatever.

05:53 But, 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.

06:00 I believe it can persist.

06:01 Well, anyway, it's gone through some funky licensing.

06:05 This is not new, by the way.

06:06 This is not new.

06:06 But it's been that way for a little while, and I don't know.

06:09 I've always had prickly reactions with the folks from Redis, but whatever.

06:13 I ran across this thing called Valky, like value key, key value store.

06:20 And Valky is a truly open source, no license, no cost, no nothing alternative to Redis.

06:28 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.

06:35 So here, I'll just give you the quick first paragraph.

06:38 Valky is an open source, high performance, key value data store that supports a variety of workloads, such as caching, primarily, right?

06:46 Message queues and can act as a primary database.

06:49 Valky can run either as a standalone daemon or in a cluster, which is pretty awesome with replication and high availability options.

06:56 It even has native support for, well, strings, obviously, numbers, probably, but hashes, listsets, so you can ask for probably like, I want a query into this dictionary type of thing.

07:05 Pretty cool.

07:06 People can check it out if you go to the GitHub somewhere.

07:10 There's got to be a GitHub, right?

07:11 Here we go.

07:12 And you go to the repositories somewhere.

07:15 Oh, there it is right there.

07:16 Finally.

07:17 Found it.

07:17 18,000 GitHub stars, 700 forks.

07:20 So it's got a lot of life to it.

07:22 And let's see.

07:23 Does it tell you how old it was?

07:24 About a year old, I think.

07:26 Anyway, isn't that cool?

07:27 I think it's really neat.

07:28 Yeah, I'll definitely check this out.

07:30 I do too.

07:30 I'm pretty excited about it.

07:32 I'm not using anything like this yet, but there's some situations where I might be able to use this recently.

07:37 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.

07:46 Because a lot of times, you've got to restart these things.

07:49 They have to repopulate the cache.

07:50 And that can be really kind of slow.

07:52 And, you know, you see systems fall down.

07:54 Then they can't quite get back up because the cache isn't there.

07:57 And they keep getting killed.

07:58 Anyway, these are pretty neat technologies if you need them.

08:01 And Valky, yeah, check it out.

08:03 Cool.

08:03 Cool.

08:03 All right.

08:04 Back to you.

08:05 Let's see.

08:06 Doing this again.

08:07 Okay.

08:08 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.

08:19 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.

08:28 And that was a long story as to why we didn't talk about this.

08:33 But I can't believe we haven't covered this yet.

08:35 So a really great article, 30 Best Practices.

08:38 I'm not going to read all of them, but I want to read like a few of them.

08:42 Yagni, it's not the only place I've listened, heard the term Yagni, but Yagni is number one.

08:48 Yagni stands for you ain't going to need it.

08:50 So don't write code that you think that you might need in the future, but don't need yet.

08:54 Just don't do that.

08:55 You write it in the future because you might not need it.

08:58 Yeah.

08:58 People stress so much about this.

09:00 Like, oh, we got a plan for the future.

09:01 We got to get just right.

09:02 Or just embrace refactoring.

09:04 Just embrace refactoring.

09:05 Right?

09:06 Like write it so it works now.

09:07 And if you need to change it, there's all sorts of amazing tools to change it.

09:10 Source Control doesn't not break it so you can save it.

09:12 We'll refactor.

09:13 Just test to make sure it works.

09:15 Yep.

09:17 Going to jump down a little bit.

09:18 A bunch of great stuff in here.

09:20 Oh, I love this.

09:22 When it comes to API design, simple things should be simple.

09:26 Complex things should be possible.

09:28 I can't remember.

09:29 I don't remember if I got this from him or not, but I live by this.

09:33 Trying to keep the easy things easy.

09:36 And it can be complicated for the not easy things.

09:39 That's okay.

09:40 Number six is unit tests.

09:43 Unit tests test to the unit of behavior, not the unit of implementation.

09:50 And these are kind of fighting words.

09:53 This is pretty much the difference between classical versus Marcus test driven development.

09:59 But I stand by Michael's side on this one.

10:02 Number eight.

10:04 We've got a couple more that I want to hit.

10:05 Number eight.

10:06 Code is the enemy.

10:08 It can go wrong.

10:09 It needs maintenance.

10:09 Write less code.

10:10 Delete code.

10:11 Don't write code.

10:12 You don't need less code.

10:14 It's true.

10:15 The less code you got, the less bugs could be in there.

10:17 For the most part, as a general rule.

10:20 Last one that I want to cover.

10:22 More about nine as well, by the way.

10:24 Oh, nine.

10:25 Yeah.

10:25 Inevitably code comments become lies over time.

10:28 Yeah, definitely.

10:28 In practice, few people update comments.

10:31 I still remember that I had a code base that there's so many comments in them.

10:35 And there were boilerplate comments that in order to understand the code, I wrote a script

10:41 to copy the entire code base into a different directory structure.

10:44 and strip all the comments out.

10:46 And it was so much easier to deal with.

10:48 Gosh, I feel that way about help docs.

10:50 Help strings.

10:51 Doc strings sometimes.

10:52 Yeah.

10:53 It's like there's three lines of code and 18 lines of doc strings.

10:56 Like, wow.

10:57 If that just weren't there, I could read it.

10:59 Yeah.

10:59 And then that can blow up the entire file.

11:01 If each function is like that, you've got a few hundred lines of code and 2,000 lines

11:07 of file.

11:08 Anyway.

11:08 Anyway.

11:08 15.

11:10 We'll jump to 15.

11:12 The more you have to mock out to test your code, the worse your code is.

11:18 And that was one of the things that surprises me coming from him.

11:22 This is the dude that wrote the mock library.

11:24 And one of the things he discusses in the episode where I got to interview him is he was developing

11:32 this when he was on a team that was doing a mock test, you know, a mockist isolation test

11:38 driven development philosophy.

11:40 And they ran into the issues that I've run into before also is if you're testing the implementation,

11:47 that means when you have to refactor your code, your tests don't help at all.

11:52 They just all break.

11:54 So testing behavior is better.

11:56 And then also just trying to not have to mock your code.

12:00 That's not a hard and fast rule.

12:01 Sometimes it's the easiest thing.

12:03 So.

12:03 Yeah.

12:04 And plus you're going to hurt his feelings if you mock it.

12:05 It's just not nice.

12:08 I mean, sometimes you got to.

12:09 Just not nice.

12:10 It's just not nice.

12:10 Come on.

12:11 Yeah.

12:11 That's funny.

12:14 Anyway.

12:14 Great article.

12:15 Go have a read.

12:18 I've reposted it on social media and a lot of people have said, hey, this is great.

12:23 Awesome.

12:23 It's good.

12:24 All right.

12:25 I got a question for you, Brian.

12:27 Okay.

12:27 If you're working on a web project, and I've been working on some web projects, and you

12:32 have to do direct requests, like say, for example, over on Python Bytes, if I go to, say,

12:38 like our latest, which is very, very close to being not true, but our latest episode,

12:43 Bug Tied from the Light, you can see there's an image here.

12:47 And that's the thumbnail from YouTube.

12:48 And we have stuff in Python Bytes.fm that when you load this page, it'll look for the

12:54 YouTube link, and then it'll talk to YouTube.

12:56 Pull that and get the thumbnail.

12:58 Now, you might think, why don't you just put the YouTube embed right there?

13:02 Because Google is parasitic, and when you embed a YouTube video, it puts tracking cookies

13:09 onto you, which means we would have to have a cookie banner.

13:12 Do you accept our cookies?

13:14 Because we're making our website better for you by tracking you.

13:16 Like, I'm pretty sure you're not, but okay.

13:19 Or you could download the image, put it in your database, and then serve it out of court,

13:24 or Flask, or Pyramid, or whatever it is you're using, right?

13:27 Yeah.

13:28 When you do that kind of stuff, you need to know what the MIME type is, or the content

13:32 type, more importantly.

13:33 Like, you need to tell the browser, this is not just binary stuff, but this is an image.

13:37 I know it came from a database.

13:38 It doesn't have a file name, but it's a PNG, or it's a JPEG, or whatever, right?

13:42 So back to my item, MIME type.io, which I would prefer to say is content type.io.

13:48 But, you know, for example, tell me, what is the content type of a JPEG?

13:53 Well, it's probably image slash JPEG, but is there a E in there, like JPEG, or is it JPG?

13:59 Hmm.

14:00 But you better not get it wrong, right?

14:02 So there's this site, MIME type.io, and you just type in whatever file extension you think

14:08 you can imagine.

14:09 It'll tell you it's image slash JPEG with an E, not without.

14:12 And it shows you all the file type extensions for which this applies.

14:16 And it gives you, like, the history of it, what if there's other things it's known as.

14:21 Like, sometimes, I think if I put it in JSON, there might be, like, JSON is application slash

14:26 JSON, but there's a deprecated text slash JSON.

14:29 It might also appear as.

14:31 Isn't that cool?

14:32 Yeah.

14:32 Yeah.

14:33 So if you're doing web projects and you need to send files, you need to specify the content

14:38 type.

14:38 And here you go.

14:38 This is how you do it.

14:39 So I really like this.

14:40 I ran across this.

14:41 And I had tipped to a very, very similar project for HTTP status codes at HTTP statuses.io.

14:48 So, for example, you've seen 200, 201, like 200 is good.

14:52 201 is created if you did, like, post a new thing or whatever.

14:55 What is about 203?

14:57 I don't know, man.

14:59 But if you click on it, it says this is a, you know, lets you dive into them.

15:03 It's a 203 non-authoritative information.

15:05 This request was successful.

15:06 But the enclosed payload has been modified from that of the origin server's 200 OK response

15:12 by a transforming proxy.

15:14 Woo!

15:14 But it also shows you, like, how to get to these as enumerations in, say, Python or the

15:20 new new Python and so on.

15:22 Right?

15:22 So you're not programming with magic numbers like 203 or quote 203.

15:26 Sometimes these are representative strings, and I don't know why.

15:28 But yeah.

15:28 Anyway, we're going to come back to this for our joke.

15:31 But the takeaway is mime type.io, which I wish were called content type.io.

15:36 But whatever.

15:36 It still works.

15:37 Okay.

15:37 I like mime types.

15:38 Yeah.

15:39 Like the types that are stuck in a bubble.

15:42 Like, I can't get out.

15:43 I know.

15:44 Yeah.

15:44 They really do act it out.

15:46 They do act it out.

15:47 Sorry.

15:49 No, it's all right.

15:50 All right.

15:50 That's it for our main items, right?

15:51 Yeah, I think so.

15:52 You got any extras?

15:54 I just noticed, just one.

15:56 I noticed, sorry.

15:58 I noticed somebody posted online today that Python 1.1 is out.

16:03 Actually, 31 years ago, as of today, Python 1.1.

16:07 Yeah.

16:07 That's awesome.

16:08 On January 27th, 1994, Guido posted 1.00 is out.

16:12 So anyway.

16:13 I'm tired of deciphering that Perl code you got last week.

16:16 Sick of CGI.

16:17 Let's go.

16:18 Frustrated with born shell syntax.

16:20 Yeah.

16:21 Yeah, yeah, yeah, yeah.

16:22 Yeah.

16:23 Funny.

16:24 Cool.

16:24 Well, I don't know.

16:25 We'll see if that thing takes off.

16:26 Hope so.

16:28 It's got a feature.

16:29 We'll see.

16:30 All right, cool.

16:31 I got a few extras.

16:32 I'll keep it quick.

16:33 I don't got a lot.

16:33 Speaking of releases, Python 3.14.0 Alpha 4 came out last week, minutes after we recorded

16:42 our last episode.

16:43 So since last time, something to announce.

16:46 People can check it out.

16:47 It's coming along.

16:48 This is Alpha 4.

16:48 That means there's three more Alpha releases.

16:50 Then we hit beta.

16:51 Then you can start to treat it seriously as a fixed item, right?

16:55 Chances are no new features.

16:57 Just bug fixes and polish before it goes.

16:59 Although I'm sure they could decide, you know, this is too rough.

17:02 We're not going to make it.

17:03 We'll take a feature out.

17:04 But the idea is that the betas are fixed.

17:07 Yeah, and actually, so I usually haven't been testing new stuff until we had to betas.

17:13 But UV has made it so easy to load up pre-release stuff that I'm testing with 3.14 already.

17:20 That's awesome.

17:21 And it's not just easy.

17:22 It's also low impact.

17:23 It's not like you're taking over your machines.

17:26 The latest Python is now this Alpha thing.

17:28 Yeah, right.

17:29 Yeah, yeah.

17:31 Same goes true for free-threaded Python, right?

17:33 You can get that with UV.

17:35 Pretty cool.

17:35 All right.

17:36 This wasn't even going to be here, but then I was thinking about it as we were setting up.

17:39 I just set up a Fastmail account.

17:41 And wow, Fastmail is so much better than Protonmail for what I've been doing these days.

17:46 Like Protonmail is always slow and clunky and even things like archiving.

17:51 Like they have a hotkey to archive your mail.

17:53 And you're viewing the mail and you press archive.

17:55 It's like three seconds later before it archives it and it goes away.

17:58 Like what is it doing?

18:00 So I've switched my personal mail over to Fastmail.

18:02 And so far, I highly recommend it.

18:04 Yeah, I've been using it for a while.

18:06 I love it.

18:06 You like it?

18:07 Yeah.

18:07 I'm really enjoying it as well.

18:08 Okay.

18:09 Well, that brings us to our joke.

18:11 Okay.

18:12 And back to HTTP status codes.

18:14 What episode is it, Brian?

18:16 I don't remember.

18:17 418.

18:17 418.

18:18 Well, let's go down to status code 418.

18:20 And there was somebody in one of the socials, Mastodon or Blue Sky, I can't remember,

18:24 I believe, who said, it's coming up.

18:26 It's coming up.

18:27 You got to do this.

18:28 Oh, yeah.

18:29 They were still right.

18:30 And they gave us a picture.

18:31 I can't find the post again.

18:32 So I'm sorry.

18:33 I can't shout out credit.

18:34 But thank you for sending that in.

18:35 htpstatuses.io slash 418.

18:38 418.

18:38 Client error.

18:39 418.

18:40 I'm a teapot.

18:41 This is literally in the HTTP spec.

18:44 You can return it for whatever value it serves.

18:46 418.

18:47 I'm a teapot.

18:48 Any attempt to brew coffee with a teapot should result in an error code.

18:51 418.

18:51 I'm a teapot.

18:52 The resulting entity body.

18:54 may be short and stout.

18:55 I am quite disappointed in Python.

18:59 I am disappointed.

19:01 There's a .NET enumeration.

19:03 Status code.

19:04 Status.

19:05 Status.

19:05 418.

19:06 I'm a teapot.

19:07 There's a Rust.

19:08 I'm a teapot.

19:08 There's a Go.

19:09 Status teapot.

19:10 There's no Python.

19:11 I'm a teapot.

19:12 They didn't implement all of the status codes.

19:14 Come on, people.

19:15 Oh, dear.

19:16 This could be my first pep, Ryan.

19:18 Yeah.

19:18 I think you should do this as a pep.

19:20 I got to get this accepted.

19:21 Yeah.

19:23 So one, it's funny.

19:25 But also, do you think it's in place just for something for people to debug their status codes?

19:32 Yeah.

19:32 Possibly.

19:33 I'm pretty sure it was an April Fool's joke that got into the spec, and people are like,

19:38 we're doing it.

19:39 Yeah.

19:39 We just have to keep it.

19:40 I'm a teapot.

19:41 This is a perfect status code.

19:44 So this is I'm a teapot episode.

19:46 I mean, show title right there.

19:48 What do you think?

19:48 Yeah, definitely.

19:49 Number 418.

19:51 I'm a teapot.

19:52 Let's go.

19:52 All right.

19:53 Hopefully, the RSS readers will still get it.

19:55 I know.

19:56 Will they read the 200 OK on the RSS, or will they read the title?

20:00 The 418.

20:01 We'll see.

20:02 And there we go.

20:03 We're sorry.

20:04 Your podcast letter is not short and stout.

20:06 Yeah.

20:08 I hope so.

20:08 No, I hope it actually works.

20:10 Awesome.

20:12 We'll see where it goes.

20:13 But that was a lot of fun, as has been doing this show for 418 episodes.

20:17 So thanks for being here.

20:18 Yeah.

20:18 Thank you.

20:18 Yeah.

20:19 And thanks to everyone who listens.

20:20 Bye.