Python Bytes - #274 12 Questions You Should Be Asking of Your Dependencies

Episode Date: March 9, 2022

Topics covered in this episode: The Adam Test: 12 Questions for New Dependencies Validate emails with email-validator The Python on Microcontrollers Newsletter Git Organized: A Better Git Flow CPython issues moving to GitHub soon * MicroPython, CircuitPython and GitHub* Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/274

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 274, recorded March 8th, 2022. I'm Michael Kennedy. And I'm Brian Ocken. And I'm Ian Peralta. Welcome, Ian. It is so great to have you here. It's going to be a lot of fun to talk about Python things with you, and devices, and maybe even space. Who knows? I'm glad to be here. Thank you very much for

inviting me. Yeah, absolutely. Before we get into our topics, just tell people a quick bit about yourself. You've had a varied background and you've done a lot of interesting things. I may be known in the Python community as the author of the book, Getting Started with Adafruit Circuit Playground Express, which goes over CircuitPython. And I've done numerous tutorials and blog posts for Adafruit Industries, where I've been working for the past four years. Prior to that, I had a 30-year career with the U.S. Department of State as a diplomat and security engineer, reaching the level of the senior foreign service. Wow.

Oh, neat. Awesome. I bet you have some stories to tell that you can't tell. I have some I can and some I can't. Indeed. Indeed. All right. Well, welcome to the show.

It's nice to have you here. Thank you. So, Brian, there's that old famous saying, programming is like riding a bike. Is that how it goes? What is it? I've never heard that. Oh, yeah.

Neither have I. Tell us about your bike okay so i'm not sure what the bike is for but um actually it's a cool looking bike but anyway what we're talking about is uh adam johnson's article uh the well-maintained test 12 questions for new dependencies and he's calling it the well-maintained test, but I'm going to call it the Adam test. I think, I think the Adam test is better. Um, and anyway, he's referencing, um, do you remember Joel Spolsky's the Joel test? I remember, remember Joel Spolsky. Okay. I don't, I don't remember the test though. Okay. So he has, he has this test, um, and it's referenced in this blog post, but I'm not going to click over to it, but there's a link in here.

But it's essentially like trying to, it's a 12 question, question and answer thing of like yes and no questions about whether or not you, whether or not your software team is healthy. It's interesting, a little bit dated, but it's an interesting read. But that's way back from like the year 2000.

So before a lot of you were born. But now we've got the Adam test. And it's about whether or not you should pick up a dependency on your project. So again, there are yes, no questions. And there's 12 questions. And it's kind of, zoom in a little bit. It's just questions about a project. so let's just run through them uh is is it described as production ready and is is there sufficient documentation is there a change log is someone responding to bug reports are there

sufficient tests that's a that's a tough one actually to answer if you're from the outside but are the tests running on the latest Python version or the test running on the latest integration version? So he says language and integration. So for instance, is it running on the latest, is it running Python 3.10 in CI? And is it running the latest Django version if it's a Django utility or PyTest version if it's a PyTest plugin or something. Is there a CI configuration? Is it running on CI? Is it CI passing? Does it seem relatively well used? And there's ways to look for that with PyPI stats. And then has there been a commit in the last year? And has there been a release in the last year? The 12 been a release in the last year the 12th one is

interesting i think because sometimes there have been commits there are maintainers that are pushing to the main line uh but um but nobody's actually releasing to pi pi because the actual one person that has uh release privileges doesn't hasn't been doing that um i i i'm not sure i guess what do you think he goes through more detail, but do you have any comments on this? Uh, either Michael or Ann? I'd like this list. I mean, uh, obviously it's directly related to some of the work we've been doing, uh, at, uh, Adafruit. I mean, and, uh, we're trying to make sure that we don't have bottlenecks like there are multiple people have authorization to do releases and merges and that type of thing.

And it would be rather unsettling if there was a package that was several years old and no releases and that's where you start getting into problems. Sure. I totally agree. Things can be done. There can be a, like, here's a thing that parses CSS styles. Like, maybe that just doesn't need to be updated, but that's not the case for most things.

Here's a web framework. It hasn't changed in four years. That might make you nervous because the web has changed a lot in four years. And Python's changed. So is it even, it just takes a little bit to, you have to push to kick the CI and test on, I guess you don't have to,

