Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to
your earbuds. This is episode 143, recorded August 7th, 2019. I'm Michael Kennedy.
And I'm Brian Ockin.
And Brian, we have a special guest this week.
Yeah, very special.
Yeah, Kelly Schuster-Perez. Welcome, Kelly.
Thank you. Thank you for having me.
It's great to have you here. I know you do a lot of podcasting, but you can do a little
podcasting with us in addition to that, huh?
It's very exciting. I've become quite an expert now at podcasting, I think, with my whole
25 or 26 episodes.
I would say, I don't know, Brian, what do you think? What's the major milestone you got to
cross? 10? After 10, you're kind of in?
Yeah, I think so. I don't think I'm worried about these guys. They're pretty dedicated, I think.
Yeah, definitely. You all seem to be going strong. So we'll talk more about your podcast at the end.
I'll let you get a word in about that and tell everyone. I also want to tell you that this episode
is brought to you by DigitalOcean. Check them out at pythonbytes.fm/DigitalOcean. Get a $50
credit for new users. Lots of good stuff there. Tell you more about that as well.
Brian, you want to kick us off with a keynote?
Yeah. So we don't often, there's a lot of great videos out there and sometimes we'll
recommend people that mention when new conference videos show up. So I don't even really know what
PyLondinium? PyLondinium19. I'm guessing that's a London Python conference.
Yeah, that or it's a new element discovered out far at the far end of the elemental table there.
But it sounds cool. I saw a couple people recommending this video by Lucas Lange,
his keynote about Python 2020. So that's just looking forward a little bit. It's a keynote,
so it's kind of a long talk. It's about an hour-ish. It was really interesting and it's
interesting on a lot of fronts. And what I want to highlight is he gets into that it is important for
us to try to get Python on multiple platforms and not just on the desktop or on the back end.
There's other platforms specifically like web, front-end stuff, 3D games, system orchestration,
mobile platforms that have other languages that are used more than Python. The question is really,
maybe we can get there if we don't limit ourselves to the same implementation as CPython, that maybe we
limit the implementation. And as an example, MicroPython and CircuitPython are very successful
and they are limited implementations. They don't do everything that Python can do.
Right. Those run on little tiny embedded chips, right? Like $5 chips. And so you can't put all
of CPython into that little tiny thing and expect it to behave well. So you've got like this, as you
said, limited one. And yeah, maybe that does make sense. We kind of have a limited one for the web
front-end, right? We've got Sculpt and Brython and some of those things as well. But I don't feel like
it's, maybe it's not limited enough because those are pretty massive downloads for your JavaScript.
But I think this is a really important message. And I think the idea of some kind of limited
thing is quite interesting. You know, we had the conversation or the debate at the Core Developer
Language Summit and around that about what do we maybe take out of Python or how do we create like a
minimum subset of Python? It seems like this is kind of part of that conversation.
The discussion even talked about things that I hadn't even thought about before. Like,
if you're controlling, like you would on JavaScript, you're controlling, it gets compiled down into
modern JavaScript now gets compiled down into something that isn't the same as what people
wrote it in that gets delivered to the end user. And things that, like for instance, massive imports,
maybe we don't need the same flexibility of the import system for a web front-end stuff. And it also reminded me of,
of how like C and C++ went, because there are many other compilers of C and C++, not just visual, like Visual Studio or GCC,
that are targeted. Because I, like you were saying, for different limitations, I've worked on platforms that really still felt like C++,
C++, but like they threw out the template system. You can't use that.
Sure.
He was even bringing up things like that I didn't think about, like monkey patching. Maybe we don't allow monkey patching for some cases. And I think this is a great idea.
It's definitely an interesting idea and worth thinking about. Kelly, you do a lot with education. Your main day job is teaching kids and programming and stuff, yeah?
Yes, that's correct. And we use MicroPython and CircuitPython. And I actually watched some of the keynote and I found it kind of interesting how he scrolled through the documentation. And I don't really get into that conversation with the kids on where it's coming from. I always tell them that some smart guys and girls have like put all this information in there.
And we don't have to worry about that. And in some cases, it's great because we can only do that limited amount. And it's fast. And I think there should be more of it.
What parts of programming is relevant for education and younger kids learning, do you think? What stuff doesn't matter? What stuff matters to them? What kind of programs do you teach them? Or what kind of projects do you give them, I guess?
Right now, the physical computing is really big because it's that instantaneous gratification. A lot of kids don't want to code 200, 300, 400 lines of code before something happens. So that old school thought of, oh, we're going to build an app or a game is just out of the question, I think, right now, because the kids want something, they want to code and they want it to happen.
So we particularly work on hard, you know, physical computing or a little bit of instantaneous activities.
Yeah. So Adafruit stuff, things like these little Circuit Express and so on, that kind of thing.
Correct. And the ESP and the BBC Microbit and Lego and stuff that we're going to talk about later.
Yeah. Very cool. What age group is that?
We currently are working with 10-year-olds to 13, 14-year-olds. And then as they go up higher, then they're getting more deep into Python and AI and TensorFlow and things like that.
Wow. That sounds like a way cooler education than I had.
It's totally cooler than what I had. I didn't grow up on this stuff.
Yeah. Amazing. That dovetails really well into what you want to talk about next. So tell us about Mew.
Oh, yeah. So Code with Mew is a software that was created by Nicholas Tolerbe.
And what's so great about Nick is that he's a former teacher. He's a music teacher.
And he's developed this code editor that is specifically for beginner programmers.
And it's a modal editor, whereas the kids can go and click on a mode and code in BBC Microbit, code in CircuitPython, code in ESP, PyGame.
He just added Flask. And the kids can click on it and it kind of packages everything.
So we don't have to worry about slower processing and all these nice little from import, microbit, everything.
It's right there in that package. And it just bundles things up with simplicity.
A lot of, you know, when you work in another editor like PyCharm, there's so much going on for newcomers.
You don't know where to go. With Mew, it just has these buttons and you can click, check for updates, save, flash, put on a REPL.
It's just a great little package.
Yeah, it's incredible. And it really reminds me or makes me think this is kind of what Idle should be.
The Idle editor that's built in is like kind of meant there to be like a little helpful editor, but it seems like it just doesn't help enough.
And this really brings together kind of a similar philosophy, but really making so many things easy to get started with.
And like you said, these modes you can put it into. It's very great.
All the books that are out there always tell you to install Idle or to go there and get Python.
But it's really not something that a newcomer like myself who just started coding, it's not intuitive.
So with using Mew, you're able to just jump in and start coding right away.
So it's great. And what I love about it is he's constantly updating.
He just released a mode called Flask for the kids so that they can start making some short web apps.
And he presented at EuroPython and he released a whole bunch of new alpha features of Mew, which I think is great because he's not afraid of just throwing something out or pre-alpha.
And he just lets everyone get on there and train. So it's pretty cool.
It's so exciting that Flask is on there. And the Flask, it can run on these little devices. Is that right?
It just runs on the desktop.
Yeah, I think it's really great to make it just, you know, a mode and then the kids can just start writing Flask apps.
Do they want to have a website? Well, here you go.
You flip the switch on and it's really great.
Yeah. And he just tweeted out literally like 30 minutes ago that he released a project he started two days ago called PiperCard,
which is a HyperCard inspired GUI framework based on what Adafruit had released.
And when I mentioned to my co-worker, Sean, about HyperCard, he's like, oh, I hated HyperCard.
I don't remember. I don't know if you guys used HyperCard back in the days.
I don't know if you guys were around.
I only know it in lore. I have never used it.
It's like in 1980s. So that might be dating some of us.
But what it does is he just released a it's called PiperCard.
And he's asking for feedback on it.
And you can run it through Moo by just going into the toggle, the little cog on the bottom right and install PiperCard.
And then you can run it in the Python 3 mode.
I can't wait to get my hands on it. And I just had a little bit of a play just a few seconds ago.
That's exciting. Anything that contributes to the GUI story in Python makes me happy.
It helps with that instant gratification for the kids.
You know, you can click on that button and then so that they can type something and get in there.
It's just great.
Yeah, absolutely. Brian, you're a fan of Moo, right?
Moo?
Yeah, I'm really excited to try the Flask and the PiperCard. It looks really fun.
And also CircuitPython. I want to get my daughter started working on CircuitPython.
And the serial output, how to configure that is not hard, but it's not something I can expect a nine-year-old to do.
But within the Mu editor, it just does it. It hooks up to it automatically.
Yeah, you should check out the alpha release that they launched at EuroPython.
And he has the ESP MicroPython on there as well, which is a board from Adafruit.
Yeah, super cool. I'm really happy that project exists.
So let's keep with the theme a little bit in this helping beginners.
There's a cool article that I want to reference and then just talk about some things here.
So there's an article called Understanding the Python Traceback.
And this is on RealPython, written by Chad Henson.
And I'm pretty sure one of the first experiences any new programmer has is being confronted with this traceback.
Some kind of error, probably syntax error, but maybe not, right?
It could be some other kind of runtime error.
But you get this giant dump of information.
And it's like, what is all of this?
And I just wanted to highlight this article and talk a little bit about some of the things it covers.
Because there is a wealth of information in the traceback.
And depending on the tools you're using, the tools maybe understand that.
And they can allow you to navigate different parts of your application by turning various things into hyperlinks and stuff like that.
So if you get a traceback, what do you learn right away?
You learn the type of error, attribute error, key error, something like that.
A description of the error, hopefully, sometimes.
The line of code that the error occurred on.
Usually, like, actually the syntax that that error was on.
The call stack.
And for, you know, the file names.
The line numbers.
The module names.
And even if that happened while handling some other error, right?
Some exception caused another exception to happen or things like that.
So really, really nice.
I think there's even some plug-in on PyPI that, like, colorizes this.
I can't entirely remember.
It might be a pytest extension, Brian.
Who knows?
But this article is really nice.
People should check it out if they just, you know, they've always, I'm sure they've, like I said, one of the very first things you learn about is errors.
But it's nice to kind of really highlight, actually look at all these things that are there.
So people should check that out.
One of the things that's unusual, so if you're experienced in programming but not Python, about tracebacks is they read in reverse.
Most error messages like this in other languages, they start with the error that actually happened and then where and then what caused that and so on.
But this is the reverse.
You read it from bottom to top instead of the other way around, which I think is a little bit weird.
It also has some interesting conversation and highlights of different common error messages.
If you see this type of error, that probably was caused by this.
You see this other type of error is caused by that.
And I would, I don't know if it was even covered in the article, but I would throw out the most common error you're going to run into is attribute error.
None type does not have whatever you're trying to do to the none type, right?
It's just some kind of crash there.
So it's useful if you have some more junior developers or people are learning.
I think handing this article out to them would be great.
I love this article.
I picked it up.
I looked at it after you posted it.
And then the idea of the name error being or the error being at the bottom, that's something that I never knew.
I just was like, skim down until you find something that you can figure out.
This looks like it applies.
Yeah, exactly.
They're like, line two, there's nothing on line two.
And I'm like, just keep reading.
Somewhere in there, it tells you the error.
So I love that.
I didn't know that it was only the last thing, you know, was the first.
So thank you for that.
Yeah, for sure.
But I'm constantly using my error readings lately.
When you're teaching people and especially younger kids, this is something that's got to be a little frustrating, but also, you know, something they've got to get used to right away.
And it's not really beginner friendly, I wouldn't say.
One of the things that's really nice that Al Schweiger does in his book, Automate the Boring Stuff, is like right near the beginning, he says, let me show you how to Google some errors and find ways to fix them.
And he literally spends several pages talking about, here's this problem.
Type this into Google.
You get this answer.
Here's what you mean.
Here's how you interpret it.
He kind of trains people to understand how they can solve their own problems when they hit this kind of stuff, which I think was really cool, too.
So that's one of our features as well, is going straight to Google and putting that error in.
One of the things I want to pop in is when you're just playing with some code, you might have to deal with one traceback.
When you're dealing with test suites, there might be lots of failures and lots of tracebacks altogether.
And I've found that people get a little overwhelmed with like these just lots of huge tracebacks.
So pytest has a feature that you can limit the size of the traceback.
And so I highly recommend people use short tracebacks.
It only gives you like 10 lines of code around the failure instead of having a huge traceback.
And it makes it a little less intimidating.
Yeah, you don't need to see the whole call stack all the way into the pytest library, right?
Yeah.
Because otherwise, yeah, you'll be chasing that down.
So one more thing to throw in.
I don't know that this is covered in the article, but it's definitely worth considering.
To make tracebacks more helpful, to make exception handling better and more specific, you should definitely consider making your own exception type.
Right?
If you're writing a library or you're writing an application, it's super easy to make your own classifications for errors.
Like if it has some kind of lookup, you can have it derived from key error, but, you know, means something, you know, something more specific.
And it's literally like three, two lines, three lines, probably two lines to write that, you know, class exception name derived from the exception you want, colon pass.
You're good.
You know what I mean?
Like, and it really helps communicate errors back and lets you be more specific in your try except block.
So also worth considering there.
All right.
Now, before we move on to the next one, let me just tell you about DigitalOcean.
So all of our infrastructure here runs on DigitalOcean.
When you get your audio on your player, that's flown, distributed through the DigitalOcean infrastructure, our website, our database server, everything runs there.
It's been wonderful.
It's super affordable.
It's the right level of detail.
You have enough features to do what you need, but it's not overwhelming.
Like you're trying to build the world's most complicated app.
So I definitely recommend checking out DigitalOcean.
Visit them at pythonbytes.fm/DigitalOcean.
Sign up, get $50 credit to play around for six months.
And yeah, give them a try.
It's a really good place to be.
Now, Brian, you did mention plugins and other things or settings and pytest.
So let's keep going with that.
Yeah.
So we actually, this is a listener contribution from Raycoat via email.
And he recommended us cover extension, like mypyE extensions to other tools.
So there's a flake8-mypy and a pytest-mypy.
So mypy is the, I'm sure we've covered that, talking about testing type hints in your code to verify that they're right or something.
Right.
So let me give a quick overview for people who don't know.
I mean, you sort of did.
But Python has optional type hints, right?
I could say, here's a function that has a thing, colon, int.
Now, the runtime of Python does nothing with that, right?
There's no validation.
But if you run mypyE, it will do static type checking to make sure that everywhere you're calling that function, you actually are passing integers and all that.
So all the stuff you're talking about is built on top of that.
Carry on.
Yeah.
There's a couple ideas.
Flake8 is a static type checker also.
Flake8-mypy just is an extension to that so that you're running mypy while you're running Flake8.
The interesting thing that Ray brought up is that he said that he tried to do run mypy by itself and always had trouble getting it configured right.
But with the plug-in Flake8-mypy, it just worked easier.
I don't know.
It was easier to use.
So I'm going to try that also.
I've tried mypy with limited success, so I'll try this as well.
And this extension to Flake8 is also, I guess it's Łukasz Langaday for me, but this is a project maintained by Lucas.
And then another project, these are static analysis.
But if you want to check to see if you're really using it in runtime, whether the types are right or not.
Actually, I'm not sure if I'm telling this correctly, but as part of the pytest.
No, I think I lied.
I don't think it checks runtime types.
It is still just a static type checker, but it's triggered by your pytest suite.
So pytest can check doc tests.
It can check other things as well.
And this is just an extension that runs mypy while you're running your tests.
Yeah, that's pretty cool.
I like it.
And it's maintained by our friend Dan Bader and David Tucker.
That's a good one.
Kelly, do you do any testing with the kids?
Or do you do any of these type hints where you say, hey, kids, this is an integer?
Or is the beauty of Python that you don't have to even talk about that kind of stuff?
No, we're getting into it a little bit.
We do introduce a little bit of the idea of tests in the older grade levels.
Sean, my colleague, he uses it quite often just to set parameters.
We use the lingo.
He's a big fan of tests and he's been trying to show me all of that.
So I plan to learn more this year, step by step.
Yay.
We have the test, the test book signed by somebody famous or something.
Amazing.
Got the legit version.
I'm blushing.
I know.
All right.
Speaking of working with kids, your next one has to do with Lego Education.
Tell us about this.
I don't know if you're familiar with Lego Education.
We all know the Lego bricks that you buy at the store.
But Lego Education launched a series of robots over the years.
The last robot that they launched was in 2013 called the EV3 Mindstorm.
And there hasn't been a new robot since.
The EV3 Mindstorm, you can still code with Python.
There was a gentleman named Nigel Ward who did this.
You'll have to dig into it yourself.
But this kind of convoluted way of getting Python to run on the EV3.
And it was a Debian Linux-based operating system called EV3 Dev.
So you're going to have to explain that to me.
But it was a little bit difficult for a person not knowledgeable in Python to run it on Mindstorms.
We played with it a little bit, but it's kind of convoluted.
Well, since earlier this year, they're launching a new robot called Spike Prime.
And Spike Prime is said that it's going to be running with MicroPython.
And this is really huge that Lego Education is launching this because there's over 300,000 kids who compete with Lego robotics.
And now, instead of just using the Lego programming operating system, they're now going to launch it with any programming system that they want to use and with support of MicroPython.
And earlier this year, they launched a whole guide about how to run MicroPython on top of the EV3 Dev with Pybricks.
And there's a whole bunch of people with their hands in there.
And it's just a really interesting thing.
They even have its own Visual Studio Code extension where you can click on it and install it with Visual Studio Code.
There's no need for use in Terminal.
It has all these instructions.
It kind of looks like the MicroPython API when you open up their guidebook.
And it just seems a lot easier.
And there were a couple people with their hands in this development.
And I'm not sure who started what and if it's all based on the original guide.
But Sebastian Thomas, he's one of the main contributors, it looks like, for Pybricks.
And then David Lechner, Lorenz Valk, and Antoine Van Hook are the Lego MicroPython release guys.
And they have a lot of really cool programs that they've converted into MicroPython.
So we're excited.
This is such exciting news.
This is like really a mainstream thing that will probably bring awareness of MicroPython and exposure of Python to a lot of kids and teachers.
Absolutely.
And what the cool thing is, is like EV3 Mindstorm robots, they're a little bit, you know, like all other robots.
They don't really do what you program them to do.
But with using MicroPython, you're pretty much getting down into correct angle and speed.
And you can use the gyroscope to regulate where it is on with GPS kind of coordination on a mat.
So you're going to get a little bit more controlled environment.
So we're excited.
I'm still buying that when it comes out.
It just sounds so cool.
It's really cool.
Wait till Spike Prime gets released later this year.
It looks, it's got really a lot of colors.
So I think it sounds bad, but I think it's going to get more girls involved with robotics.
It's not the basic gray and white of the EV3.
There's a lot of colors on Spike Prime.
So I'm excited about it.
Yeah, it sounds like it's going to look fun.
That's cool.
Yeah, very exciting.
Thanks for covering that one.
I think that's great.
So the last one, I want to start with a popular saying.
So 20 years ago was the best time to plant a tree.
But, you know, the second best time might be like right now.
And that's kind of the story for Mozilla.
So Mozilla has tons of Python.
And they wrote this sort of, let's look at what we're doing with Python large at Mozilla.
And what's the story around Python 3 and converting over to it?
So they say, hey, look, we actually have 3,500 Python files at Mozilla Central, which is like 230,000 lines of code, which is a lot of Python.
And they also have 462 repositories over at the Mozilla or GitHub repo organization.
So they've got a lot of stuff going on with Python.
And they looked and they said, you know, most of this is Python 2 only.
Boo-hoo.
So we all know that the end of life of Python 2 is quickly approaching.
Brian, you were talking about Python 2020.
Like that sounds still to me way in the future.
I don't know what 2020 is, but that is maybe we'll have flying cars by then.
I don't know.
But that's way out there, isn't it?
This next year.
I know.
It's like five months.
It's crazy.
How is that possible?
So that is when Python 2 is going to be end of life.
So this is an interesting article because I know a lot of organizations are thinking about their status with Python 2 and Python 3, whether it's worth upgrading things, are they behind, and looking to other leading organizations on how they're doing their migration.
So this is kind of a walkthrough of where is Mozilla?
Where are they going?
What's their assessment here?
And the idea was, first of all, do they actually need to migrate off of Python 2?
Technically, no.
You can still download 2.7.
You can still run it.
But here's the things we're concerned about at Mozilla.
Python 2 will no longer receive security fixes.
That could be a problem.
More scary, I guess, is all the exciting growth of all the other packages they depend upon may no longer support Python 2.
And so they will be stuck on old versions of all the other libraries that are great.
Right?
So in a sense, like, the libraries they can use will be calcified, not just the runtime.
It also means delaying more code they got to migrate and probably writing new code that is not as easily migrated.
And it also has an opportunity cost that they can't use the cool features like async and wait and f strings and all those good things.
So probably they should migrate to Python 3 is what they decided.
And their first step was to set up some linters.
They said one of the linters makes sure that Python code at least can be imported into Python 3 without failing.
Like, that's a pretty low bar.
Can I say import this and run that statement under Python 3?
Yes or no.
Right?
But it's like that's the first step, you know.
And then the other linter they set up was to make sure that all the Python 2 files had the dunder future import statements.
So things like print statements and whatnot were working out.
All right?
So you write the right print statements at least.
And then we've talked a lot about pip enf, poetry, managing dependencies, all that kind of stuff.
So there's an interesting conversation there about their evaluation of pip enf and poetry and whether or not that made sense for them.
And pip enf and poetry are pretty good for, like, I would like to create a project and here are some dependencies I want to install.
You know, pip enf, install, whatever, right?
Request or something like that.
But it turns out the way Mozilla works with one huge mega repository, like monolith repository, those tools don't really work for that.
And so they actually created this thing called Jetty, which is based on poetry.
That is more appropriate for those types of, like, systems and dependencies and stuff.
So it's a pretty interesting look into some simple steps that Mozilla is taking to move to Python 3.
Yeah.
Jetty seems interesting.
Yeah.
Take a project based on another project that removes features.
These features.
What did you do?
Well, I removed these three features.
So now we won't use them.
Yeah.
The idea of some of the stuff about the way poetry worked, just it assumed that the top level of the project is kind of all of it.
And at Mozilla, that's, like, all of their code in entirety.
And they want to work in, like, sub bits or something to that effect is what I got out of it.
All right.
Well, that's cool.
Yeah.
I like it.
Yeah.
So if you're thinking of moving your organization to Python 3, which should be anybody who is not already on Python 3, I would say, or that's your role or something like that, check out this article.
I think it's got some good tips.
One question for you, Michael.
Wouldn't the second best time to plant the tree be 19 years ago?
Yeah, but it makes explaining the thing a long – it takes, like, 21 statements instead of two.
Okay.
All right.
So that's our main topic.
So, Brian, you got anything extra you just want to throw out there real quick?
Yeah.
The beta 3 for Python 3.8 is out.
And the core Python team is encouraging everybody, especially people that maintain third-party package at third-party Python projects, to heavily test 3.8 because it can be fixed now.
But if you wait until 3.8 is actually out, it's harder to fix.
So please test.
It seems like we're getting a little bit closer to Python 4.
Is that in a future?
It's such an interesting idea.
2.7 and 3.8.
Well, I asked – speaking of Lucas Lang, I asked him about it back at PyCon when I did an interview with him and Anthony Shaw around the features of Python 3.8.
And I think, you know, there's hesitation to have a double-digit second number there, like 3.11 or something like this.
But there's also so much fatigue of this Python 2 to 3 conversation that I'm not sure that we're going to be going to 4 anytime soon.
On that note, though, I think it might be interesting to have a 4.0 be a non-event, to have it just be another version.
Yeah.
That would be nice, wouldn't it?
Especially since everyone's getting used to the conversion.
So you might as well just throw it in and have another one there.
We've been converting for like 10 years.
Let's just keep going.
All right.
So I've got a quick one I want to throw out there.
PipX.
I love PipX.
It lets you install things that are Python but are meant to be little utilities that you just run on your terminal.
Install and manage those separately, kind of like Homebrew, but for Python stuff.
It now has shell completions, which is pretty cool.
So you can install those really easy.
You can say pipX space you tab and it'll show you all the things that you can send to PipX that starts with you for like upgrade, upgrade all, things like that.
Not a huge thing, but I'm a big fan of PipX.
So it's a little bit better still.
That's good.
Yeah.
Kelly, how about you?
So you got to put a plug in for our podcast at teachingpython.sm.
Sean, Tiber, and I, we started this podcast because if you haven't heard, I'm a new coder.
I can't say I'm a newbie anymore.
I guess I've been around for a year now trying to learn how to code and Sean's a new teacher.
And we started this podcast and it's just about the frustration of working with a coder who's becoming a teacher and a teacher who's trying to become a coder.
And it's just about our pitfalls and what we've learned.
And it's been a great push for me learning Python.
So for all those people that listen to you guys, Michael and Brian, I think it's a good in-between.
We go home and after we listen to you, we start Googling, what is he talking about?
It's great.
Yeah, that's a great podcast.
I'm happy you all are doing it.
I think you're doing good work there.
I recommend the podcast to anybody that has to teach anybody anything Python related.
Not just teachers or paid instructors.
If you're acting as a mentor within your organization, I think that you get a lot out of this podcast also.
Absolutely.
We really want to hit everyone in the college, even colleagues who want to learn Python.
And just about good teaching, whether it isn't Python, you know, it's not Python, God forbid.
It's something else.
It's just that idea of all the other skills that come along with being a coder.
Yeah, it's a good podcast.
People should definitely check it out, especially like Brian said, if you're in that role somehow.
All right.
Time for a joke, huh?
This is visual.
So I'm going to set the stage, but you two, you have to click that link to open that and see the image here.
Okay.
Then I'm going to describe it, describe it to folks.
We'll see if we can do a visual joke on the air.
So here's the idea.
In Python, you just had this phrase, something to the effect of, like, we're all consenting adults.
We don't need to be overly protective or overly structured in how we put our data together.
Like, we can just say, you know, this part of our data is meant to be internal and leave it alone.
And so there's conventions, but not really enforcement in the language to make that happen.
So, like, if I had a module and something was like an internal implementation, I might have underscore value instead of value.
Underscore method for a private method.
But, of course, you could still get to it, right?
Yeah.
So the joke is, this is a little cartoon, and the cartoon is a door and a welcome mat.
It has a key.
Like, sometimes you have a key under the doormat, but the key is half sticking out.
Kelly, what does it say?
A little annotation there?
It says Python private method.
There you go.
It's, you know, you're not supposed to pick it up, but it's right there.
So anyway, you know, we'll put the link in the show notes.
Y'all can click it, check it out.
But it's pretty funny.
That comes to us both from RealPython and Nick's spirit.
So thanks, guys, for sending that over.
All right.
Well, that's it for the show.
Brian, great to chat with you as always.
Kelly, thanks for being here.
It's great to talk to you and get your perspective on all this stuff.
Thank you for having me.
It's always fun talking to you guys and listening to you guys.
Yeah, you bet.
See you all later.
Thank you 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.
And get the full show notes at Pythonbytes.fm.
If you have a news item you want featured, just visit Pythonbytes.fm and send it our way.
We're always on the lookout for sharing something cool.
On behalf of myself and Brian Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.