Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 131, recorded May 15th, 2019. I'm Michael Kennedy.
And I'm Brian Okken.
Hey, Brian, how are you doing?
I am good. How are you?
I still have a little bit of a conference hangover.
Two conferences in a row and then some parties definitely took it out of me. How about you?
Oh, yeah. You went to build afterwards. How was that?
It was good. I did a bunch of podcasting, met some other folks.
I got to see what a different type of conference than Python looked like.
And yeah, it's pretty different.
Okay. So anybody out there from build listening, you can invite me next year. That'd be just fine.
Yeah, absolutely. Absolutely. So yeah, it was fun. It was fun to be there.
And it's but it's good to be back home from all the conferencing.
Yeah, it is. So let's get back into Python.
Let's get into it. So before we do, though, I want to say thank you to DigitalOcean.
Check them out at pythonbytes.fm/DigitalOcean. More about that later.
I feel like we kind of have a little bit of a PEP roundup for this episode, Brian.
We got at least three peps. Yeah, we got at least three peps making an appearance. Maybe four.
Okay, well, the ball is rolling now with the new steering council in place. And they're kicking butt and taking names. And it's great.
So we'll start off with, I just saw this today. Pep 581 is accepted. And that is the GitHub issues for CPython. So CPython has traditionally had its own, I think it was its own custom made defect tracking system or something.
It hasn't switched yet, but it will be switching to GitHub issues. We'll link to the PEP and also it has discussion of pros and cons, but it has been accepted.
But the follow on PEP is 588. And I'll quote Barry Warsaw here. It's the migration will be a large effort with much planning, development and testing. And we welcome volunteers who wish to help make it a reality.
I look forward to your contributions on PEP 588 and the actual work of migrating issues to GitHub. So 588 is, okay, now that we've decided to do it, how are we going to do it? How are we going to do the migration?
And once they figure that out, they'll probably need some help to do it.
That's cool. And you know, you spoke to Barry on our episode, our live episode at PyCon, about becoming a core developer and ways you can help.
And here it sounds like another way you can contribute to CPython without actually writing C code potentially.
Yeah, I'm not afraid of C code, but I know, I mean, especially in the Python community, there's some people that aren't involved with C code.
So there's other places, ways to help. And this is one, yeah.
Yeah, it's one thing to write C code. It's another to write on the core of CPython itself, right? I mean, that's like, it's a super highly polished piece of software and any change you make has like massive ramifications.
So, right, I can see how it depends on it. No pressure.
You're going to take down the Instagram influencers if you mess this up. So don't.
Yeah.
Maybe some science and other important things as well. I think this is good. You know, Brett Cannon was key in getting,
CPython, the source code over to GitHub originally. And I feel like this is well overdue, right? Like, having the issues there means you can reference them in check-ins. It means that you get that integration for pull requests and all sorts of stuff. It just makes a lot of sense to do this.
Yeah. And I have no idea what the migration path looks like.
Yeah, I was wondering, like, are they going to copy every single issue across? Or is it this a chance to kind of like clean house?
I go, well, if this bug comes back, it's important enough to worry about. If it doesn't, maybe it's not.
I've been on projects like that, that we've gone to a different bug tracking system where we just said, well, we'll just leave the other one around. And if anybody really cares about moving them over, we will. But sometimes cleaning up is a good thing.
Yeah, I totally agree. So how about cleaning up some code?
Yes, let's clean up code.
So I'm a big fan of design patterns in general, the solid principles, all these things. I really enjoy, like, thinking about how that influences code.
And one of the things that makes me crazy when I read code is, like, ultra-nested, indented, conditional stuff.
And when I see it, I feel like people write code like that because they don't believe there's another way.
It's just like, well, this code is complicated, so it's, like, indented, you know, 16 spaces or whatever it happens to be indented as, right?
Like, it doesn't have to be this way most of the time.
So I just wanted to, like, call out a super easy-to-implement design pattern called guard clauses or guarding clauses.
Okay.
Okay, so this is, if you have, like, nested stuff.
I have two little examples, like a bad one and a good one here in our show notes, and people can check that out.
And it's, like, a little checkout for a user.
So a user, they've got a shopping cart.
They've got some items in there.
Some of them are available.
Some of them aren't.
Some of them are selected to be express-shipped.
Some of them are not and things like that.
And so it's got, like, if user is not none, go through their carts.
If the item is available, add it.
In addition to that, if the item is selected to be express-shipped, add it.
And that's, like, just, what is that, a 30 degrees down, 45 degrees down line of code, right?
It's not vertical.
It's, like, you know, at an angle, probably 45, right?
Yeah.
And every one of these is asserting a positive thing.
The thing I want, if the user is good, I want to go through them.
If the thing is available, I want to do this, right?
And so on and so on.
Guarding clauses basically check for the negative and bail out as soon as possible.
So you could rewrite that and go, if the user is none, return empty stuff for their stuff.
If it's not available, just skip through the loop with a continue and so on.
And it's much simpler.
And it's not just about visual code.
It's not just, like, easier to read, but it's easier to reason about.
Like, if you get into one of these super nested conditional structures, then it's really hard
to think about, like, okay, I want this case and that case.
Like, where does that go?
Do I need another branch in this if?
And so on.
I feel like it's much easier to maintain and add to with these guarding clauses.
And in the example you're showing, and we're going to have in the show notes, the better
one actually ends up being more lines of code.
However, you're visually going to skip over the top part because you're like, oh, I'm just
making sure that things are the right.
And then in the middle, I've got highlighted just, like, three lines of code where the actual
work is.
And highlighting where the real work is instead of dispersing the real work across lots of if
clauses.
I think that's a great idea.
Yeah, thanks.
I super love it.
I'm linking to Martin Fowler's original little article on it, which is like C or JavaScript
or something.
But it's, you know, it's if statements.
It's basically the same idea.
As well as to one on, from a Go, a Medium article about line of sight programming, talking
about, like, you can just, you know, see right down the line.
Anyway, it's all pretty cool.
I definitely, definitely think how those can be used.
I find it to make it a lot nicer, a lot easier to maintain this code.
It'll also reduce the cyclomatic complexity of your code.
Yes.
Yes, it will.
And that also probably, you know, that's cool because it'll make Anthony Shaw happy in his
Wiley.
But it also means, like, it's less cognitive overhead to maintain, right?
You can say, okay, I cleared out the stuff that's not good.
Now we're in the good spot.
It's not indented.
It's not a lot going on.
You're right.
It's so simple that I don't, you know, if you're not using it, just check it out.
It's great.
Good reminder.
Speaking of if you're not using it.
Yeah.
So the, so Python 3 is a thing.
We've talked about it a few times in the past.
There's probably a lot more people.
Well, I don't know.
There's probably more people, some people now still converting to Python 3 or starting to
get used to it.
The easy hurdles are just to start not using the stuff you can't anymore and some of the
string changes and whatever.
But here's an article we ran across called Things You're Probably Not Using in Python 3,
but Should.
So there's a lot of new items in Python 3, but this article goes through a handful.
So there's some obvious, I think obvious, of course, items like fstrings, pathlib, and maybe
data classes.
I'm using them a lot, but, you know, maybe.
fstrings and pathlib, definitely everybody should be using those.
Those are awesome.
I'm warming to type hinting a little bit more.
I think it's feeling more natural.
You know, I'm not really a zealot about it.
But when I start trying to see myself start typing a comment to say what kind of stuff should
go into a function or what should be in a variable, I'm like, oh, I could just put a type hint
on there.
Exactly.
Yeah.
Exactly.
Yeah.
Comments are deodorant, right?
They go on to bad code to make it smell better.
But maybe you should just make it better by putting some type hint.
Maybe type hint.
Yeah.
So especially when it's, I'm only intending it for like the reader.
I'm not using some testing tools around that.
But there's some stuff that I knew about that I just kind of forgot.
So I'm glad that I'm going to list three that he listed.
Enumerations with the new enum package and enum and auto methods and classes.
Yeah.
I love enums.
They're really great.
I don't use them enough, but yeah, they're super enough.
I want to use them a little bit more after this reminder.
Also, LRU cache is built in.
It's a decorator in func tools that you can use really easy memoization.
So if anybody's not familiar with LRU cache or memoization, the gist of it is, is you just
throw this decorator on a function.
If it's really functional programming type stuff where you pass in some value and you get at
and that has no behavioral side effects and it just returns some other, some value that's
a one-to-one correlation between input and output.
And it's called a lot.
You can use memoization with LRU cache to speed it up and it just remembers the old stuff.
Yeah.
It just says like, if I see this argument come in, say you have a number in your example,
like if the number 72 comes in and the answer was 7,000, the next time it's called, it just
goes, that argument's 72.
We know it's not changed.
The answer is going to be 7,000.
Anytime you have a function that basically is deterministic, you give it the same input,
it gives you the same output.
This is a super good option.
Yeah.
Especially if it's something that's like time consuming, it has to do some data crunching
or something.
Yep.
The last one I'm going to highlight that I totally forgot about is extended iterable unpacking.
And this one you kind of have to see to get it, but basically you can, when you like, for
instance, if you're unpacking a list with a three element list, you can assign it to three
variables.
We know that.
But if you have more than three, you can put a star on one of those things and it'll catch
all of the rest.
And that's cool.
There's lots of places that I could use that that I forgot about.
You know, you can even do the star in the middle, right?
You've got like head, star, body, and tail for five things.
And the body is three things.
Pretty awesome.
Yeah.
When I look at this and I think about it, you know, obviously there's a lot of people
moving to modern Python and using it in their code, right?
But just like you could come from C and write non-Pythonic Python, you could move to Python
3 and write non-Python 3-ic?
I don't know.
Like you could write code that's not idiomatic to Python 3, right?
You still do everything in the Python 2 style, not taking advantage of any of these things,
right?
Like f-strings, pathlibs, type hinting, async and await, you know, like you said, enums.
You could like do none of that and still be quote using Python 3.
So I think it's cool.
A cool reminder and example of things you could do to be more idiomatically Python 3.
Yeah.
Actually, when I was thinking about that, the author of this even says some of his old articles
are written essentially for Python 2.
And I think that's a great place for people if they're new to, they want to start doing
technical blogging and they don't really have some ideas on what to do.
You could go look at some common and popular articles that are written in Python 2 style and
kind of make them your own and do a similar article.
Don't copy it, but do a similar article with Python 3 syntax and you'll probably get some
hits.
Yeah, for sure.
Or even if you really love that resource you're reading, you could send them a note like,
hey, I'd love to upgrade these three articles to Python 3.
Could I help you?
Oh, yeah.
That would be much nicer.
Do that.
Yeah.
Well, they both have their own merits, right?
Yeah.
Speaking of merits, let me tell you about DigitalOcean.
DigitalOcean is powering all of our things, which is awesome.
And we talked about GitHub at the beginning.
One of the big things GitHub is doing is GitHub Actions.
So kind of automated workflow for things that happen, you know, check-ins and other stuff
on GitHub.
And DigitalOcean has a GitHub Actions for DigitalOcean that you can install and plug in there.
So you can take your workflow that's happening on GitHub and automatically use that to do
things like create a new virtual machine or push a new version to a Kubernetes, managed
Kubernetes cluster based on a push or something like that, right?
Or maybe snapshot it when an issue is filed.
Who knows?
But all sorts of cool stuff you can do with GitHub Actions and DigitalOcean mixed together
with that.
So check that out at pythonbytes.fm/DigitalOcean.
Get $100 free credit for new users.
Definitely can recommend them.
They're doing good stuff.
So how about some fun, Brian?
Yeah, we got a couple of fun ones.
Yeah, yeah.
Let's play a few games here.
It's awesome that these came up just right by each other.
So I want to talk about this thing called the Python Arcade Library, which is at arcade.academy,
which I didn't even know .academy was a top-level domain.
But apparently, apparently it is.
That's pretty awesome.
So this is a library for easily building 2D games in Python that run at like 60 frames
a second on OpenGL.
Oh, neat.
That's pretty cool, right?
So it's really about like this is by a guy.
I believe his name is Paul.
Paul, hopefully I'm getting that right.
He built this to help teach.
He teaches at a college.
And it helps teach his students a more visual way to learn programming.
So it's not to teach game development.
It's to teach programming.
But because it's got a visual aspect and not just like a terminal version, you can see what
you're creating more easily and see it working.
So that's pretty cool.
You can create like Minesweeper games, Hangman games, and in particular, platformer games,
right?
So if you wanted to recreate Lemmings or he wanted to do like Joust or whatever, like you
could totally use this for that.
Ooh, neat.
Yeah, and you can check out the sample games made with that.
So there's like a tower defense game.
I'm a sucker for tower defense.
There's like a little Angry Bird thing made.
There's all sorts of fun stuff.
There's tons of examples here.
I think mostly because these are students who are taking the class but then submitting their
projects.
Oh, that's a great idea.
Yeah, nice, right?
Yeah.
Yeah, and I like these 2D games.
I do too.
Yeah, and it also includes things like physics, which is nice because it's one thing to get
the graphics on the screen.
But hit detection, physics, sound, all these other things are super hard.
And I believe sound is still like a little bit of an iffy feature here.
I hear that that's tough in Python.
So maybe that's like a cool C extension somebody should write.
I don't know.
But anyway, it's all based on OpenGL.
And it looks pretty cool.
So definitely want to recommend that people check that out.
Yeah.
And you guys, similar one.
How about that?
Yeah.
So I wanted to highlight an article called Teaching a Kid to Code with Pygame Zero, written by Matt
Lehman.
So this is just this guy with his kids.
He likes to play video games with his kid.
And I thought, you know, I should try to teach him how to code.
And they tried, his son did like a version of Scratch.
But the worry is that Scratch is really far removed from actual coding.
And the skills you build might not be transferable really easily.
So I went ahead and decided to try Pygame Zero using the Mew editor.
And I guess Pygame Zero is already pre-installed in Mew, as is a Python interpreter.
I didn't know that.
That's cool.
Yeah, that's great.
And so a quote from somewhere.
Pygame Zero is intended for use in education so that teachers can teach basic programming
without needing to explain the Pygame API or write an event loop.
He worked with his son and they came up with a 29 line of code, including blank spaces.
Little game.
Doesn't really do much.
But it teaches a lot.
So he said that his son learned about naming things and variables and mutability.
Fiddling with constants to see how those will affect the screen size and stuff like that.
Writing functions that have side effects and interacting with mouse events.
So he learned quite a bit with just this little bit of code.
And it's actually Python.
So that's kind of neat.
And then one of the things I really like, because I do want to start, I haven't worked with my kids with coding yet,
but the article also includes some tips on how to behave as the adult when you're working with kids with coding.
This is good.
Yeah, it's truly tricky to set up the right balance of it's interesting, but like quickly becomes too hard or it's easy enough to get kids started.
But it's, you know, they have expectations of something they can do with their iPhone as a game.
And what you build does not necessarily match, right?
Yeah, and I'm, I like the tips at the end because I'm one of those kind of people that would just say,
okay, you just sit on the side and I'll do it and you watch.
It's not really teaching.
Yeah, true, true, true.
It's cool though.
I think these are both really fun options for teaching kids programming and building a little game.
Because, you know, not everybody cares about building games, but a lot of people who do,
like a lot of people's introduction to programming was they wanted to build a game.
Programming was just what was required to make that happen, right?
And you can go do something else like a useful utility that somebody might need.
But I mean, how many like six-year-olds really need a useful utility written in Python?
Yeah, true, true, true.
Anyway.
Cool.
While we're talking about games, like if kids are not quite ready for a game,
but they're ready to do adventurous stuff, I guess, I want to throw a shout out to CodeCombat.com.
That's a super cool place.
It has a free version where you basically go into these dungeons and you solve the dungeon by writing Python programs.
Oh, neat.
And the editor has like autocomplete like nobody's business.
It's super, super nice.
So you have to like have your hero move around.
You say like hero.attack and select like an enemy.
You type the letter A, it'll autocomplete hero.attack.
I mean, it's like really, really beginner friendly.
So definitely, you know, that's maybe a first step.
And then like one of these two that we just spoke about would be really good as well.
Oh, I'll try that.
Yeah, I was doing that one with my daughter and she was super into it.
She got like 50 levels in or something.
50 little dungeons.
Cool.
So, all right.
So last one, let's round it up with something a little more serious.
So, we talked before about whether or not the GIL will become obsolete with the introduction of PEP 554.
And this was on episode 128, which is cool.
So, Anthony Shaw wrote a cool article called Has the Python Gil been Slain?
That really digs deeply into that idea that we were touching on back then.
So, the answer is kind of, maybe.
I don't know.
Probably.
But for a limited case.
So, we've got a multi-threading in Python, which is pretty easy, but it's not actually concurrent because of the GIL.
We have multi-processing, which is harder to exchange data and stuff.
It carries a lot of overhead, but does escape the GIL because it's all these separate processes.
Right?
So, PEP 554 introduces this idea of sub-interpreters.
Remember that from back then, right?
Yeah.
And we speculated that maybe the ability to have multiple sub-interpreters would remove the problem of the GIL.
Because the GIL is not a process thing.
It's an interpreter thing.
It's a global interpreter lock.
So, if we just take and run our threads on multiple sub-interpreters, there would be no GIL.
Things would go potentially faster at least some of the time, right?
The problem is if you actually try to share data across those sub-interpreters, things get pretty tricky.
So, Anthony's article really digs into that and talks about how you might use shared memory and IPC,
which is also another feature coming to multiprocessing.
But that's also kind of slow and challenging.
So, he highlights another PEP.
So, here's our fourth PEP.
PEP 574, which proposes a new Pickle protocol.
Is that surprising?
Yeah, a little bit.
A little bit.
Because, like people say, don't use Pickle.
It has all these vulnerabilities and versioning issues and whatnot, except for it's a nice binary format.
And if your goal is to just literally exchange data from sub-interpreter to sub-interpreter through shared memory,
well, then, like, that's fine.
That's, like, within the runtime of a process.
It should be okay, right?
You're not going to hack yourself.
And if you do, you deserve it.
Yeah.
So, this is a special protocol version 5 that has support for allowing memory buffers to be handled separately for the rest of the Pickle stream, basically.
So, all these things could be combined together to get us a cool, faster, more concurrent Python.
And he answers the question, when?
When will maybe these things be here?
So, Pickle version 5 and shared memory will probably make it to Python 3.8, which will be October of this year, 2019.
And sub-interpreters may make that, but they might take another version 3.9, which I believe at the time that's going to be 18 months later.
I think we're still on the 18-month release cycle here.
Yeah.
What I really appreciate about this article isn't that there's suddenly stuff that I can use now.
It's that we have been talking about the sub-interpreters, and I haven't really got my head around really how that affects us.
And I think this is a good jump in, a good discussion about it.
So, if you're curious about this, he talks about all the kind of the backstory and kind of where we're going from here.
The where we're going from here, I think, is still kind of up in the air.
I would like to see something more around like a shared memory.
One of the discussions is having shared memory objects that are owned by one sub-interpreter at a time.
So, you could say, well, I'm creating this data to have another interpreter take it over.
Right.
I'm handing it off to you.
You can have it now.
Yeah.
And it would be nice if I didn't have to pickle that.
If I could just, the data I'm creating is just normal data, but it happens to live in an area that I can hand over to a different process or something.
Oh, that's interesting.
Like, basically dereference it in the current garbage collector system and re-reference that information in the other one.
Yeah.
Somehow.
Something like that.
Yeah.
Okay.
Cool.
There's, I'm sure, lots of smart people working on the problem.
But it is neat.
It's neat to see it going forward.
Absolutely.
Plus, there's a really amusing video of a breakdancer where, like, six guys come out.
None of them are doing anything except for one who's spitting on his head.
Yeah.
It's a very, I don't know even how to describe it.
It's a very different interpretation of how the global interpreter lock kills concurrency through breakdancing.
Yeah.
Through breakdancing.
I knew it all along, man.
The rap beat was off.
That's why we can't get this scene to run in parallel.
Yeah.
All right.
Cool.
Well, that's it for our main topics today.
What else you got that you just want to quickly chat about?
A couple things.
PyCon seems like it just got over, but the videos are already all available.
And I've already started watching them, including Ant's Complexity with Wiley Talk.
And the other thing I wanted to bring up is I'm reviewing, I'm not reviewing it, but I bought the new Pragmatic Programmer book, the 20th Anniversary Edition.
They rewrote it.
And I'm reading the testing chapter starting there.
And they bring up pytest.
And they're using pytest and Hypothesis.
And that's pretty cool.
Oh, yeah.
That's super cool.
And Hypothesis.
That's pretty interesting, that one.
Yeah.
All right.
Well, I have a couple quick announcements for you all.
So, first of all, quick and easy one.
I've been creating a bunch of different things lately.
The iOS and Android apps are both out for the Talk Python training stuff.
But I just released new versions that have a couple of cool new features.
So, if you have it installed, make sure you update it.
If you don't have it installed, well, check it out at training.talkpython.fm.
That's cool.
So, Brian, I've joined you in the journey that is writing a book.
Yes.
You're an author now.
Yeah.
Apparently.
Somehow.
I don't feel like I've gotten any official stamp or any letter or a little pamphlet that
makes me officially an author.
But, yeah.
So, we have a book called Effective PyCharm that's out.
And it has a digital version.
It has a print version.
It has sort of bundled stuff with some of the courses.
So, I'll link to that in the show notes.
People can check that out at effectivepicharm.com.
So, that's pretty cool.
And then, also, we just released a new course, 100 Days of Web.
It's pretty neat.
I've started watching it.
I like it.
Yeah.
Thanks.
Thanks for checking it out.
That's awesome.
So, it's kind of intense.
It's like 28 little different web projects.
So, one time you build an API in Flask.
And one time we build, like, logins with Django.
And migrations with SQLAlchemy.
So, all these different things you might want to do all over.
It's kind of like a super sampling of all the web stuff.
So, check that out.
You know, the links in the show notes at Talk Python Training as well.
All right.
Well, that's all I got for now.
Do you got a joke for us?
I don't.
But I wanted to bring up something about your course.
Oh, thank you.
My first concern was that, like, 100 different web projects might seem overwhelming.
But it isn't that.
Like you said, it's 28 projects.
Is that right?
28?
Yeah.
And there's four of them that are super short.
So, it's kind of 24.
Yeah.
You get more into it than just some quick thing that you can do in one day.
I appreciate that pacing.
Yeah.
Thanks a bunch.
Yeah.
We're trying to find a balance there.
Because 100 separate projects, too small.
Yeah.
One huge project.
You don't get enough variety of other things.
So, 24.
That was the slicing we came up with.
All right.
How about this?
So, there's a programmer going to a coffee shop looking to get out of the cube.
All right.
Can't stand being a cube more.
So, I'm going to get out.
And there's a waiter that comes over and says, hey, welcome to the restaurant.
Would you like coffee or tea?
The programmer says, yes.
Yes.
Of course.
Have you done this?
No.
But it sounds like it might be sort of fun.
Yeah.
I mean, I haven't done it with coffee or tea.
But I definitely think that sometimes if somebody gives me an or question, I'll answer with yes.
Yes.
Yeah.
They mean exclusive or, don't they?
Yeah.
Pretty awesome.
All right.
Well.
Thanks a lot.
You bet.
Good to chat with you.
And I'll catch you next time around.
Okay.
Bye.
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.