you can manually kick CI to run it on the latest Python version. Yeah, one more area, and that might be multiple little additions or it might be grouped into one that people understand as a group of things, but does it use modern language ideas and constructs?

So for example, does it use Python type hints or no? Does if it's something that is inherently talking to external systems or something like that, does it use async in a way? Is there an async capability, right? Or if I'm like, well, I really want to use fast API and I have this database that would be awesome to talk to, but this thing in the middle that does the database part, there's no async version. Well, then I've thrown away, I cannot access that part of the new Python world, right? And so those kinds of like group that into, does it use modern Python ideas and features?

Yeah, that one's a tough one because sometimes a project will want to support older Python versions, so they can't really. Yes, exactly um one of the things ann said that i wanted to highlight was i like this question this these 12 questions to ask of my own projects not i mean yes it's for dependencies but i also these are good questions just to ask for your own project or like how how am i doing how am i doing um and i have this package that's kind that's kind of used by a handful of people or maybe a thousand people. But if I've not updated in the last couple of years, that's kind of lame. I should just take a few hours and go check it out. Push something up.

Yeah, for sure. All right. Now that I see your list and know what you're talking about, I love it. It's great. I want to talk about abusing things. Let's talk about stack abuse. Okay. No, stack abuse is just the blog from Stack Overflow.

But what I want to talk about is validating email addresses. So this might sound like a solved problem, right? We've talked about regex 101 and stuff like that. And surely you can go, you can get some regular expression and apply it to an email address. Now that may or may not be good. I've, there are so many little weird domains these days. Like I just got a dot tech domain that is four letters on the end. And if your regex is like, does it go thing at sign something dot three or two things. Well, that fails. I've had that email address come up and say, Oh, you got to enter a valid email address. Like this is a valid email

address. You crummy reject from 2000. You know what I mean? So this one goes a little bit beyond that. Like it does validate that kind of stuff that you're thinking about, right? It does validate that like there's an at sign and there's a domain at the end and those kinds of things. But it also does a couple of other things that I think are worth considering. That's kind of cool. So for example, one of the things that it'll do, if I scroll down a little bit, is it will actually check that the domain is real. So if you were to say, my email is something at blah, blah, blah, junk, junk, junk, just type in junk, like, no, no, no, there's no way that could be delivered. So it's going to validate, like actually do a DNS lookup on the domain name

for that, right? So it'll check on the internet that this is a real thing. It also does some interesting things about normalization or canonicalization of the email. So for example, there's different ways to represent the same thing in Unicode and stuff like that. And you'll end up with a, here's the definitive way in which you should express this in your database so that you can check, have I seen this before or things like that. You could even get ASCII representations of it from what comes back. So pretty cool. It'll do the check for deliverability, and then it also does that normalization plus the regex. Wow.

Neat, right? Yeah. All right. Yeah. I mean, it's not going to change the world, right? We all have to validate email addresses and whatnot, but putting just type equals email in an HTML form is not going to tell you that, for example, the DNS exists and things like that. So I think this is a cool sort of next level version and it's a Python package that runs on the server. You just pip install it and then you call validate. And of course it'll, you know, it needs to do the DNS lookup and stuff like that. I like it. Cool. Yeah. Awesome. Yeah. It's really easy to use. So I think that

that's a nice feature. And it's production ready and as a fairly recent release. Awesome. I'm glad you checked on it. And before we switch over to Ann's first topic, John Sheehan out in the audience says, for phone numbers, I had really good luck with phone numbers, all one word, no spaces, Python library. Oh, very cool. Yeah, that has, I think phone numbers are more complicated than emails in the sense that like they're different lengths and styles and all sorts of stuff. Well, I've lived in many places in the world and so many people do this US centric phone number check and do not parse it for international numbers and it drives people crazy.

Yeah, I bet it does. Cool, all right. Well, tell us about your first item. Well, I was going to talk about one of the main things I've been doing with Adafruit that's Python related and that's the Python and Microcontrollers newsletter. We think this is the only newsletter focusing on Python on very small hardware devices.

