Brought to you by Michael and Brian - take a Talk Python course or get Brian's pytest book


« Return to show page

Transcript for Episode #274:
12 Questions You Should Be Asking of Your Dependencies

Recorded on Tuesday, Mar 8, 2022.

00:00 Hello, and welcome to python bytes where we deliver Python news and headlines directly to your earbuds. This is episode 274. Recorded March 8 2022. I'm Michael Kennedy lamb Brian Aachen, and I'm in Berlin. Welcome, man, it is so great to have you here. It's it's gonna be a lot of fun to talk about Python things with you and devices, and maybe even space. Who knows?

00:22 Oh, I'm glad to be here. Thank you very much for inviting me.

00:26 Yeah, absolutely. Before we get into our topics, just tell people quick bit about yourself, you. You've had a varied background, and you've done a lot of interesting things

00:34 I may be known in the Python community is the author of the book make getting started with Adafruit circuit playground Express, which goes over circuit Python, and I've done numerous tutorials and blog post or Adafruit Industries, where I've been working for the past four years. Prior to that. I had a 30 year career with the US Department of State as a diplomat and security engineer reaching the level of Senior Foreign Service.

01:03 While Oh, neat, awesome. But you have some stories to tell that you can't tell.

01:07 I have some I can at summer camps. Indeed,

01:11 indeed. I 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, no, I neither have I. Tell us about your bike.

01:26 Okay, so I'm not sure what the bike is for. But actually, it's a cool looking bike. But anyway, is what we're talking about is Adam Johnson's article, the well maintained tests 12 questions for new dependencies, and he's calling it the well maintained test, but I'm going to call it the atom test. I think, I think the atom test is better. And anyway, he's referencing, do you remember Joel Spolsky, is the Joel test.

01:53 I remember. Remember Joel Spolsky. Okay, I don't I don't remember the test, though.

01:58 Okay, so yeah, he has this test. 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 or no questions about whether or not you whether or not your software team is healthy. It's 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 atom test. And it's about whether or not you should pick up a dependency on your project. So in there, again, there, yes, no questions. And there's 12 questions. And it's a it's kind of xumo bit. It's just questions about a project. So let's just run through them. 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? Are the tests 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? 310. And in CI, and is it running the latest Django version? If it's Django utility or PI test version, if it's a PI test plugin or something? Is there a CI configuration is you know, is it running on CI? Is it Pat, the CI passing? Does it seem relatively well used? And there's there's ways to look for that? Pipeline, IPI stats? And then has there been a commit in the last year? And has there been a release in the last year? The 12 point was interesting, I think, because sometimes there have been commits, there are maintainers that are pushing to the mainline, but But nobody's actually released into pi pi, because the actual one person that has release privileges doesn't hasn't been doing that. I, I'm not sure. I guess, what do you think he goes through more detail, but do you have any comments on this? Either Michael, or

04:08 I do like the Smiths. I mean, obviously, it's directly related to some of the work we've been doing at Adafruit. I mean, and we're trying to make sure that we don't have bottlenecks, like, there, multiple people have authorization to do releases and, and, and merges and that type of thing. And it would be rather unsettling if there was a package that was several years old and, and no releases, and that's where you start getting into problems.

04:45 Ah, sir, I totally agree, things can be done. There can be a like, here's the thing that parts of 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. Hmm, that might make you nervous. because the web has changed a lot in four years,

05:02 and Python has changed. So is it even is even it just takes a little bit to you have to push to get kick the CI intestine, I guess you don't have to you can manually kick CI to run it on the latest Python version. But

05:15 yeah, one 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? And await? 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 throw it away, I cannot access that part of the new Python world. Right. And so those kinds of group that into does it use modern Python ideas and features?

05:59 Yeah, that's, that one's a tough one, because sometimes a project will want to support older Python versions. So they can't really but yes, exactly. One of the things and said that I wanted to highlight was, I like this question this these 12 questions to ask have 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 of like,

06:20 how am I doing? How

06:20 am I doing? And I have this package that's kind of kind of used by a handful of people, or maybe 1000 people. But if I've not updated in the last couple of years, that's kind of him, I should just take a few hours and go check it out. Put something up. So yeah,

06:36 for sure. I know that I see your list. And now 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, one to one 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's so many little weird domains these days, like I just got a dot tech domain that has 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, say, Oh, you got to enter a valid email address like this is a valid email address you crummy regex from 2000. You know what I mean? Yeah. 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 ad 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 that blah, blah, blah, junk, junk junk, just type in junk, like 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 and 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 can even get ASCII representations of it. From what comes back. So be cool. It'll, it'll do the check for deliverability. And then it also does that normalization plus the regex. Oh, neat right now. Great. Yeah, I mean, it's, it's not gonna change the world, right? We often validate email addresses and, 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 need to do the DNS lookup and stuff like that. I like cool. Yeah. Awesome. Yeah, it's really easy to use. So I think that that's, that's a nice feature. So

