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 Okken.
And I'm Ann Barola.
Welcome, Ann. 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 actually, it's a cool-looking bike.
But anyway.
It is.
What we're talking about is Adam Johnson's article, 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 the Adam Test is better.
And anyway, he's referencing – do you remember Joel Spolsky's The Joel Test?
I remember Joel Spolsky.
Okay.
I don't remember the test, though.
Okay.
So, 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 and no questions about 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 – let's zoom in a little bit.
It's just questions about a project.
So, let's just run through them.
Is it described as production-ready?
And is there sufficient documentation?
Is there a change log?
Is someone responding to bug reports?
Are there sufficient tests?
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 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 – is the 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 12th one is interesting, I think, because sometimes there have been commits.
There are maintainers that are pushing to the main line.
But nobody's actually releasing to PyPI because the actual one person that has release privileges hasn't been doing that.
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 Ann?
I'd like this, Miss.
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, 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, like, here's the 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?
Yeah.
Does it use async and await?
Is there an async capability?
Right.
Or if I'm like, well, I really want to use FastAPI 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.
One of the things Anne said that I wanted to highlight was, I like these 12 questions to ask of my own projects.
I mean, yes, it's for dependencies, but I also, these are good questions just to ask for your own project.
How am I doing?
And I have this package 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 and 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.
There are so many little weird domains these days.
Like I just got a .tech domain.
That is four letters on the end.
And if your Regex is like, does it go thing, at sign, something, .3 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 Regex 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 be cool.
It'll do the check for deliverability.
And then it also does that normalization plus the regex.
Wow.
Neat, right?
Yeah.
You're 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 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.
So let's...
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 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.
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 I said, okay.
So we currently have about 9,400 subscribers and it focuses mainly on the two flavors of Python
that run on small devices on hardware.
And that's 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.
Yeah.
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.
It's, 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.
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.
We consider it kind of a big happy family rather than the Hatfields and the McCoys.
Nice.
If anybody's interested in our weekly newsletter, they can go to AdafruitDaily.com.
And it was specifically chosen to be a different domain than Adafruit because there's no sharing
of information between, you know, 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 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.
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.
But we really encourage community involvement in this.
It's not Anne 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 review those.
You accept PRs for your newsletter?
Sure.
That's awesome.
Why not?
I mean, I've not had that many issues.
No, it's great.
We have some instructions on, OK, if you're going to put an image in, you know, make it a
certain size and parameters.
If you can 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 friend.
We love GitHub.
And again, although 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.
And I do.
I go through and pick up things.
Cool.
Yeah.
Very cool.
Yeah.
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 one of the things we do when we tap CircuitPython, the
phrase is code plus community.
And we have a pretty broad community on, again, like Twitter, a large Discord server, Reddit,
Instagram, just wherever you might try to get information.
We try to target copying it on there.
And yeah.
And I think Adafruit and CircuitPython are doing community correctly, or at least doing it a
good way because it's obvious.
And like for Discord, we have a code of conduct that's, you know, plain to see.
For CircuitPython, it's very similar to the Discord one.
It's kind of the philosophy of, you know, do good things, you know, be good.
Yeah.
You know, everybody can get along.
We welcome good-hearted things to happen.
And it, for, you know, 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 in 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.
It's tough, but that's how it is.
With that in mind, Microsoft 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, 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, 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?
So you can book a one-on-one meeting with mentors, many 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/founders hub.
Click the link in your show notes.
And yeah, thanks to Microsoft for supporting the show.
Nice.
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 it trips people up, actually, to start with.
And so this was interesting.
There's an article called Get Organized, a Better Git Workflow.
I actually learned about it by listening to episode 480 of the Change Log, which was talking
about this workflow.
And the idea, it really appeals to me.
So I haven't tried it, but I'm going to try it out.
So I'm going to kind of go through the idea.
The idea is when you're working on a new project instead or some new code, you create a branch
off of the master or main or whatever.
And then you just push up your work with simple comments for yourself or just work in progress
comments is all.
And then when you're ready, 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?
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 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, I did clean up here.
I did, I added this feature over here.
I fixed this bug over here.
And it, and there's a comment in the, 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, 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 what I mean?
Like it's, it's so easy to go, oh darn, I was doing these two things at the same time.
And yeah, so yeah, I feel that.
So 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, 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, I 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 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, and other people laughed.
They're 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 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 flow and that of a couple of colleagues I, 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 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 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 Lucas
Shalanga 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 like makes this a little bit tricky.
So if you look at the article I'm linking to by Lucas, 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.
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 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 least likely to change?
And 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 the import.
So yeah, there's a lot of stuff going on to get the CPython issues and conversation fully over to GitHub.
But 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 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.
They kind of held off.
And 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.
You know, I don't know if there's any nexus between Guido working for Microsoft who owns GitHub.
But it's definite that, you know, 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 about MicroPython, CircuitPython, and GitHub, as we were just talking about, is an important parcel in all of this.
That CPython just will not work currently.
I mean, somebody might someday say, okay, we'll slim down CPython.
But for now, MicroPython, which was started as a Kickstarter by Damian George back in 2013, does a very good job of providing Python on small microcontroller boards, like a Raspberry Pi single board computer or a microcontroller board.
And microcontroller boards, like a Raspberry Pi single board, which is a very good job of providing Python.
Yeah.
And microcontrollers are all around us.
You know, there's one in this microphone, and they're everywhere.
Yeah.
And that's kind of a great job of providing Python.
I mean, I think it's a great job of providing Python and software, but it's a great job of providing Python, and it's a great job of providing Python.
And that's kind of a great job of providing Python, which is a great job of providing Python, and it's a great job of providing Python, and it's a great job of providing Python, and it's a great job of providing Python.
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.
And you plug it into a computer, PC, Mac, Linux, whatever, and it should show up as a thumb drive.
Very small one, you know, 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 it provides instant feedback, which a lot of people like.
The tried and true code in a framework compile, fix it 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 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 have a look 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.
Nice.
Let's see what else we got.
Oh, CircuitPython 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.
Finally, make it easy to use and understand for beginners, yet, you know, pretty much most of the hooks are there, so power users can dig right in.
We recently added a SyncIO.
You were talking about it.
Yeah.
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's presence?
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 those small boards and CircuitPython code in the library.
And for the most part, it just works.
Nice.
Yeah.
CircuitPython is great.
People who want to get started with small devices should definitely, definitely check that out.
And there's a lot of tutorials on the Adafruit learning system 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.
We've got 30 minutes for this next one.
Let's do it.
30 minutes.
No, I just thought this is a really easy, 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 especially at work, if you have colleagues and you get stuck on the same problem for the half an hour, half an hour is the mark, you should ask for help.
Yeah.
Maybe you're just spinning.
Maybe you're just spinning your wheels.
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.
Yes.
Go have some lunch.
Absolutely.
Walk around.
Maybe you don't have the problem.
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.
There's Twitter.
There's Discords.
There's places you can go and ask for help or even coworkers.
So I got two quick extras.
One, James wrote in to 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 about?
Or just like if it's an expired version of Python, do we really, you know, a non-supported out-of-date Python 3.2 or something, do you really need to explicitly not talk about it?
Well, James wrote in.
He 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 invalid use cases.
For example, I'm one of the upstream maintainers at CloudInit.
Now, I was 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 OS is 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 sharing your experience.
Top of the list of jobs I don't want.
Is it 10 years old and 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 interviewing, you know, the odd Adafruit person.
And I mean odd, 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 yeah, it's good so far.
So today, it's speaking of it's less 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 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 not there.
Join 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 doing?
Why did I not make a better note of this?
Why did I not write this down?
What is happening?
Yeah, that's good.
We can all relate.
Right?
Right, Ian?
Oh, definitely.
Been there.
That's why you got to give good whip comments to yourself when you commit last on Friday.
But Friday, you're trying to get out.
You know, you're trying to, you know, start your weekend.
I mean, notes.
I mean.
Exactly.
This is the hangover, though.
This is what you get.
Love it.
I do, too.
All right.
Well, I love that Ian 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 Livestream 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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.