And I started as editor about the time of the pandemic when priorities were switched and somebody said, well, I've got to do something else. Here, it's yours and okay um so uh we currently have about 9400 subscribers and it focuses mainly on the two flavors of python that run on small devices on hardware and that's circuit python and micropython um CircuitPython and MicroPython. When I say it, it's kind of obvious that the full CPython will not fit on a device with limited memory and capabilities. So MicroPython was first developed in CircuitPython. I'll talk about it later in the show. that actually work on very small devices and provide a very Python experience in coding these as compared to C or assembly

or some of the other ways in which people do it. So this is obviously free and open source just like everything else Adafruit does and hopefully much of the Python world. Yeah, one of the real exciting things I've seen going on with you all is working to get CircuitPython and MicroPython more close together.

So it's kind of one world for the small Python things. Sure. I mean, CircuitPython is a fork, but we bring in the upstream features of MicroPython, and we provide some compatibility through a library called Blinka. So on certain microcontrollers, you can take a MicroPython program and run it in CircuitPython. But there's some differences that were chosen. And again, I'll go over those in a bit. But the two programs talk to each other. It's a very

friendly relationship. Adafruit has provided support to MicroPython uh we consider it kind of a big happy family rather than uh the hatfields and the mccoys nice um if anybody's interested in our weekly newsletter they can go to adafruit daily.com and it was specifically chosen to be a different uh domain than adafruit um because there's no sharing of information between, nothing behind the curtain even. It's a totally separate website. None of the data is used for advertising and all the things that one does when they sign up on the web, it's pure and clean. And it's easy to subscribe and unsubscribe. There's no pressure to say, oh, do you really want to unsubscribe? I've been going through this process of unsubscribing from a tremendous number of old newsletters that have just piled up. And so many of them are like,

type in your email address here and uncheck the four things you would like to unsubscribe to i'm like you know this is not stopping me we're typing this in and this is happening i'm out of here so yeah that's good to hear yeah no one wants to actually go to that much effort i've made you know just one click and you know you're gone you can come back if you want to um but we really uh encourage, encourage community, um, involvement in this. It's not. And writing her own thoughts together and putting them down, uh, via GitHub to WordPress. It's, um, uh, there are different ways in which people can contribute. It's all done on GitHub.

So people can put an issue if they like, or actually a PR on the current document. And, and I review those. You accept PRs for your newsletter? Sure. That's awesome. Why not? I mean, I've not had that many issues. We have some instructions on, okay, if you're going to put an image in, you know, make it a certain size and parameters. If you're going to put an image in, you know, make it a certain size and parameters. If you're going to put an animated GIF, you know, kind of do it this way. Otherwise, you know, just kind of, as long as it's kind of in the same format, I'll take it. Again, we try to be very GitHub friendly. We love GitHub. And again, all our stuff's open source on GitHub. So, you know, people can do whatever they wish and we want to encourage communication. But, you know, if people don't want to use GitHub,

they can email the information to cpnews at adafruit.com or they can hashtag CircuitPython or MicroPython on, say, Twitter twitter and uh i do i go through and pick up things cool yeah very cool yeah i i subscribe to the newsletter thank you yeah you bet i love the idea of a sort of direct community involvement brian we should just put our show notes up beforehand and let people do prs against that love it we just have like a Trello board. Well, I didn't put it up here, but the, one of the things we do when we, we tout circuit Python, um, the phrase is code bus community, and we have a pretty broad community on, um, again, like Twitter, um, a large discord server, um, Reddit, um reddit um instagram just wherever you might try to to get information uh we try to to target um copying it on there and uh yeah and i think i think uh um adafruit and circuit python are doing

community correctly or at least doing it a good way because it's it's obvious and like for discord we have a code of conduct that's you know plain to see for circuit python it's very similar to the discord one it's it's kind of the the philosophy of you know do good things you know be good yeah everybody get along. We welcome good-hearted things to happen. And for 99.9% of it, it works. Because CircuitPython is not Adafruit. We want CircuitPython to be much, much, much bigger than Adafruit as far as adoption and effort. And again, that reflects over to MicroPython.

And the whole thing goes to the bigger Python community. I mean, Guido van Rossum has tweeted and various things saying, yes, he supports Python on small devices. I mean, small devices to supercomputers. I mean, it all works. Yeah, that's awesome. Yeah. Very cool.