09:28 let's and it's production ready, and as a fairly recent release.

09:34 Awesome. I'm glad you checked on him before we switch over to Anne'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 links and styles and all sorts of stuff.

09:55 Why Glip 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,

10:11 I bet it does. Cool. Well, tell us about your first item.

10:14 Well, I was gonna talk about one of the main things I've been doing with Adafruit. That's Python related. And that's the Python on 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 parties were switched. And, and somebody said, Well, I've got to do something else here that you are since Okay, so 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 circuit Python and micro Python. It's it, when when I say it, it's kind of obvious that the full C Python will not fit on a device with limited memory and, and capabilities. So micro Python was first developed in circuit Python, I'll talk about it later in the show that actually work on very small devices and provide a very Pythonic experience in coding knees as compared to C or assembly or are some of the other ways in which people do it. Yeah. So this is obviously free and open source just like everything else, Adafruit does, and hopefully, much of the Python world.

11:47 One of the real exciting things I've seen going on with you all is working to get circuit Python and micro Python more close together. So it's kind of one world for the small Python things.

11:58 Sure. It's, I mean, circuit Python is a fork, but we we bring in the upstream features of micro Python, and we provide some compatibility through a library called blinkers. So on certain microcontrollers, you can take a micro Python program and run it in circuit Python. But there's, 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 micro Python, we consider it kind of a big happy family rather than the Hatfields and the McCoys is 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 domain that Adafruit because there's no sharing of information between the young, nothing behind the curtain even. It's a totally separate website. It's none of the data is used for advertising. And you know, all the things that one does when they sign up on on the web. It's it's pure and clean. And it's easy to to subscribe and unsubscribe, there's no pressure to say, Oh, do you really want to unsubscribe. And

13:33 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, 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.

13:52 Yeah, no one wants to actually go to that much effort, I've made no, just one click, and you're gone, you can come back if you want to. But we really encourage community involvement in this, it's not in writing her own thoughts together and putting them down via GitHub to WordPress, it's, 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 reviewed those

14:29 you accept PRs for your newsletter? Sure. If that's awesome,

14:33 why not? I mean, I, I've not had that many issues. I'm great. We have some instructions on okay, if you're gonna put an image in, you know, make it a certain size and parameters if you're gonna put a 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 for we'd love to GitHub and, again, although all our stuffs 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 CP news@adafruit.com. Or they can hashtag circuit Python or micro Python on, say, Twitter. And I do, I'd go through and pick up things.

15:28 Cool. Yeah, very cool. Yeah, I subscribe to the newsletter. Thank you. Yeah, you bet. I love the idea of sort of direct community involvement. Brian, we should have put our show notes up beforehand to let people do PRs against I'd love it. We just have like a Trello. Board.

15:43 Well, I didn't put it up here. But that one of the things we do when we we tapped circuit Python, the phrase is code us community. And we have a pretty broad community on again, like Twitter, a large Discord server, Reddit, Instagram, just wherever you might try to to get information. We try to, to target copying it on there. And yeah,

16:15 and I think I think it Adafruit and circuit Python are doing community correctly, or at least doing it a good way, because it's obvious.

16:24 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 philosophy of, you know, do good things, you know, be good. Yeah. No, everybody get along. We welcome. good hearted things to happen. And it for you know, 99.9% of it, it works. Because the circuit, Python is not Adafruit. We want circuit Python to be much, much, much bigger than Adafruit, as far as adoption and effort, and again, that that reflects over to micro Python, and the whole thing goes to the bigger Python community. I mean, we have an awesome as is tweeted and various things saying, Yes, he supports Python on small devices, I mean, small devices to supercomputers. I mean, it all works. Yeah,

17:24 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 supportive 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 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 hubs 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 industry, it doesn't require startups to be investor backed or third party validated to participate. Founders hub is just opened everyone. So when you get you get, 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 open ai, ai research and deployment company to get extra benefits through their partners as well. It's 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 and 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 should be doing and so on. So you can book a one on one meeting with mentors in your home, our 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 Python bisetta FM slash founders hub, click the link in your show notes. And yeah, thanks, Microsoft for supporting the show. Nice, indeed. All right, Brian, you got the next one, right.

