Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 67, recorded February 28th, 2018.
I'm Michael Kennedy.
And I'm Brian Okken.
And we have a ton of great stuff for you.
As always, it's getting harder and harder to narrow it down to just keep this, like, bite-sized stuff,
because there's so much amazing stuff out there, isn't there, Brian?
Yeah, there is. And we got a lot this week.
Oh, yeah, for sure.
So before we get on to those, I just want to say thanks to DigitalOcean.
They're our sponsor for this week.
It's where our code runs.
So when you download the audio or you go visit the website, you're running a little slice of that ocean.
So check them out at do.co.python.
Now, Brian, I would have a better performing site and be able to run on a much smaller server if I literally had just files.
No logic, no database queries, no database server, just files, right?
Yeah. And you can host it cheaper there sometimes, too, for statics.
Yeah, absolutely.
So you've got a—the first item is something on Pelican, which is one of the more popular static site generators, right?
Right.
So somebody on Twitter actually asked us.
They said they were going to—I forget who it was, but they said, hey, I'm going to build a new blog.
What are the Python options now?
And a few people came back with different static site generators.
And one of the people that I just found this out today is a guy named Peter, and he's—I believe he's a professor at Portland Community College that has a whole series, a blog series, on how to build a blog with Pelican and host it up on—as a GitHub page.
So you don't even have to pay for your hosting.
At, like, the pages.github.io or something like that?
Yeah.
Yeah, nice.
And the focus of his site, it's pythonforundergradengineers.com.
What a mouthful.
But cool focus.
He's not assuming really much of anything ahead of time.
So he even walks through installing Python and making sure people are using Git appropriately and saving their work.
So even though it's a seven-part series, if you know what you're doing, you can probably go through that pretty fast.
I thought it was a nice tutorial on how to get a blog up.
Yeah, that's really cool.
And I love the fact that he takes it all the way to deployment because it's one thing to show you, like, well, here, now you've got a bunch of static files, and good luck with that.
Yeah, like, getting it online is, like, a nice final step for his article there.
One of the other places I know uses Pelican is Fullstack, Matt McKay's site.
Yeah, and he's doing amazing, amazing stuff.
And his site is just so super fast.
He really thinks a whole lot about that.
That's really cool.
There's actually a number of options around this kind of stuff, but Pelican seems to have a lot of mindshare in the Python space, for sure.
Yeah.
Yeah, cool.
So how would you like to get notified in a whole bunch of different ways if something went wrong with your static site, Brian?
I would.
You know, you could use a service like Rollbar or something, but I'm thinking more like, hey, we've processed your order, and now it's put onto a ship, and it's headed your way.
Or the build server has built some version of your app, and the build is ready for deployment.
Or, you know, those kinds of notifications, right?
And there's just this explosion of places where you might want to notify people of these things.
And they all have their own API.
You know, if you're lucky, there's a pip install thing, and you can at least use that.
But, right, sometimes there's not even that.
There's just an API you've got to sign up for.
So I'm thinking things like Slack, email, Gmail, Telegram, Gitter, you name it.
There's a whole bunch of different places where you might want to push notifications that something like this happened, right?
And these grow every day.
Yeah.
So there's this thing called notifiers.
And what notifiers does is it's like this abstraction API front end for all these different other APIs.
So you can work with the notifier API and say, I want to notify the things.
And you can, like, register a Slack provider, register a Gitter provider, a Telegram provider, Gmail provider, and just check those off.
And then use the same API against all of them.
That's actually really cool.
Yeah.
Yeah, it's really cool.
I can imagine, like, an individual, like, a selection on your site for different users.
So some people would rather get a Slack notification.
Some people would rather get a text message.
And some people wanted it in Slack or something.
Yeah.
And so you could just list off all the providers that you support, check them off.
But your code doesn't really change.
It just feeds that on through this notifiers thing.
So, like, you could send a text message because they have integration with Twilio.
And then Twilio would let that push on through and so on.
There's a bunch of stuff.
There's some things that I don't even know what they are, like Pushbullet.
I have no idea what that is.
It's probably cool.
But it's cool that I don't have to learn its API to integrate.
Somebody comes and says, hey, Michael, your site's cool, but could you have Pushbullet integration?
Yeah, sure.
Here's a checkbox.
Yeah, that's actually awesome.
I'm going to have to play with some of that.
Yeah.
I don't really have a great reason to notify people, but I thought it was cool.
One final thought on notifiers was we've talked for quite some time.
We talk less about it these days, I think.
But we've talked about how one of the points of resistance to moving to Python 3 was, well, there's this one or two libraries I really need.
It's only Python 2, and I can't leave it behind.
We're now in a world where unless you move to Python 3, these things are inaccessible to you.
And one of them is notifiers, which is Python 3 only.
Pretty cool.
Yeah.
So it's becoming more and more, actually.
It's sort of reversing that what used to be friction resistance, which is now pushing people.
The gravity is increasing, obviously, which is great.
Yeah.
It's been a long time since I've used a makefile.
And I think it was in C++ when I last really cared about it.
Yeah, actually, so I hadn't really even thought about makefiles too much.
But I got notified today about KidPixo.
He's contributed to us before.
But he notified me today that said that a combination of information from my book on pytest and also a blog post by, I'm going to go with Christoph,
is about using makefiles in Python projects.
And he's got all of his, now all of his testing is driven through makefiles as well, makefiles through pytest.
And so there's, it's actually kind of a neat idea.
This article talks about starting up in a new work group and being surprised by makefiles in Python projects.
Because there's not that much compiling, right?
Yeah.
And it's not for compiling.
It's just there's a lot of extra little utility work that people do.
And makefiles are an easy way to keep them all in one place.
And some of the examples are like cleaning out all of your PYC files.
Or if you normally create packages, you'll have egg directories lying around and clean those out.
Running your linter or, you know, running your test.
And you could have like multiple targets to start different types of testing if you wanted to.
Like, you know, start your smoke test or start with, you know, your full test or something.
Or even up to like deploying your code up onto a server, possibly.
So anyway, thought that was cool.
Yeah, it's quite cool.
And definitely a nice article.
So it's cool to bundle all these actions.
The more you can automate and just bundle up and take that knowledge of managing and working with your project and make it one CLI command or maybe even something less than that.
Something automatic.
It's like, say, a git trigger or something like that.
It's just, it's all good, right?
The article also assumes that you've not really worked with make files before.
So it tells you some of the gotchas.
And one of the ones that bites me all the time is you really do want tabs, not spaces when you're working with make files.
And that's the opposite of how I use Python.
So something to watch out for.
Yeah, definitely opposite.
Interesting.
Okay.
So speaking of things that are good, DigitalOcean, they're pretty good.
They're hosting our code and our apps here.
I just want to repeat something that I talked about last time, which is that they've basically doubled all of the things for the same price, which is a really big deal.
They've been super competitive and really good compared to the other hosting places, small and large, right?
You go up there, 30 seconds, you are able, from the time you decide to click the button until your server is up and running, you can log in.
And that's all great.
But they basically said, everything that you're going to pay for, for five bucks, we're going to double that, right?
Double the RAM, you're going to pay 20 bucks, we'll double the RAM and the CPU.
And there's all sorts of high computational stuff they've added.
So it's really a great place.
And it's gotten a lot better recently with this big upgrade or price deduction and availability of higher ones.
So if you're thinking about checking them out, go up there at do.co slash Python, help support the show.
And also, if you already are a customer, consider upgrading your servers and stuff you have, because you're still paying the $10 price for half the thing.
So if you're willing to take it down for two minutes and upgrade it, you'll get something better for very, very little work.
So check them out.
Definitely good stuff.
Thanks, DigitalOcean, for supporting the show.
So we talked a while ago about Python, CPython in particular, moving to GitHub, right?
Yes.
I can't remember exactly when that was, but it was in 2016.
So it must have been one of our early episodes.
Can you remember when?
We could probably look it up, but I don't remember.
But so what I wanted to feature next was there's this post.
And I don't remember if it was actually just on Reddit or if it's actually, yeah, it's just on Reddit.
It's literally a picture on Reddit.
But the conversation is interesting and the picture is interesting.
And the title is The Result of Moving Python to GitHub.
And so they put this graph up there, which the graph is not super well labeled.
So it's kind of hard to tell, but it looks like there's a lot more activity since Python moved to GitHub from Mercurial, right?
And they do call out a couple of numbers saying, quick couple of numbers, including PRs from 2017 compared to 2016.
The number of commits increased by 190%.
Wow.
That's a big deal, right?
The inserted lines of code have increased by 140%.
The number of unique contributors, and this is probably the biggest, actually, this is probably the biggest thing right here.
And I think this is the biggest reason to go to GitHub.
The number of unique contributors has increased by 13 times.
That's wonderful.
Isn't that crazy?
Yeah.
Our new Python releases that come out are like there's way more stuff in them now than there used to be.
Yeah, that's for sure.
This is really cool.
And finally, not just new or unique contributors, but we now have more returning contributors.
There are nine times as many returning contributors as previously.
So people tried it and they liked it.
So that was cool.
I guess that's really the news, right?
You can see the picture.
The picture is actually not that valuable, but those numbers are.
And the conversation under it is more of a conversation of like, what is the value of statistics?
So, you know, that's an interesting conversation to have on the internet around graphs.
But one comment was when somebody said, oh, I would like them to move to GitLab instead.
But this is still good news.
What do you think?
Do you think we'd have this 13 times the number of contributors if it was on GitLab?
I don't think so on GitLab.
Although I use both GitHub and GitLab and they're both great products.
But the GitHub is definitely more of a social place to have more contributors.
I tend to agree.
I think GitLab is great.
I think also places like Bitbucket are great.
But they just don't have that social momentum.
It's like, well, I could have posted the question on Stack Overflow.
But there's another forum that some developers go to.
So I put it over there.
It's like, well, you can.
But it's probably not going to have the same reach and effect.
Right.
So I think it's really great.
And, you know, really, thanks to Brett Cannon, who spearheaded this, one of the core developers,
who got Python over there in the first place.
Yeah.
That's pretty cool.
Yeah, yeah, definitely.
So as developers, it's easy for us to have like kind of a bad self-image.
Look around and go, oh, all these people are so smart.
I'm not very good.
I'm stuck.
Like, I think two days ago, I was more frustrated than I have been in like probably months trying to get something to work.
I was really frustrated.
So you've got an article kind of around this, right?
Actually, somebody posted an article called Self-Deprecation Needs to Stop.
And really, this was Maurice Hayward, and it was inspired by some tweets by Stephanie Hurlbert.
And the comments apparently started with she was trying to get more women to blog about what they're doing, their technology stuff,
and that she would retweet the blog posts.
And many of the ones that she was told about were comments like, well, this project isn't that good, but here it is anyway.
And I guess I'm paying attention to this too because there's a fine line between like being honest about what your skill level is and how you can help,
and also trying not to be arrogant and act like an expert when you're not.
But there's, I mean, if you spent some time working on something and learning it, there are people out there that know less than you.
And I think people need to be, I like this article because people need to be better about understanding that they have learned a lot and they can contribute.
This also resonated with me because as a parent, I really try to stop my kids from self-deprecation speech and not say things like, well, I'm dumb, this was dumb.
Because it can give you a negative self-image and that's bad.
And we do see it a lot in the tech field.
I think partly because we are, we like to solve problems.
So we're always looking at people that know the answer to our problems who clearly know more than us because they've already figured it out.
So this is good.
Yeah, it's definitely good.
And no matter how experienced you are, you can find something that will frustrate you and make you feel stupid in tech and programming.
I'm sure of it.
This was repeated in the article, but it was from Stephanie.
He has really like three points, which I numbered them one, three, four, which is interesting.
I'll have to fix that.
But first off, stop saying words like my project is not good.
It's just a thing I wrote or it's just by a newbie or it's silly or it's not useful.
Just share it and let others be the judge.
The second point is really think about the value you bring and let everybody know what that is.
This is advertising for yourself and your public image also might reflect on a job interview sometimes.
So don't be too hard on yourself.
And also just like be proud of the things that you've done.
It's completely okay to say, man, I did this thing.
It was really cool.
Here it is.
Yeah, I think that's great advice.
People should definitely put what they do out there and just let people know what they're up to.
Very nice.
All right.
So it wouldn't be a Python byte if we didn't somehow feature our friend Anthony Shaw's work, would it?
Yeah.
It seems like he is so prolific and doing such cool stuff.
The last item I want to cover is something called five speed improvements to Python 3.7.
Oh, this is nice.
Yeah.
So Anthony's digging deep into Python 3.7 for a project that he's working on.
And I'm sure he'll talk about that later.
But he's been trying to explore this through blogging and so on.
And so this is a really nice article for a couple of reasons.
One, it's nice to call out the things that are going to be faster in June.
That's great.
When Python 3.7 comes out.
It's also cool because you see him doing a lot of internal introspection and looking into Python, like with the disassembler and the opcodes and seeing how different methods actually turn into operations in the CPython interpreter, which is really cool.
So let's talk about the five things.
So one is calling methods will be faster, kind of maybe, sometimes, in Python 3.7.
Okay.
So the reason is there's actually two new opcodes that are being added.
And under certain circumstances, these can either remove the slowness of methods, functions tied to classes, or generally other ones.
I think if you have a bound method with no arguments, it's going to be faster than it was before.
So he has some numbers.
I don't remember exactly what the numbers on this one were.
String.find is faster for some characters by a lot.
So some of the time you're working with standard ASCII characters and everything is fine on string.find.
But for some reason, the way Unicode is laid out, there's certain types of characters that can make it up to 25 times slower to call string.find based on the input.
That's crazy, right?
Yeah.
So they said these are still slower than standard characters in Python 3.7.
But now they're only three times as slow, not 25 times as slow.
So that's still a really good speed up, right?
Close to 8x.
That's good.
Let's see.
Really quickly, os.fwalk, which creates like a tree directory structure type thing, which you can point it at a folder and it'll create like a subtree of files and folders.
It's now twice as fast.
Regular expressions are faster, but only in like a weird way.
Like they're less, they were changed in Python 3.6 basically for, I don't actually know why they were changed, but they were changed in Python 3.6 and that slowed them down.
So now this fix kind of puts them almost back to as fast as they were in 3.5.
So take that for what it is.
Okay.
And finally, regular expressions that are case insensitive are now 20 times faster.
Oh, awesome.
That's really good.
So basically the internal implementation of that, it used to call lower on every character.
which I guess was slow.
So now it can just like work on them in a different way, which is great.
How did I not know about fwalk before?
Yeah.
I got to look, that looks neat.
It does look neat, right?
Like I've traditionally used like recursion and stuff like that to deal with this, but yeah, I don't think you need it.
You have to check that out.
Maybe you still do, but it definitely, it returns like a tuple with four items with like the directory, the subdirectories, the files, things like that.
It's pretty cool.
So does he have like some, I haven't read this article.
Is there, are there like a benchmark of a, you know, a little application that runs in Python 3.6 versus 3.7?
That is a good question.
I did not see that.
It may be in there.
He was just quoting the numbers of his testing, but I don't know if he actually had a demo.
He may, and I just didn't catch it.
Okay, cool.
All right, Brian.
That's it for our news this week.
But you've got some follow-up stuff.
First of all, we talked about your PiTest, PiCharm webinar, and that was in the past at this point.
But the recording just came out, didn't it?
It did just come up.
And so I went back in this last week.
I listened to it.
And there's a couple things that I noticed, especially with respect to this, you know, don't be hard on yourself and self-deprecating speech.
Because my memory of it was I felt really embarrassed about the times where I didn't know the answer because people are asking in real time, and I don't want to, like, you know, go and look it up or something.
You're on the spot.
Hundreds of people are there, and it's being recorded.
Yeah.
So it just gave me, like, and then I listened back to it.
It's really not that bad.
And so there are some pauses that I have there, which are fine.
But I think I'm going to try to be easier on myself.
I think it would be a useful thing to watch if people aren't familiar with pytest or using it in PyCharm.
But the other thing was also just on my to-do list is try to come up with better ways to, or some way, to say, you know what?
I don't know the answer to that right off the bat.
I'll get back to you.
Or maybe that's it.
Yeah.
I don't know the answer.
I have no.
Yeah.
I mean, the last one I did, people asked me about SOLR, S-O-L-R, which is a full-text search type of thing I've learned since then.
They're like, how does this work with SOLR?
I have no idea what you're talking about.
I'm sorry.
Yeah.
Yeah, it's okay.
We don't have to be experts on everything.
The other thing I wanted to bring up is there's a, I don't think it really deserved an entire story,
but the PyPA has put up a post that says they'd like help from package maintainers to test out the new PyPI
because they've gotten funding to do some fixes and they want to see how they work.
Oh, that's really cool.
And a couple of cool things about it is I think people should go help them out.
But the link that I put up, which apparently is broken, I'll fix it by the time this goes out.
If you're asking people for help in beta testing something, this format that they put up is a really nice format to kind of use of,
these are the kind of things that we'd like you to try out, some of the workflows and let us know and how to let us know.
So there's a good template.
Here's 10 things we would love for you to test.
Here's how you check on security.
And here's how we have live chat hours if you find something you want to talk to us about.
That's great.
All right.
Well, I don't really have too much news.
I've been working on a whole bunch of projects, but nothing to announce at this point.
So I just have to keep those under wraps for a little while.
All right.
All right, Brian.
Thanks for finding all these things.
Like I said, every week, these are just so much fun to explore them with you.
So I appreciate you being here.
I appreciate it also.
Thanks.
Yep.
Thanks and bye, everyone.
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.