All right. Well, people should check it out for sure. Now, before we move on, I do want to talk about our sponsor for this week, Microsoft for Startups, Founders Hub. They're doing super cool stuff. As someone who has started his own small business, it is a lot of work. There's a lot of uncertainty and knowing how to get help and having support of people who have experience

is really, really valuable. So starting business is hard. They say that by some estimates, 90% of all the startups will go out of business in the first year, which is tough, but that's how it is. With that in mind, Microsoft's for startups set out to understand what startups need to be successful

and create a digital platform to help overcome those challenges. And that's where they got their Founders Hub. So Microsoft for Startups Founders Hub provides all founders at any stage with free resources to help them solve startup challenges. You get technology benefits, access to expert guidance and skilled resources mentorship networking connections and so much more so and unlike a lot of other similar programs in the industry it doesn't require startups to be investor backed or third-party validated to participate founders hub is just open to everyone so what do you get you get uh you can speed up your development with free access to github and microsoft cloud resources that have a bunch of credits that unlock over time so you can grow without worrying about paying for stuff.

They also help startups innovate. They're partnering with companies like OpenAI, an AI research and deployment company, to get extra benefits through their partners as well. So with the Founders Hub, it's not really about who you know. You have this access to this mentorship network. So you get access to a pool of hundreds of mentors across a range of disciplines, areas like idea validation, fundraising, management, and coaching sales and marketing and specific technical stress points. I think that might be the most valuable, honestly, is, Hey, I need to talk to this person or

somebody. Is this a good idea? Is this how I should be doing? And so on. So you can book a one-on-one meeting with mentors, any of whom are founders themselves. So make your idea a reality today with critical support that you'll get

from Microsoft for Startups Founders Hub. During the program, visit pythonbytes.fm slash foundershub. Click the link in your show notes. And yeah, thanks Microsoft for supporting the show. Indeed. All right, Brian, you got the next one, right? Yeah.

So I want to talk about Git a little bit. And so I've been using, I mean, I've been using Git personally for a long time and professionally for many years at work for version control, of course, but I've used others as well. And it's one of the interesting things about Git is you can do it,

you can use it a lot of different ways and trips people up actually, to start with. And so this was interesting. There's an article called get organized, a better get workflow. I actually learned about it by listening to episode 480 of the changelog, which was talking about this, this, this workflow. And the the idea it really appeals to me so i'm gonna i haven't tried it but i'm gonna try it out so i'm gonna kind of go through the idea the idea is um when i'm when you're working on a new project instead or some new code you branch your branch your create a branch off of the the master main or whatever and and then you just uh just push up your work with simple like you know comments for yourself or just you know work in

progress uh comments is all and then uh and then when you're ready that that all of that when you're ready to to do a pr or something all of those commits are going to be in a sloppy format. It's hard to review those, but you, so what the proposal for this, and this is, oh, who's the author of this? Annie Sexton. Annie's workflow is once you're at that point, you're ready to do a PR, go ahead and do a get reset of against origin main. And what that does is it keeps all of your changes that you've done, but it kind of forgets all the history. And then you can recommit in a logical order that makes sense for reviewing. So you can do, you know, I did clean up here. I added this feature over here. I fixed this bug over here. And there's a comment in the article, which I totally agree with,

is you can say, I'm going to separate those into different PRs, but often that's disruptive to your workflow. Often there's a few things you're doing. You're cleaning up while you're coding. You know, Brian, when I do that, I'm like, oh, I'm going to check this in separately. So I know that this is a special task that I'm going to like isolate and then i'm like oh no i just checked in part of it you know like it's yeah it's so easy to go oh darn i was doing these two things at the same time and yeah so yeah i i feel that so some of the benefits of this are that it's it's helps uh for uh big prs so once you're once you're done you've got a pull request that if somebody looks at the individual commits in the PR, they're broken up into easy to review bits.