19:46 Yeah. So oh, I want to talk about get a little bit and so I've been using I mean, I've been using Git personally for a long time and for professionally for many years at work for version control, of course, but I've used others as well. And, and there's, it's one of the interesting things about Git is you can do it, you can use it a lot of different ways. And that trips people up actually, to start with. And so this was interesting, there's an article called Get Organized to a better Git workflow, I actually learned about it, by listening to Episode 480 of the change log, which was talking about this, this, this workflow. And the idea, it really appeals to me. So I'm going to, I haven't tried it, but I'm gonna try it out. So I'm going to kind of go through the idea. The idea is, when I'm when you're working on a new project, instead, or new, some new code, a branch or branch, you're create a branch off of the master main or whatever, and, and then you just just push up your work with simple like, you know, comments for yourself, or just, you know, work in progress, comments is all and then. And then when you're ready, that that, all of that, when you're ready 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 anti Sexton and he's workflow is once once you're at that point, you're ready to do a PR, go ahead and do a git 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, 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 did, I added this feature over here, I fixed this bug over here. And in 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.

21:58 You know, Brian, when I do that, I'm like, I'm gonna check this in separately. So I know that this is a special task that I'm going to like, isolate. And then I like, oh, no, I just checked in part of it. Yeah. 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, see, yeah, I feel that so

22:13 some of the benefits of this are that it's, it's helps for 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 I, and I, you know, definitely wouldn't do something like this for, you know, 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 a trade out. looks neat.

22:47 Yeah, this looks great. I'm definitely gonna export 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 and other people laughed, like, That's so weird. Why would you do a PR to yourself, but like, these, these organizing ways of like, this is the whole feature, or this is the whole thing that I did, like, there's real value and having that as a, oh, no, what changed across this, I need to go back and compare or like, know, the totality of and stuff, I really like these organizing ideas. So I'm definitely gonna look into it. What do you thinking?

23:19 I'd like it to nine, my workflow flow, and that of the couple colleagues I can think of, would would benefit from that, because some things get chaotic. Oftentimes, with data, fruit, you're working on something, you kind of get blocked, and then you go to something else. It's very easy to say, Okay, where am I? And where did I leave off? I think, anything to help? Wonderful.

23:48 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 gonna see it, because it's, it just helps me organize for sure. Alright, speaking of Git, and organizing on all that thing, all those things. Traditionally, if you want to issue a bug or track changes, to see Python, you'd have to go over to bugs.python.org, I think it was, and yet, a long time ago, they moved the C Python 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 like 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 lukesh Langa, becoming the C Python core developer and residents 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 and that system, and then you just create them over here, but there's stuff going on that like makes this a little bit tricky. So if you look at the article I'm linking to by lukesh, GitHub issues, migration is coming mean 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, it was pretty mind blowing. It was like, yeah, the migration is estimated take anywhere from three to seven days of continuous tight loop import this over to their 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 close it out on the other side, like 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, because they're the 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, it took them 21 days to do to like do the import. So yeah, there's a lot of stuff going on to get the C Python issues and conversation fully over to GitHub. But thank you, Lucas 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

26:25 at it. To be fair, the 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, you could turn off submissions or comments for a week and then just convert it all. Yeah, exactly. Yeah. But But then that, you know, that stops can conversation for a week. So anyway,

26:45 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. You can like everything off, you could just say that's the I think they don't want to turn it all off. Right? They 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 that they kind of enter to see. Yeah, excited to see GitHub issues, for C Python over here, where they belong next to the code

27:14 I am. I've already read this and put it on the newsletter. It's all good to happen in one place. You know, I don't know if there's any nexus between Guido working for Microsoft, who owns GitHub, but that definitely that, you know, if the where the code is, and you have your, 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, we, this is kind of our, it was maybe hard in bugs.python.org, when we can make it a lot easier on on GitHub with maybe not today, but with a couple tweaks in the next release.

28:11 Yeah, absolutely. Definitely gonna do a stress test sort of thing for them. Alright, and you got the final one. The final one of our main topics.

28:19 Sure. Um, I was going to talk a little bit, my internet about micro Python circuit Python, how and GitHub, and we were just talking about is, is a part and parcel and all of this, that C Python just will not work currently. I mean, somebody might someday say, okay, blue, Moon down, see Python, but for now, micro Python, which was started as a Kickstarter by Damien George back in 2013, does a very good job of providing Python on small microcontroller boards, like a rasp, a Raspberry Pi, single board computer or a microcontroller board and microcontrollers are all around us. You know, there's one in this microphone and there's, they're everywhere. They're sprinkled like silicon dust micro pi. THON has some syntax that isn't quite the same as C, Python and certain areas. Adafruit, when looking at moving into an easy way to program microcontrollers decided that micro Python was a wonderful starting point, but they 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. Circuit Python 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, how it picks it up. Yeah,

