Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
It's Tuesday, May 30th, 2017, and this is episode 28 of Python Bytes.
And I'm Michael Kennedy.
And I'm Brian Okken.
Brian, can you believe that we've done 28 episodes already?
No, I can't. I was telling somebody about the show recently and I said,
oh, we've only done like, oh my gosh, we've done like 27 episodes already.
Yeah, we've done over half a year in the history of Python Podcast.
I think over half a year's worth, over 20 episodes, makes it like one of the longest running podcasts of all time, actually.
Right? A lot of the other ones, they sort of cut out early 20s, you know, things like that.
Oh yeah, that's true.
Yeah, I mean, Talk Python and Podcasting, they've been going for a while, but still.
One of the primary rules that, or documents, or enhancements, that tells us how we should write our code is PEP 8, right?
Yeah, definitely everybody that's really into Python knows about PEP 8.
But sometimes when you mention, hey, you should follow PEP 8 to somebody new, it's not really that easy to get them up to speed.
You know, it's not that hard to read.
But I didn't know about this thing called PEP 8.org.
And so I just stumbled across this recently.
And it's from Kenneth Reitz.
And it's just an easy to use, it is the, just PEP 8, the style guide.
It's a nice webpage with, styled nicely.
It's got red for bad examples and green for good examples.
And it's got a nice index on the left that you can click through.
Yeah, it's definitely, yeah, it's a really nice and navigable thing.
And you're right, like, the green do this, red don't do that.
And, you know, even little touches like the code samples that demonstrate good and bad, just basically any of the code samples that demonstrate anything.
Are color-coded, which is, like, surprisingly delightful.
Yeah.
And I also like, because there's the index there, they're all anchors in the webpage.
So you can take one of those.
And if you want to mention a particular guideline to somebody, maybe a coworker that's not following it, you can email them that link and say, hey, could you read this?
Exactly.
Yeah, put that in your get issue response.
Like, I'm willing to take your PR, but hold on, you got to fix this first.
Yeah.
And, but one of the things that I always want to mention when I talk about Pep 8 is don't be a Pep 8 bully.
The first line of Pep 8 talks about hobgoblins or something like that.
And basically...
Yes.
Blondly following rules is the hobgoblins of little minds or something to this effect, yeah?
Yeah.
So somebody might have a decent reason for not following Pep 8.
So tread carefully when you try to get somebody to follow it.
If you haven't stumbled across Pep 8 before, which is kind of hard to think that's possible if you're listening to this podcast, it does describe itself as being the style guide for the standard library for Python.
But it's a lot more than that.
Most open source Python projects follow it to some degree, don't you think?
Right, yeah.
And you can set up linters that will, like, mention violations.
So, for example, I think cookie cutter, if you do a PR back to them and you do something like, say, write an 81 character line, it will fail the automated build and say we're not going to accept it because it fails Flake 8 or something to this effect.
Right.
Okay.
Yeah.
You know, I suspect everyone, pretty much everyone's heard of Pep 8, but I'm not sure everyone has actually taken the time to read through Pep 8.
And I think that this thing is more readable.
So it's probably, you know, if you're in that group, then go check it out, pepe.org.
Okay.
So what's next?
I want to talk about asynchronous stuff.
Is it surprising?
I always talk about asynchronous stuff.
So there's this new project called Tokio, I think is how you might say it, T-O-K-I-O.
And at the heart of AsyncIO and the Async and Await stuff are these things called Async Event Loops and whatnot.
And this is one of those.
We'd previously spoken about Sanic and some of these faster web frameworks.
And their magic was that they run on top of this thing called uv Loop.
And uv Loop is, I think, implemented in C and is an alternate implementation of this internal AsyncIO loop.
Well, Tokoy is a similar concept, but implemented in Rust.
So Rust is a compiled low-level language such as, you know, like C.
I mean, you can debate with this low-level.
I feel like it is.
It's closer to the metal anyway.
It's a compiled language.
And it's supposed to be a little better for threading, a little better for memory management and safety.
So it's a little bit of a safer, more modern, low-level way to implement this.
And I just thought it was kind of an interesting example that you could go check out and say, like, here's integration of Python with Rust.
Okay.
So it's a Python thing?
Yeah.
So you use it from Python.
But instead of having, like, a C extension, you have a Rust extension.
Oh, okay.
That makes sense.
Took me a while to catch up.
Yeah, yeah, yeah.
So, like, the heart of the asyncIO event loop is, like, written in C when you're looking at a uv loop.
Here it's written in Rust.
And so here's, like, an interesting internal bit.
But you basically plug it into your Python code, and then you can, you know, work with the async event loop like you normally would.
Okay.
And I'm guessing it might be pronounced Tokyo, but just guessing.
Tokyo?
Yeah, yeah.
Okay.
Tokyo.
You're probably right.
You're probably right about that.
So, yeah, cool.
And the project's still super early stage development.
So if you're into Rust or you want to play with Rust and you would like it, a lot of people ask me, like, hey, I want to do something open source.
Is there an approachable small project?
This thing's pretty early days.
And so it's probably not too complicated to jump in and play around with if people are looking for some project to get involved with.
Well, that's great.
Yeah, absolutely.
Tell me about some boilerplate.
Well, this is – I've got another project that is fairly early.
I guess I was just assuming it's fairly early in the project.
But I stumbled across – stumbled.
I'm saying that a lot today.
I came across this – a website called Python Boilerplate.
It's python-boilerplate.com.
And it's addictively fun, at least right at first.
I wouldn't try it on a phone.
Actually, I haven't tried it on a phone.
But it's got a whole bunch of push buttons and stuff.
And you can say which sort of boilerplate you want to have it spit out.
And you can select Python 2 even or Python 3.
Luckily, it does default to Python 3.
And you can say whether or not you want an executable – whether it's an executable script or – and whether or not you want arg parse stuff in there.
Which actually, somebody that wants to add arg parse stuff, it's kind of nice to have some built-in boilerplate of examples.
Yeah.
So it's a little bit like what Cookie Cutter does for large projects where you can say, I want to generate kind of a starter code, a starter skeleton.
But it's more like that but for command line apps, CLI apps, right?
Yeah.
Smaller little projects.
And it even, like, puts together a preliminary – like, for instance, if you add Flask or pytest, for instance, it'll add your requirements.txt to it.
So it's a similar vein as Cookie Cutter but a little more interactive and it's fun.
Yeah, I know.
I like it.
People should check that out.
So that one's fun.
We recently went to PyCon.
It was awesome, right?
It was very awesome, yeah.
Hopefully this year people will take us seriously when we say, get your tickets before it sells out.
Because – anyway, one of the things that's really cool that I really liked from PyCon was the presentation that Instagram – the folks from Instagram did.
And luckily this is all on YouTube so people can check it out.
So Instagram, they're probably not the biggest but they're one of the biggest by traffic number of users and whatnot, consumers or users of Python for their web apps and their backend services.
Like, they seriously use Python.
They use Django in many, many places.
And they had found themselves in a bit of a situation like many, many of our listeners probably find themselves.
But to a degree that is way, way higher, right?
So they've got hundreds of millions of users.
Many, many, who knows how many thousand lines of Python.
And they were stuck on Python 2.7 and Django, I think they said 1.3, which is years out of date.
It's quite out of date.
Like, the current one is 1.8.
The one people are working on is 2.
The big news about Django 2 is it's only going to support Python 3, right?
That was the big news there.
And so they said, we somehow need to get onto Python 3, right?
A lot of companies say we have this huge bit of code.
And so, well, I'll throw my hands up in the air.
We just couldn't possibly switch, right?
It's just too much work.
It's too much risk.
If you watch this presentation, there's almost no way you can look at this and go,
oh, there's no way we can switch to Python 3 after you see what they went through.
So it's really intense.
So, for example, they don't believe in branches in their Git repo.
Wow, I must have missed that.
That's interesting.
Yeah.
It's interesting, right?
Because I think to some degree rightly feel that the farther you are away from master or, yeah, from master,
what they're calling it, the more it's going to be hard to integrate that back in.
And the more you could introduce trouble by merging that back in.
So what they do is they use feature switches.
So if you're working on a new feature, there's a config on your dev server that says,
enable this feature.
But in production, it might be turned off.
So they're shipping.
They said they check in to the master branch quite often, like many times a day.
And with an hour of that check-in, it's pushed to production, even when the features are not done.
Right?
So now they have this huge, huge branch of Python code where lots of the libraries and modules and stuff are shared across different services and different servers.
It runs on our old version of Django on Python 2.7.
And they're like, all right, what we're going to do is we're going to upgrade to Python 3.
And we're not going to branch.
We're going to keep shipping on this main branch and convert it to Python 3.
We're going to upgrade like years worth of Django.
I'm going to keep shipping on Python to production and so on.
And so the process that they went through and the little steps that they took, and even for you, the testing procedures they went through to make this work was really, really interesting.
So basically, I'll give you guys the summary.
If you want to watch the video, it's highly recommended.
But it's really a concrete roadmap for every large project, every large company with lots of users and traffic to switch.
So they said they got between 12% and 40% performance improvement, depending on where you look, like, say, the web tier versus the async queue tier and so on.
And I think like 30% better memory usage.
So just like straight across the board, everything was better.
And they haven't even started using the asyncio stuff.
And they're super happy now that they can switch to a new version of Django.
Something cool comes out in terms of performance, say, like Python 3.7.
Some function call becomes much faster.
They just get that.
They don't have to, like, go, well, that'd be nice, right?
They basically, so they get to be part of the forefront of Python once again, and they're happy about it.
So then they, like, start converting their code base so that it could run on Python 3.
But they were still deploying on Python 2.7.
Yes.
Yes, exactly.
And then eventually one of the changes, one of the steps they made was we're going to make all the developers run and develop on Python 3, but still deploy to Python 2.
And so that was one of the main, like, checks and balances was the developers will start hitting these bugs locally.
I will never push it out.
And then they didn't push it out to production fully then.
They pushed it out to just Facebook employees.
And then they pushed it out to 0.1% of their users.
Yeah.
To see how that worked.
And then finally they started, they switched to, like, 20% and then, like, they pushed it all the way out.
Something like that.
Yeah.
So it was a really interesting rollout.
And on their testing, they had, like, at first there was a bunch of tests that just couldn't be fixed.
And so they set up a, like, these are the tests that are included in the automated build.
And slowly as they migrated tests, they added them to also include this so they would not regress back to be broken.
Yeah.
And they kind of chopped their way through that.
And then eventually they said, okay, the default is new tests all have to pass on Python 3.
And the old ones are going to go into this exclude list until we get the failing ones to 0.
And I really liked the presentation.
And I liked how they talked about actually a lot of the points that they went through.
And it's a lot, I think the example is a good example for any project.
But the, I also, I really liked the, just the reality that it's not trivial.
Yeah.
No, it wasn't trivial.
It was like six months or four months or something huge.
Yeah.
But very doable and while in production.
That's pretty cool.
Yeah.
And they also kept shipping new features, right?
That was one of their requirements.
Right.
So they shipped a bunch of new features at the same time.
I bet they used at least one underscore in their code when they did that.
Probably several underscores.
Yeah.
We've featured Dan Bader on the show a lot, but this is a pretty cool article.
The meaning of underscores in Python.
And again,
I think this falls into the realm of like what you said with PEP 8, right?
Like a lot of people are seeing these, but maybe they haven't really looked specifically at what it's about, right?
Yeah.
And also he goes through pretty much all the different meanings.
But one of the things that I, it took me a while to understand is that when people say dunder, they mean something with two underscores on both ends.
Yes.
Shortened of double underscore.
So it's a good list.
He talks about the leading underscore, meaning that it's sort of by convention, private for, or internal use only.
But, and I added a note in our show notes that that doesn't apply to named tuple.
Named tuple has its functions starting with leading underscore, but you can still use them.
That's what they're for.
Yeah.
Nice.
Yeah.
I was just pairing with somebody today and said, what does class underscore mean?
Like why is the underscore there?
Oh yeah.
Right.
So if that's the trailing underscore, it's because somebody doesn't want to collide with a Python keyword or something.
Yeah, exactly.
Like it's class.
So class underscore.
Yeah.
And I do like, I actually like that convention a lot better than having like my class or this class or something like that.
I know that really.
Yeah.
And one of the things that a lot of people don't, that I was surprised by when I first learned about it is a single underscore by itself.
Yes.
That's my, one of my favorites.
And that's a, that's a, I don't care variable that you can, like, if you have to assign a variable, something to a variable, but you're not going to use it anymore or use it at all.
That's a decent one.
And the warning, you don't get a warning for that.
If it's a, something assigned and never used.
Exactly.
It's meant to not be used.
Yeah.
I mean, the couple of places I see that like a tuple unpacking, when you don't care about all the
values is kind of good.
If you say, I just want to do a loop from one to 10, but I don't care about the number.
I just want to do it 10 times.
You could say four underscore in range, you know, zero, 10, whatever, things like that.
That's a good use for that.
Yeah.
The other place that I really liked this is where I have function signatures.
I have to match, but I don't care about the variables.
So for example, in the web methods, a lot of them take request as a parameter.
And if you don't put the request parameter there, like the framework will fail to like try to pass it and won't like match and it'll crash and all that.
But I don't care about calling the request variable or working with it.
So you'll get like a flake eight violation.
You're not using it.
So underscore.
In that case, can you use it multiple times?
Like, can you have multiple parameter names that are underscore?
I think so.
Yeah.
I mean, you just like blast away the previous value stored in underscore, but if you're really using it as like, I don't care, then it's fine.
Cool.
Okay.
Yeah, absolutely.
So the underscore is definitely good.
If you're not familiar with that, check out Dan's article.
It's a good one.
So let's close this out with a little bit of a look towards the future.
Okay.
And we talked about recently the Stack Overflow tools, trends tool.
And when Stack Overflow released it, one of the things that they featured right up in the front was like language popularity for a few languages, including Python.
And it looked pretty good, right?
Yeah.
So I want to come back.
There's a guy who wrote a Medium post that actually dug into this quite a bit and played around with it and said, the future is looking bright for Python.
And basically took that tool and did a little better analysis with it than we did.
And there's one chart that they put up as a standard chart at Stack Overflow since we covered it called the most popular languages trend chart.
And that's got like 15 languages or something still.
It's really completely overwhelming.
But if you hover over the language names, it highlights them and dims the other so you can actually see it.
Okay.
Cool.
What's really interesting is if you go through that chart and you hover over the languages, there are only like two languages that have upward trends and recently.
And which one is the most steeply upward?
Has the most positive derivative?
Well, probably Python.
Of course it does.
Actually, by quite a large margin.
And there's also a trend chart on there for Python 2 versus Python 3.
And last year, Python 3 overtook Python 2.
Oh, nice.
So just a little, same kind of ideas with this trends, but just digging in a little more detail on it.
It's kind of interesting.
I thought it'd be fun to tie that together with the Instagram story so you can go back to your company, your boss, whatever, and go into life 2020 for Python 2.
Django is no longer supporting Python 2.
Look, the Python 3 is growing here.
Just like all the good stuff, right?
Bring it all together to help get a little more Python versus legacy Python in the world.
Yeah, and I definitely don't hear, a couple years ago, we still heard people coming up with good reasons to stay on 2.7.
And I don't hear anybody talking about that anymore.
Nope.
It's definitely, definitely, we've crossed over some sort of boundary, for sure.
Well, hopefully also in the future, it'll bring us at least another half year of Python bytes.
I'm pretty sure we can at least get another half year of this.
Yeah, so.
It's fun.
That's all of our topics.
Any news for us, Michael?
No real news for me.
I'm just recording podcasts like crazy, trying to get ahead for the summer.
So I have, like I was just telling you, the opening of the show before we hit record, like eight episodes of Talk Python to Me.
I'm recording over the next six, seven days.
So there's going to be a whole bunch of good stuff lining up, and I'm excited about what's coming.
How about you?
I'm kicking off some more recording also.
Definitely the book is still going strong.
Yeah.
And doing a lot of work on that.
But I recorded an interview this morning, and I'll have at least a couple coming out in the next couple weeks.
So Test and Code is not dead.
It will come back.
What was the topic?
What did you record on today?
Actually, I recorded somebody that does mobile testing.
So mobile application and mobile and responsive web page testing.
And it's a company that offers a service that has, like you can rent a device.
So somebody, like, tells you that your website or your web application or something doesn't work on this particular device.
You don't have to go out and buy it.
Yeah.
Android, Oreo, whatever, right?
Yeah.
It's on this?
Yeah.
You can go and rent it for, like, I think their prices are, like, 10 cents a minute or something like that.
But you can – I have no idea what their prices are, actually.
I can't remember.
But it's a commercial product, but I want to make sure that Test and Code isn't just about open source stuff.
It's also companies that are helping out that area.
So it's good.
Yeah.
It's cool to cover the whole spectrum.
And can you imagine what their data center must be like with a thousand different phones running in there?
Yeah.
And I also asked them silly things like, okay, so I operate my phone with my finger.
Do you have somebody – are you paying somebody to move their finger or something?
And they said, no, they've got that all figured out, automated.
So –
Perfect.
All right.
Well, Brian, thanks for sharing the news this week and meeting with me.
And as always, you know.
Yeah.
Thank you.
Talk to you later.
You bet.
Bye.
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.