And I think that's lovely. And I definitely wouldn't do something like this for a one line change or a small change. That's kind of overkill. But for things that you're working on for a while, this is sort of a cool workflow to play with. And I think I'm going to try it out. Looks neat. Yeah, this looks great. I'm definitely going to explore it as well, because I was just listening to a podcast where somebody was talking about like, oh yeah, I issued a PR to myself and then I accepted it. And other people laughed. They're like, that's so weird. Why would you do a PR to yourself? But like these organizing ways of like, this is the whole

feature or this is the whole feature or this is the whole thing that I did. Like there's real value in having that as a, oh no, what changed across this? I need to go back and compare or like know the totality of it and stuff. I really like these organizing ideas. So I'm definitely going to look into it. What do you think, Ian? I like it too. My, my workflow and that of a couple of colleagues I, uh, I can think of, uh, would, would benefit from that because some things get chaotic. Oftentimes with data fruit, um, you're working on something, you kind of get blocked and then you go to something else.

Um, it's very easy to say, okay, where am I? And, and where did I leave off? I think, uh, anything to help that. Wonderful. Yeah. Very cool. I definitely use the feature branch, do a bunch of changes over there, PR these days, even if it's just, I'm the only one who's going to see it because it's, it just helps me organize for sure. All right. Speaking of Git and organizing on all that thing, all those things, traditionally, if you want to issue a bug or track changes to CPython, you'd have to go over to bugs.python.org, I think it was. And yet a long

time ago, they moved the CPython source code to GitHub. So it would be natural, like, well, if you're already there and you want to do a PR against GitHub, wouldn't it be awesome if the issue was there? So you could say at issue 1,226,000, whatever it is, this solves that, or this addresses that, or something like that. And so that's starting to happen. And I believe that this is really one of the things that's being made possible by Lucas Shalenga becoming the CPython core developer in residence, because he can take the time and actually focus on getting this done. It might sound like, oh, you just copy the stuff from over in that system, and then you just create them over here. But there's stuff going on that makes this a little bit tricky. So if you look at the article I'm linking to by Lukasz, GitHub issues, migration is coming soon. There is a bunch of stuff going on about testing and how long it takes.

Let me see if I wrote that down, like one of the actual durations. So it was pretty mind-blowing. It was like, yeah, the migration is estimated to take anywhere from three to seven days of continuous tight loop import this over to there. Next, next, next. And so some of the things they got to deal with is like, well, if it's a seven day gap and the issue appears over there, but we haven't yet closed it out on the other side, well, people could be commenting on both ones and you could

get like effectively merge conflicts, I guess you would think of them as in GitHub. So pretty wild to think about how, how they're doing this. Should they start with the newest one? So people have immediate access to that, or should they start with the oldest ones? Cause they're least likely to change. And it's, it's pretty interesting. They've compared it to some other really, really large platforms that have made a similar change. Like the LLVM project made a similar migration from Bugzilla gasp, and it took them 21 days to do to like do the import so uh yeah there's a lot of stuff going on to get the c python issues and conversation fully over to github but uh thank you lukash and team for doing this because yeah there's a lot and if you look at

the comments below there's a ton of comments that have like some pretty interesting stuff if you want to look deeper. And to be fair, some of the complexity here is because they're trying to do it without shutting people out. Because one of the things you could do is you could just turn off submissions or comments for a week and then just convert it all. Yeah, exactly. Yeah.

But then that stops conversation for a week. So anyway. I think the real challenge know, that stops conversation for a week. So anyway. I think the real challenge is it's difficult to turn off partial. It's hard to go like this older quarter of issues. We're going to turn them off and then import them. Yeah, but you can like turn everything off. You could just say. Yeah, that's the problem.

I think they don't want to turn it all off. Right. If they could do it in a more fine grained way, I think that they would already be on it. But yeah, there's a lot of conversation. That's a good point, though. Are you excited to see GitHub issues for CPython over here where they belong, next

to the code? I am. I already read this and put it on the newsletter. It's all good to have it in one place. I don't know if there's any nexus between Guido working for Microsoft, who owns GitHub, but it's definite that

where the code is and you have your discussion process integrated, and that actually gives the GitHub developers a way in which to look at which a large project,

the workflow goes as far as things, and they can make more modern optimizations to say, hey, you know, this is kind of hard. It was maybe hard in bugs.python.org. We can make it a lot easier on GitHub with maybe not today, but with a couple tweaks in the next release. Yeah, absolutely. Definitely going to do a stress test sort of thing for them.

