Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 104, recorded November 15th, 2018.
I'm Michael Kennedy.
And I'm Brian Okken.
Hey, Brian. How you doing?
I am great.
Yeah, it's a wonderful day, isn't it?
Yeah, it is.
And I'm doing one of my favorite things, talking to you on a podcast.
Yeah, same here. You're all about podcasting today.
It's like you just block the whole calendar day.
It's just all podcasting all day.
Yeah, yeah.
Right on.
Well, I'm sure your other episodes on Test Code will come out good as well.
But before we get to our episode, let's just say thanks to DigitalOcean.
They support the podcast massively, and we're very thankful for that.
Check them out at pythonbytes.fm/DigitalOcean.
Get $100 credit for free for new users to use towards your virtual machines and whatnot.
Tell you more about that later.
Brian, I would normally ask you what your first assignment is or make some not very great transition into it
about coyotes or something.
But we're not going to go down the coyote route.
Yeah, we have some exciting news.
Yeah, we do.
So there's two things I would like to tell you about the podcast.
One is new and awesome, and one has just been around, but we haven't really bothered to talk
about it, and I don't know why.
So let's talk about it real quick.
First of all, we talk about six items and maybe a few extras more or less each week, right, Brian?
Yeah.
Our episodes are 25 minutes.
Wouldn't it be nice if you were interested in, say, the third thing to be able to just click on the third thing
and hear just that if you wanted to jump back as a refresher or whatever?
Yeah, like you said, if you heard it before and you're like, what did they say about Wiley?
And you could go back and listen to that.
Exactly.
And we do have transcripts.
We've always had transcripts, and that's great.
But now the podcast MP3 comes with chapters in each episode.
So if I open up, say, Overcast on my iPhone, and I flip over, I think I flipped to the right two times
or something funky like that, I see every topic that we cover now, and you can click on any of them.
It tells you how much time we spend on each one.
You can click on it.
You can get a little independent progress bar.
It's beautiful.
Yeah, it's nice.
It also works in Apple Podcasts.
You've got to swipe up.
And all the other podcast players, I don't know, but they support the most of them.
Which one do you listen with, Brian?
What do I listen to?
Overcast.
Pocket Cast for a while.
Yeah, Overcast.
I like Overcast.
It's not perfect, but it's better than the others, in my opinion, at least for iOS.
Yeah, I like a lot of the features of it.
I do, too.
So chapters.
Chapters are awesome, and they are now in there.
And also, if you go to the episode page, I've updated the website for roughly the same capability.
So there's a little play icon next to each chapter or each thing that we talk about.
And this only works for episode 103 and forward.
This doesn't work going way back in the past.
But everything going forward, assuming we keep this up,
is a lot of work to do the chapters and figure out the times and put in all the pieces.
But hopefully people like it.
And, you know, as long as we're doing it, I'll put it on the website.
And you can click there as well.
And one of the things I like about the website is if, like, I'm looking at a, you know, in the future, I'm looking back at an old episode.
Yeah, I can listen to it without downloading the whole thing onto my iPhone or something.
Yeah, and I think people also don't understand how much we use our own site as reference.
Yeah.
Like, did we talk about it?
All right, throw it in the search engine.
No, it's not there.
So we probably didn't talk about it.
Let me look at this other thing.
Yeah, like, it's good for us.
And other people can use it too, right?
Yeah, I mean, we have over 100 episodes, six topics.
We've covered over 600 things.
So, yeah, it's hard to keep track.
Sometimes multiple.
Yeah, there's a ton of stuff in there.
And it's good to go back and find the links and comments we put.
So chapters, hopefully people enjoy them.
Be sure to take advantage of them in your podcast player, especially for reference.
And the other one is we have friends.
It's great deaf friends, isn't it?
Yes, friends of the show.
We have friends of the show in the sense of people who send us stuff.
And we love that.
We also have the ability to send out notifications for everyone that cares.
So if you visit pythonbytes.fm/friends dash of dash the dash show,
or just pythonbytes.fm and click on it in the banner,
then put in your email address and you'll get notifications.
I'm going to try to start sending out more interesting stuff more frequently.
You can check that out.
But if you're not signed up there, you probably won't get it.
So be sure to do that.
You can even open up, say, Overcast, go to the show notes, click the title,
and even become a friend of the show right from your podcast player.
I think that's probably the most appropriate way to do it.
So are we going to collect all these email addresses and then sell them to some list?
Yeah, I think we're going to be so rich.
We could probably sell them for two cents an email.
No, we're not going to share those, of course.
No, we hate spam.
We won't do that either, of course.
All right.
Now it's time for the Wile E. Coyote.
Yes, the Wile E. Coyote.
And more friends.
Right.
So Anthony Shaw, we've talked about it.
He's been on the show.
He's been on both of our podcasts also.
And he joked recently that he's going to, at PyCon 2019, he might put friend of the show
as his name on his badge.
Nice.
So then one of the things that Ant or friend of the show or Anthony has been working on
is a project called Wile E.
And it is a Python application for tracking, reporting on timing, and complexity of the tests
of your application.
So it's sort of like we have some complexity checks for your application or for your module,
but this is a complexity of your tests.
And it's kind of an interesting project.
But I'm not going to actually talk about the testing part of it.
Why I brought it up is he's done something that I'm not going to say he's the first,
because it's possible that somebody else has done.
But it's the first that I've heard of.
Somebody that's done this new pyproject.toml style packaging.
So there's no setup.py.
It is pip installable.
And there's a lot of extra goodies that you can do with that.
And he's figured out all of the weird things that you have to figure out to make this all
work.
So he's got like hooked up to read the docs.
So the read the docs is generated.
It's a restructured text-based documentation that gets pushed to read the docs.
He's got it working on the talks is set up.
So there's talks configuration in there.
There's a black configuration within the project.
There's all the things you'd expect.
Plus, he's got pre-commit hooks set up.
And this isn't really part of the pyproject part.
But there is a pre-commit hook for an example.
And also, how to use...
If you're writing a tool that you want somebody else to be able to do pre-commit with, there's
an example hook there.
It's kind of a lot of goodies and it's not very much code.
So I like it as an example.
Yeah.
Nice work, Anthony.
That's really cool.
I like the use of PyProject.
Do you know if he's using poetry?
He's using Flit.
Flit.
Okay.
Right.
So Flit is another one of the ones like poetry or pipfemf, but one of the ones that understands
pyproject.toml.
And if you're curious to learn more about pyproject.toml, we talked about it in Python Bytes 100.
And then I also talked about it with Brett Cannon on testing code 52.
Nice.
Yeah.
That's a really good example.
Leave it to Anthony to be on the cutting edge of packaging.
The other thing, it's a small package, but one of the things I like is his contributing
guide includes the code of conduct right in there.
And I think that's, instead of having it as a separate file, I like the idea of having it
in this contributing guide.
Yeah.
I think the contributing guide should just link to Brett Cannon's presentation about open
source expectations.
Yeah.
Anyway, don't be a jerk.
Yeah.
You're giving me a puppy with this PR.
Just understand.
Thank you.
Thank you for the puppy.
I think I will link to that in certain projects.
Because I've got like, you know, like four contributors on my project.
So, wow, it's just exploding.
That's actually pretty good.
I think the step from zero to one is bigger than from like one to 10.
Maybe.
For most projects to get anybody to care, right?
Yeah.
Well, and I'm having trouble getting myself to do more work on it.
Yeah.
That's a different problem.
So, speaking of different problems.
Yes.
So, let's talk about data science for a minute.
The Visual Studio Code folks are building some really interesting tools.
And there's some quite unique things coming from it.
So, you know, I'm a big fan of PyCharm.
But if I'm not using PyCharm, VS Code is the thing that I would pick up and use.
Right?
So, it's like if I have something really small, I'll probably open it up with VS Code.
Like real projects probably stick to PyCharm.
But VS Code is definitely coming along.
I'm sure Brett can't love that.
For real projects.
I know.
I think it's more that PyCharm is more focused on working with lots of files and project stuff.
And it doesn't make a lot of sense, as much sense to just opening up for like one file.
It sort of can, but not as much.
Yeah.
So, VS Code is definitely coming along.
And one of the things it hasn't had a lot of is support for some of the data science tools.
But now, with the latest release, they just announced a really unique way of doing Jupyter Notebook type of support.
Oh, wow.
Right.
So, normally, Jupyter Notebook is like you go and you open up the notebook.
And you've got these cells.
And you type in the cells.
And you run the cells.
And there's like these IPNB files, whatever the extension is.
They're not really Python files.
They're like XML or something weird in there that has like embedded Python that can run.
Right.
So, this leads to all sorts of funky things like profiling it or testing it.
All those can be somewhat challenging.
Right.
Because you've got to get into the notebook and whatnot.
Yeah.
So, VS Code has taken like a pretty unique approach where what they'll do is they will turn their editor into like a notebook-like surface.
But it's actually still a single Python file.
And you just put, what's the syntax?
You put hash percent percent.
And that line defines a cell in the file.
Mm.
And you get separate output from them.
Okay.
You get separate graphs and all sorts of stuff that you would have in like a side window out of the Jupyter Notebooks.
But you have a single Python file that you still treat as a single Python file.
Okay.
Does it generate a notebook file?
I don't know if it generates it.
It will import them.
So, you could tell it to open a proper notebook and it'll convert it to this format that I just described.
Okay.
Neat.
Yeah.
So, if you're doing any sort of thing with notebooks, this is a really nice way to kind of work in a full-on text editor style.
But still get all the benefits or most of the benefits, at least, of Jupyter.
Yeah.
I do like that they're continuing.
I know that there's a lot of work on VS Code making it.
They're trying to make it even better and better all the time.
That's a good thing.
Yeah.
I guess some of the other things to throw out there that I added, now it has better support for virtual environments.
So, you can like create a virtual environment in your project level directory and it'll detect it.
Things like that.
So, there's a few other nice things.
Better completion, whatnot.
But the big deal is really the Jupyter, pseudo-Jupyter support.
Yeah.
Cool.
Yeah.
It's pretty cool.
I don't do that much with Jupyter, but if I did, I would definitely consider this.
I don't know if you would say it's the right way, but it's definitely a good way.
Yeah.
I don't play Doctor on TV, but never mind.
All right.
So, speaking of the right way.
Speaking of the right way.
So, a lot of people have projects they're supporting or thinking about maybe not a lot of people.
There are a lot of open source projects.
One of the things that we've talked about is if you have users, they might get upset if you change things.
And change is inevitable.
Don't fear change.
Send it to me.
But one of the things you've got to think about is your API.
And APIs evolve.
And so, there's an article called API Evolution the Right Way.
And this is written by A. Jesse Giroux Davis.
And he is an excellent writer.
I mean, even if you don't care about this topic, he puts really cool graphics in his articles.
And also, he's just a good writer.
He's a super storyteller.
And this one is, no doubt, part of that.
So, check it out for that alone, right?
Yeah.
And, like, it's, okay, the first line is, imagine you're a creator deity.
I mean, that's just good.
So, he does it in an analogy of, you know, a snake gaining wings and things like that.
But, anyway, he talks about how to go about adding features, removing features, deleting features.
That's something you sometimes have to do.
And he also, and adding and removing, like, you probably wouldn't remove parameters from an API call.
But you might add some.
How to go about doing that.
Changing behavior.
Sometimes things just aren't working the way they should.
And they should work different ways.
And he also gives some examples and some examples of things that, even in the Python standard library, that changed.
Because the way it used to work just was weird.
One of his examples was that you could date times.
So, if you did datetime.time with the parameters 0-0.
So, that's an odd time.
But it does happen.
And it happens if you have it in a loop and are checking to see if the time is not null or something.
But you just said if x or if time.
That'll return true sometimes if it's 0-0.
So, that's converting bools to time or time to bools.
A valid time should return true.
But it used to return false.
And that was in pre, yeah, 3.4 and before.
Oh, my gosh.
It returned false.
And that's just weird.
You know, sometimes there's just behaviors in your code that you didn't intend that you need to change.
And how to go about doing that in a nice way if you've got users in a public API.
So, it's a good article.
Yeah, he's got some good advice for sure.
One of them includes not putting feathers on snakes.
Another one is like evolve cautiously.
You know, avoid bad features if you knew, right?
Minimize features less to maintain.
Keep features narrow.
Mark experimental features as provisional.
Delete gently and stuff like that.
Yeah, provisional features actually are interesting.
But they're still tricky.
Like, for instance, pytest introduced an experiment on how to deal with fixtures at one point.
And they're still, I guess, just recently deprecated them.
Or they've been deprecated for a while.
But it took a while to, it's hard to remove stuff because people might be using it.
Yeah, yeah, definitely.
Even if you say provisional, someone's going to be like, wait, why did that leave?
I needed that.
Yeah.
It was a test.
I don't know.
Maybe separate branches.
Maybe.
I don't know.
It's hard to know what to do to really push that out and let people test it, but then actually take it away.
Yeah.
That's a tough one.
Thanks for that advice.
Yeah, yeah.
Jesse, that's a great article.
I really love it.
The way all the pictures and the storytelling.
And he's a great writer.
Nicely done.
Now, before we get back on one of our kicks, because it has returned.
So I want to tell you all about DigitalOcean.
So DigitalOcean, super big supporter of the show.
They're sponsoring every episode for the second half of this year.
So thank you to them for that.
And we've talked about you're not Netflix.
You're not LinkedIn.
You're not Facebook.
I just interviewed some guy from, a guy Colton from Adobe, talking about managing the security of 40,000 servers for some of their back-end stuff and how they do that.
Some people have those problems.
Yeah.
And the systems that manage that get pretty complicated.
But most people don't have that problem, and they shouldn't have to deal with systems that are way complicated to handle that kind of stuff, right?
Most people want to spin up a server, have a database server, maybe a firewall, a static IP.
And if that's the kind of thing you want, you can do quick, easy, affordable, reliable.
Go check out DigitalOcean.
So we use them.
WeWork, Docker, GitLab, Slack, all those folks use them.
And it's way, way cheaper, way, way simpler.
You can get started right away.
So check them out at pythonbytes.fm/DigitalOcean.
Get $100 to play around and get started.
And definitely recommend them working out well for us.
Probably will for you as well.
Yeah.
Thanks.
Yep.
Thanks, DigitalOcean.
Now, I'm trying to remember.
Have we spoken about GUIs?
I don't think we have.
No, let's talk.
We should totally do that.
Let's talk about them.
So actually, this is the thing.
This is a, we talk about GUIs so much, this item is back on Python Bytes.
Like it is previously on episode 90, we spoke about this thing called PySimpleGUI.
And PySimpleGUI, GUI is, I would put it in the category of this other thing called GUI, G-O-O-E-Y, which is, these are like really simple ways to build kind of standard, not overly customized UIs.
I just like quickly want to get like a UI up.
Like I can get some input, show some stuff to the user.
This one is more advanced than GUI, but still it's kind of meant to be, I want to get up something quick and not like massively complicated, right?
Like you wouldn't build like a full on web browser in here, but you might build like a little utility that you all use.
So the idea is you sort of declare the types of controls that go on your layout and then it pops up.
Now, one of my complaints back when we were on this kick in episode 90 was this is based on TK Enter and it looks like it's straight out of 1990, which was amazing because I love history.
But I don't want my modern apps to look that way, right?
And I mean, that's not a...
It's great music, bad user interfaces.
Exactly.
I mean, come on, Black, Pearl Jam, we even have a package named after.
Anyway, so the idea is you can simply create these GUIs, but the drawback was it was built on TK Enter.
Right?
Which you can build nice stuff, but it just looks a little out of place.
I think maybe based on our feedback, certainly on other people's feedback, Mike decided, you know what?
Let's try to create this for Qt because Qt looks modern.
Qt looks nice, right?
Like Qt is definitely a good looking framework.
Like if you build an app in there, you might not know that it's not native.
It's not built with Xcode, right?
And Coco, something like that on Mac.
So he took a shot at it.
And in one week, he fully created a Qt version.
So now you have TK Enter if you want no dependencies, and you have a Qt version if you want it to not look like, you know, Pearl Jam loved it.
It really does look nice.
So I'm excited about this, actually.
Yeah.
The new one is looking quite good.
So it's sort of a declarative little builder.
All you got to do is pip install PySide 2, and it has no dependencies.
It's a single Python file.
It only works on modern Python as well.
But he's sort of inspired by this.
He's also working towards a WX Python and a Kivy.
And if he gets Kivy going, that would be pretty sweet because that would be mobile.
Yeah.
Right.
So, so far, everything has been desktop.
But if he can get Kivy going, Kivy's a mobile Python framework, and that would be pretty killer.
Well, and also, it'd be kind of a cool thing to try to do something.
Like, if you had similar code and ran it, generated all these different versions, and then you can kind of look to see which one you like better.
Yeah, exactly.
And the, I should point out, the API is identical from TKenter and Qt, right?
Yeah.
So you just, you just do a different import statement.
You import the Qt one instead of the standard one.
And as long as you have the dependencies in place, like, the API doesn't change.
So you could, I mean, even do that at runtime.
Like, see if they have Qt installed.
If they don't fall back to TKenter and apologize a little bit.
Sorry.
But if you want this to look better, you got to go run this line.
No, you should go do something like check out the Fman build system, which will let you then take this thing, package it up as a installer for a binary, standalone binary for the various OSs, and then you'll be in business.
And you can make millions.
Millions and millions of cents.
Yes.
Okay.
All right.
So nothing major, but just sort of an update on that one, because I think the featuring, the ability to use Qt here is actually a really, really big deal.
One of the other major things happening right now is a lot of the core development around Python is kind of put on hold because nobody knows who to ask on how something gets approved, who approves it, or anything.
Tell us more about this.
People at the heart of Python are the core developers.
They're trying to figure out all this stuff.
And since Guido has stepped down as official benevolent dictator for life, I'm not sure how that works, but the governance model around Python is changing.
I think it used to be go ask Guido for final word, and that was that.
Yeah.
I think it may have been a little more structured than that.
I'm summarizing.
How do we go forward is a topic.
And Victor Stinner, who is one of the core developers also, I met him last year at PyCon, great guy.
He came up with this summary of there's a whole bunch of competing governance models.
And they are summarized at actually what there's one PEP called PEP 8000 that summarizes all of them.
But they don't it doesn't really compare them.
It's just a quick summary of the different ones.
But there's a they're numbered 10 through 16.
Why is that?
There's zero one, two.
I think there's seven different models.
Of course, Victor has put together a comparison of the different ones and how in different ways.
So, for instance, comparing them, what their hierarchy is like, how many people are involved, what the terminal limits look like, what's the PEP process going to be like and whether they include code of conduct and stuff.
And my guess is none of these are going to win just wholeheartedly.
There's probably going to be pieces of the different PEPs that get combined into whatever we end up with.
But if you're curious about what the core developers are up to for your future, you can look at some of this stuff.
Yeah, this is really interesting.
And it's a bit of a catch 22, right?
Like, who even decides on the governance model?
Well, right.
Because Guido explicitly said when he stepped back to just standard core developer was, and I'm not going to decide for you.
You all have to decide for yourselves.
I guess maybe vote by a core developer team.
I don't know.
Yeah.
So, there's only seven.
So, like, for instance, the first one is we just pick another leader.
So, it's something kind of like we have now, but it's a different person, a technical leader governance model.
There's one that's led by a trio.
So, kind of like that, kind of like Guido, but three other people kind of share that.
You know, when we talked to Brett Cannon and Carol Willing back on, what was that episode?
Around 90-ish.
I'm not sure.
Do you remember?
Wasn't it 100?
No, that was a different one.
Oh, okay.
We did a special dedicated one on this whole topic.
I just don't remember exactly what the number was.
The number was.
But anyway, I thought it was really interesting that I thought, of course, there's going to have to be an odd number of leaders because you're going to need a tiebreaker, right?
Yeah.
And Brett pointed out that some people are saying, you know, actually, it may be better to have an even number.
So, ties mean do nothing.
And you have to have a majority, like a clear majority to make any changes, which actually, I think, so maybe, like, led by four or six or something like that actually is an interesting option.
Yeah.
But I think it's kind of cool that this is all happening in the open and people can comment on the different proposals and they can also comment on this summary.
Yeah.
They definitely can, right, at the bottom of the show page.
Yeah.
Nice.
All right.
Well, thanks for featuring that.
It's going to be interesting.
And I would guess we hear by the time PyCon happens what the decision is.
I doubt they can go that long, more than, you know, close to a year without having any form of leading person or group.
One of the options that's not on the table is we can just say we're done and not develop Python anymore.
No, that's not an option.
We can't do that.
Right.
It's just doing too well.
But, you know, I guess it's always an implicit option if we could just stop.
All right.
So the last one that I want to cover, the last main topic, is this thing called Shiboken.
Because it comes from GUIs and I'm back on my GUI kick.
No, that's sort of true, but that's not why I care about it.
So Shiboken is this subsystem that the Qt folks made to create the Qt for Python, which is basically they go to the Qt libraries, which are all C++ header files,
and they want to make Python versions of that without maintaining a separate library that is, you know, here's the Qt one, here's the Python one, they'll get out of sync and whatnot.
So they created this thing called Shiboken, and the idea is you can run Shiboken against arbitrary C, C++ code,
and it will output Python libraries that interact with that at a C level.
That's cool.
Right.
So if you have any C code you want to interact with, you can just run this against it.
And it has like a type system, which is an XML file type of thing that you can customize.
So if you see, you know, this thing star in C, well, what that means is actually this type in Python.
Right.
So you can manage that a little bit.
Right.
Like standard string is actually, you know, str in Python, and you could tell it to do those mappings.
But then you point it at these libraries, and it can, you know, extract them, you can hide functions or add functions, all sorts of stuff.
So it's pretty cool.
That is great.
Automating the boring stuff.
Exactly.
Definitely automating the boring stuff.
So these folks are creating and maintaining it to build PySide 2, basically, at least the wrapper part of PySide 2.
But you can use it for whatever you want if you have C code.
It has nothing to do with GUIs or Qt or anything like that.
And there's two interesting blog posts.
One is Qt for Python under the hood, which I'll link to.
And that one basically shows you how this fits into their overall build system, which has Clang and C++ and CPython and all sorts of stuff.
And then one that's sort of a tutorial called Write Your Own Python Bindings.
And that one takes you through the process of more or less what I'm describing here.
It creates some non-trivial C++ classes with public, private members using the standard library and things like that.
And then it creates a Python wrapper and then uses it.
It's pretty cool.
Yeah.
That is neat.
Any idea where the name came from?
No.
No idea at all.
There's probably a really great story where the name came from.
Yeah.
But I don't know where it came from.
So this is one of the options if you want to do C++ stuff.
But there's others as well, right?
So you could use CFFI.
This is sort of a more modern way to explicitly write these mappings.
And Dan Bader over on dbader.org actually has a good write-up on that.
So I'll link to that.
Or you could use Cython, which actually is a really cool way to just directly import and start using C libraries.
Just basically you define the function shape and then you import the header.
You say, this function comes from this header file.
Let's roll with that.
And then you just start using it in Python.
Of course, you've got to compile your Cython code with Cython.
But it's pretty nice.
And so there's a good example of doing that from scratch as well.
So Shabokan, these other two, they're all quite interesting.
I'll link to them all.
Nice.
Yeah.
Well, that's it for our official items, right?
You got anything else you want to share?
I don't.
Do you?
I actually have a whole bunch of stuff that I'm very excited about, but it's very short.
So let me just tell you.
First of all, I bought my PyCon ticket.
Woo!
I still need to do that.
Yeah.
It's exciting.
The big news is that the PyCon tickets went on sale just like three or four days ago.
So I don't know if it sold out last year or not, but you don't want to be looking, you
know, standing outside there by the Great Lakes in Cleveland, looking at the windows with all
the people enjoying themselves and not being able to go in, get your PyCon ticket as soon
as you can, because it's going to be fun.
It's always fun.
I'm looking forward to being there with you, Brian.
Yeah.
It's going to be awesome.
And if you would like a closer, smaller, but still fun version, closer by definition
to Brian and me, PyCascades tickets also went on sale just a couple of days ago.
And this is the much smaller, like 200 person conference in Seattle.
And this one will definitely sell out because it's so small.
Yeah.
I think they received over 200 talk submissions and they can only have 200 people.
So I'm pretty sure it's going to sell out.
Yeah.
So look into that.
That one's cheaper, smaller.
And if you're in the Northwest, closer, but maybe that doesn't describe.
Many of the listeners, but yeah, it does for us.
So I'm going to be going this year, but it's the first time I didn't go last year.
So I'm excited to check it out.
Yeah, I'm excited.
This will be my second year.
I'm also going and it's going to be great.
Okay.
So those are the conference stories.
Those are the two big conferences.
You know, definitely the PyCon one is a big deal.
The other one is, have I talked about GUIs?
No.
So the other one is a book that caught my attention.
Like there's tons of Python books and, you know, sometimes they're interesting sounding, but
this one really seemed to have a unique, like really to draw the reader in.
It was really a cool angle on it.
It's called Mission Python Code a Space Adventure Game.
So basically it sets up the story of this universe that you have to save and it takes you using
PyGame and PyGame Zero and all sorts of stuff to create games with sounds and graphics and
just walks you through building this game.
And I think it looks like a super fun way to get into PyGame.
That's kind of exciting to check this out too.
It looks fun.
Yeah.
I'm like, maybe this needs to be one of my projects.
And then I remind myself, no, you're already too busy.
Please don't do this to yourself.
Yeah.
Like somebody said that we ought to go off and learn data science together.
But yeah, there's a lot going on in both of our lives.
Yeah.
Yeah, for sure.
Much of around Python, but that bucket is getting quite full.
So, but I, this is definitely one of the things that tempted me to like add one more
thing to the bucket.
It looks interesting.
Yeah.
All right.
Brian, thanks for being here and sharing all this with me and everyone else.
Yeah.
Thank you.
You bet.
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.