30:28 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. If that file change, if it doesn't reboot, right, that's writing the equivalent of reboot for a $5 microcontroller,

30:43 that we recommend code.pi. 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. And 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 build syntax. I'm learning Python or something. I'm so

31:30 Brandon out in the audience, former gas air said I flashed my ESP 32 s to run micro Python and have a look back

31:37 the special on ESP 32 processors, there's a framework by the company that makes it it's rather daunting. What you might have to do, um, circuit Python and micro Python 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 previous. Um, let's see what else we got. Oh, circuit Python specifically wants to use C Python syntax whenever possible. Because again, micro Python as as deviated a bit, but we want as much C Python code to be mirrored over as possible. Finally, make it easy to use and understand for beginners yet, you know, they're all pretty much most of the hooks are there. So power users can dig right in. We recently added a sink IO. You were talking about it? Yeah. Um, micro Python actually, does a synchronous work a little better than circuit Python, it exposes some of the lower levels. And And again, we we recommend if the power users use that, that circuit Python wants to come into that world also. Um, nice. Yeah. Um, it also provides a lot of quipment abstraction that there are currently 283 boards that that are compatible with circuit Python 87 single board computers, not Raspberry Pi lineup, everybody knows about but what about orange pie and banana pie? The Sony's presence

33:24 there, our pie board and all this? Yeah,

33:27 um, that they run C Python 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 on shifting bits around. Adafruit already done that for a lot of hardware. So you throw on some software called the blink abstraction layer. And that interfaces between C Python on the small boards and circuit Python code in the library. And most part, it just works.

33:56 Nice. Yeah. Good. Circuit pythons. Great. People want to get started small devices should definitely definitely check that out.

34:03 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.

34:20 Oh, very nice. Well, that's it for our main items, Brian.

34:24 Oh, I just wanted a quick shout out 30 minutes for this next 30 minutes. No, I just thought that is a really easy, quick blog post by Daniel Roy Greenfield that I wanted to plug because it's 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 half an hour, half an hour's the mark, you should ask for help. 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. Yeah, someone absolutely walk around and And then maybe you don't have the problem. But 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 it's, you're just thinking about it wrong or something. So yeah,

35:12 there's there's Twitter, there's discord, there's places you can go and ask for help. And yeah, or even coworkers. So I got two quick extras. One James wrote into us remember I said, when you say python three, do you really need to go back and say, well, Python 372? and beyond? Is this thing iron tie? Or just like, if it's an expired version of Python? Do we really, you know, a non supported out of date, like Python, three, two, or some do really need to explicitly not talk about it? Well, James wrote in said, you guys, were discussing python three, to mean, any current supportive version rather than, say, three, seven 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. Invalid use cases. For example, I'm one of the upstream maintainer is a clouded nit. Now, it's only recently able to remove python three, five in order to make three six or 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 yeah, that's a 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 gonna 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

36:35 experience top of the list of jobs. I don't want

36:39 it 10 years old, I can't change it. Okay. And then I was gonna talk about Paul Cutler's new podcast, the circuit Python show. If you're in circuit Python, check it out. He's He's really into sort of 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?

36:58 Um, yes. In a 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 I mean, odd that there are many other people. And

37:33 I like what he's doing a lot. Yeah, it was 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 speaking,

37:43 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 circuit Python, so to

37:54 speak, in a podcast, I just want to give a quick announcement, Brian, that we traditionally have not been on Spotify now moved our stuff over to Spotify. So people want to listen on Spotify for Python bytes. It's not joined the Dark Side. We have joined the Dark Side. Alright. That's it for all of our stuff. Right? Are we ready for a joke? Yeah. Trump, it's you know, it's we're recording a Tuesday, March eighth. Imagine that is Friday, and come into 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 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 not write this down? What is happening? Yeah, that's, that's good. We can all we can all relate. Right? Right in Oh, definitely been there.

38:43 So we got to give good whip comments to yourself. When you commit blast on Friday,

38:50 Friday, you're trying to get out. You know, you're trying to, you know, start your weekend. I mean, note some in

38:57 the actly. Exactly. This. This is the hangover, though. This is what you get. Love it, too. All right. Well, I love that and came to join and I love being here to Brian every week. So thank you both.

39:06 Yeah, thanks, everybody. The that was on the on the stream watching.

39:11 Yeah, thank you. It's been a lot of fun. Enjoyed it?

39:15 Yeah, say bye. Thanks for listening to Python bytes. Follow the show on Twitter via at Python bytes. That's Python bytes as in BYD s. Get the full show notes over at Python by Sarafem. If you have a news item we should cover just visit by them by setting them 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 Aachen, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page