All right. And you got the final one, the final one of our main topics? Sure. I was going to talk a little bit, my hinted at it about MicroPython, CircuitPython, and GitHub, as we were just talking about, is an important parcel in all of this. C-Python just will not work currently. I mean, somebody might someday say, okay, micro Python, which was, uh, uh, started as a Kickstarter by Damien George back in 2013, does a very good job of providing Python on small micro

controller boards, like a RAS, um, a Raspberry Pi single board computer or a micro controller board. Um, and micro controllers are all around us. Um, you know, there's one in this microphone and there's, they're everywhere. or a microcontroller board, and microcontrollers are all around us. You know, there's one in this microphone, and they're everywhere. They're sprinkled like silicon dust. MicroPython has some syntax that isn't quite the same

as CPython in certain areas. Adafruit, when looking at moving into an easy way to program microcontrollers, decided that MicroPython was a wonderful starting point, but they forked it to have some features which they wanted to focus on, which is perfectly fine because both are under MIT open source licenses, so there's no conflict as opposed to some other sharing licenses. Why the fork? Well, three things. CircuitPython boards are specifically made such that they have a USB port,

and they work just like a thumb drive. You plug it into a computer, PC, Mac, Linux, whatever, and it should show up as a thumb drive. Very small one, but you can drag a text file with your source code onto it or off of it and it just runs immediately once there's a change in the file system, it picks it up. Yeah, the programming model is super interesting, right? Like, if there's a file called a certain thing in a certain location,

it just boots and runs it top to bottom. And if that file changes, it just reboots, right? That's right. The equivalent of reboot for a $5 microcontroller. We recommend code.py. And, yeah, if it detects a change, then it just says, Okay, I'm going to restart and do things over. And, and it provides instant feedback, which a lot of people like the the tried and true code in a framework, compile, fix errors, and then upload it to some piece of hardware

is not something that a lot of people understand in 2022. Whereas anybody can copy a file from one place to another. And then they light up when they say, hey, it worked. Or, oh, I got an error message. I need to, yeah, a little syntax. I'm learning Python or something. So. Brandon out in the audience, former guest here, said,

I flashed my ESP32S to run MicroPython and haven't looked back. Especially on ESP32 processors, there's a framework by the company that makes it and it's rather daunting what you might have to do. CircuitPython or MicroPython makes it very easy to think of it just as another piece of hardware rather than a specialized way in which one might have to code it previously. Let's see what else we got. Circuit Python specifically wants to use CPython syntax whenever possible, because again, MicroPython has deviated a bit,

but we want as much CPython code to be mirrored over as possible. And finally, make it easy to use and understand for beginners. Yet pretty much most of the hooks are there, so power users can dig right in. We recently added a sync IO. You were talking about it. MicroPython actually does asynchronous work a little better than CircuitPython. It exposes some of the lower levels. And again, we recommend if the power users use that, but CircuitPython wants to come into that world also. Nice. Yeah. It also provides a lot of equipment abstraction.

There are currently 283 boards that are compatible with CircuitPython and 87 single board computers. Now, Raspberry Pi lineup everybody knows about, but what about Orange Pi and Banana Pi, the Sony Spresents? There are... Pyboard and all those things, yeah. They run CPython just fine, but if you want to hook up a specific sensor, you don't want to have to code down to the register level on shifting bits around.

Adafruit's already done that for a lot of hardware. So you throw on some software called the Blinka abstraction layer, and that interfaces between CPython on the small boards and CircuitPython code in the library. And for the most part, it just works. Nice. Yeah. CircuitPython's great. People who want to get started with small devices should definitely check that out. And there's a lot of tutorials on the Adafruit learning system and, and various websites around the internet of people who have tackled some of these interface changes.

And we encourage people to check things out, the tires. Cool. Very nice. All right. Well, that's it for our main items, Brian.

Oh, I just wanted a quick shout out 30 minutes for this next 30 minutes no i just thought that this is a really easy um quick blog post by daniel roy greenfield that i wanted to plug because it's a good idea 30 minute rule so if you're working on a problem at work or and especially at work if you have colleagues and you get stuck on the same problem for this, for the half an hour, half an hour is the mark you should ask for help. Uh, because maybe you're just spinning your wheels or wasting time. I would also add in, maybe that's time to just get up and

go get some coffee, go have some lunch, uh, walk around and maybe you don't have the problem, but, um, but yeah, it's a different number for different people. But just remember, don't get stuck for too long. It's probably not you. You're just thinking about it wrong or something. Yeah. There's Twitter. There's discords.

There's places you can go and ask for help. Yeah. Or even coworkers. So I got two quick extras. One, James wrote into us. Remember I said, when you say Python 3, do you really need to go back and say, well, Python 3.7.2 and beyond is this thing I am talking,

or just like if it's an expired version of Python, do we really, you know, a non-supported out of date, like Python 3.2 or something, do you really need to explicitly not talk about it? Well, James wrote in, said, you guys were discussing Python 3 to mean any current supported version rather than say 3.7 plus or similar. In my world, that's a really bad idea. There's still tons of people using unsupported versions of Python, and they're not all valid

use cases. For example, I'm one of the upstream maintainers of Cloud Admit. Now it's only recently able to remove Python 3.5 in order to make 3.6 our minimum supported version, which will continue for a year. The reason is that our main customers are downstream distro packages like Ubuntu and Red Hat and so on. And it's not uncommon for software released into long-term support LTS OSs to be supported for five to 10 years. So that's a world that I don't live in, but I didn't really think about the LTS story of like, yeah, we're going to support this for 10 years and it comes with this. So it's got to keep getting that. So yeah, that's a very valid point, James. And thanks for, thanks for sharing your experience. Top of the list of jobs I don't want.

Is it 10 years old? I can't change it. Okay. And then I was going to talk about Paul Cutler's new podcast, The Circuit Python Show. If you're into Circuit Python, check it out. He's really into Circuit Python and he and I have talked a lot about getting him set up on this podcast. So congrats. Happy to see that out there.

And I hear you're going to be on the show. Is that right? Yes. In an upcoming episode, I will be on it. You know, Paul is not affiliated with Adafruit, no paid, no, he has independent control. It's his baby, but we love the fact that he's doing it. We've recommended people in the community that he might want to chat with. And again, he's, he's interviewing, you know, the odd Adafruit person, but,

and I mean, that there are many other people. And I like what he's doing a lot. Yeah, this is the first episode. He's also got like a preview thing of like, what is this thing I'm doing? And it's good so far. So today it's speaking of it's less pounder. Today, it's Les Pounder. He works, he's done a lot in the UK. He's working for Tom's Hardware and he's done a lot with CircuitPython.

So it's wonderful. Speaking of podcasts, I just want to give a quick announcement, Brian, that we traditionally have not been on Spotify. I now moved our stuff over to Spotify. So if people want to listen on Spotify for Python Bytes, it is now there. We've joined the dark side.

We have joined the dark side. All right. That's it for all of our stuff, right? Are we ready for a joke? Yeah. Sure. You know, we're recording Tuesday, March 8th. Imagine that it is Friday and coming to work.

Has this ever happened to you? Me on Friday. I'll just stop here and pick up where i left off me on monday this is developer just staring like holding their head like what what was i do why did i not make a better note of this why did i not write this down what is happening yeah that's that's good we can all we can all relate right right and oh definitely been there so you got to give good whip comments to yourself uh when you commit on last on friday but friday you're trying to get out you know you're trying to uh you know start your weekend i mean notes i mean exactly exactly this this is the

hangover though this is what you get i love it i do too all right well i love that ann came to join and i love being here with you, Brian, every week. So thank you both. Yeah. And thanks everybody that was on the stream watching. Yep. Thank you. It's been a lot of fun.

I enjoyed it. Yeah. Same. Bye. Thanks for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. Get the full show notes over at PythonBytes.fm.

If you have a news item we should cover, just visit PythonBytes.fm and click submit in the nav bar. We're always on the lookout for sharing something cool. If you want to join us for the live recording, just visit the website and click live stream to get notified of when our next episode goes live. That's usually happening at noon Pacific on Wednesdays over at YouTube. On behalf of myself and Brian Ocken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.