Python Bytes - #42 Behold: The Python 2 death clock

Episode Date: September 8, 2017

Topics covered in this episode: What Kenneth Did Last Week (well, recently) Python 2 Death Clock Small Functions considered Harmful Why Python 3 EANABs The Incredible Growth of Python Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/42

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 42, recorded September 6, 2017. I'm Michael Kennedy. And I'm Brian Ocken. And we have the band back together again. How about that, Brian? Thank you so much for carrying the Python Bytes news banner while I was gone. And then, like, I get to pay you back straight away a little bit.

Yeah, it was fun listening to one with you and I'm blanking right now. Yeah, Miguel. Yeah, Miguel. It was great. And then it was kind of fun to talk with some new people. But I'm not ready to replace you yet. Yeah, no, no. I think this idea of maybe every now and then having someone else drop in and give it a fresh set of topics might be cool.

But yeah, no, it's great to be back together. So before we get started, I just want to say thanks to Datadog for sponsoring this show. You can check out what their special offer at pythonbytes.fm slash Datadog, which is actually really cool. You get something out of it. So that's sweet. But let's talk about what a couple of the, one of the prolific Python developers out there, just in one week, what he's been up to. Yeah, I think it was the last week. Kenneth Reitz has been very prolific and it's, I don't know if he's got insomnia and he's not sleeping lately, but he's put out a bunch of stuff recently and instead of spreading it out entirely for our entire episode, we're just going to lump it all together. This basically could be an entire

episode. Yeah, it could, but you know. That would be wrong. That would be wrong. So first off, I think this is cool. So if you're a Mac user, you, maybe you use homebrew to install stuff. And one of the things he's put together is homebrew pythons, which is a tap. I didn't know there was a thing called homebrew taps but uh it's a way to you can get all python 2.5 through 3.6 installed easily with just a couple command lines yeah it's beautiful you just basically register kenneth's tap and then you just say brew install python dash 3.6 or 2.7 or whatever i really like brew and I've been starting to use it more and more for my Mac. The next time I set up a fresh operating system,

which seems to be about like yearly, I get frustrated and format the thing. So next time I'm going to just brew install as much as I can, like MongoDB, Python, no jazz, all the things that you need. It's beautiful.

Yeah. Okay. Well, moving on. Next up, we've got Requests Threads, which is a, I think it's something built on top of requests that uses Twisted's deferred objects as a return object for requests. And so you can use it with either Async and or with twisted to have asynchronous reading through requests easily. Yeah, it's really, really cool. So basically you create this async session and you just say await session.get.

So you have actually two ways. You can do async await Python 3.6 style, which is really cool. Or you can use twisted deferreds, which work in basically every version of Python. So you actually can pick, and it's really, really cool. So I'm looking forward to seeing that rock. And it basically looks like the last activity on everything was a couple days ago. So yeah, this is kind of new. It's kind of cool. And also, before we move on, I really enjoyed your, you interviewed somebody about Twisted recently.

Oh, yeah, yeah. That was Glyph. That was the most recent episode that's out, but probably not by the time. That was 127 on TalkPython. Thanks. Yeah, he's doing amazing stuff. And so that kind of riffs on this as well, for sure. Okay.

Now, thinking about instead of threads, you might want to just have a background task. And Kenneth has that too. He's got a repo called background, which just runs stuff in the background. Yeah, it's beautiful. You basically put like a decorator on a function and then it becomes this async background thing that you just kick off like fire and forget style. It's really, really cool. Like you can do it for CLIs. You can do it for web apps. I use this and the talk Python training site, this type of stuff. I don't use this cause it's new, but like when I first built it and,

you know, gave it the capability to like email thousands of people and update, it turns out that that's really bad to do in a serial way on the main thread. So you got to kick that kind of stuff off the background threads or things like Celery. And this is a really cool way to do it. I know that there's Celery and other things, but having some simple way to just ease into multi-process programming, and it's really hardly any code at all. Right. There's no extra service. It just runs in process.

It's simple and easy. Yeah. Last up from Kenneth, although I'm sure I'm missing something that he's been doing recently, is setup.py for humans. And this isn't something you run. It's just he's got a repo that's an example setup file, which he directly off of it, this repo exists to provide an example setup.py file that can be used to bootstrap your next Python project.

It includes some advanced patterns and best practices, as well as some commented out nice-to-haves. And it had a quick look through it, and it looks actually, I like it. Yeah. So get out there and make that module package, right? Very, very cool. Okay. And so, Kenneth, either slow down, or we're going to have to have another podcast just

to talk about your stuff. And he has his own podcast, which is pretty long form, so maybe he covers this stuff there as well. Yeah, maybe. I'm not sure, but yeah, definitely. All right. So up next is a really positive thing but it sounds kind of negative i want to talk about the python death clock

so i'm over here on pythonclock.org and it says python 27 will retire in two years seven months five days seven hours 33 minutes and 35 seconds so. So that's pretty neat, right? So here's this clock that's just a running animated countdown till the 2020 timeframe when Python 2.7 is going to be no longer maintained when it goes out of support and things like that. Yeah. So this is the get, it's counting to what a best guess for when PyCon in 2020 is? Yeah, isn't that interesting? There's no, when they said they're going to retire Python 2.7, they didn't say we're going to retire it on June 1st, 2020, or we're going to retire it on December 31st, 2020. It's just, you know, within that year, kind of.

So there's a couple of interesting things here. This guy's like, all right, so when would be the ideal date to retire this? It would be PyCon 2020, of course. So he says, I hereby suggest we make PyCon 2020 the official end of life date. And we throw a massive party to celebrate all that Python 2 has done for us. Python 2, thank you for your years of faithful service. Python 3, your time is now. Sorry.

So, yeah, I think this is a really cool idea to sort of encourage people to move from legacy Python over to modern Python. And it's fun to just, you know, have up when you're leaving your desktop open, going to have some coffee. You can just remind everybody around you that Python 2 is dying. That's right. Or if your non-technical manager says, we can't really afford to upgrade that old Python 2 code, you can say, well, here's the Python 2

death clock. So this is our timeframe. This is an upper bound from when we should get to this. Yeah. So this other one that you want to talk about is pretty interesting. It's kind of a design pattern, almost a pushback on some of the more intense design patterns, I would say. Just this is a best practice. Follow it or else. I don't I don't like that. This is a article called Small Functions Considered Harmful. And it just takes a look. It takes a look at there's a quote from here. General programming advice doled out invariably seems to extol the elegance and efficacy of small functions. functions and i have seen i've seen that like this the author has to an extreme where sometimes people will go to the point where they're writing very small functions like one-line functions and that and i think that's okay for some cases like complicated math maybe it makes sense but small functions that are only used in one place it actually actually doesn't help. And so there's, she goes through and talks about quite a few problems with small functions, including like just making your,

there's a lot of things that she talks about, but I think that just makes it code harder to read to me and especially to newcomers. One thing I didn't think about was if you're using classes a lot, adding more class functions, just kind of litters up your class namespace, your interface. So it's harder to tell what the class is supposed to be doing. Yeah. I mean, you almost got to go to the level of like using double underscores to make that stuff not show up.

Right? Yeah. Right. Sort of hide it. So, okay, these are the internal things. These are little stuff I broke it into. I have mixed feelings about this. I am sympathetic to what Cindy says. I feel like she has a really good point. And certainly some

of these like dry principles, some of the design patterns taken too much to an extreme are really painful. Like I would say one of the hardest applications I've ever worked on is this like 50 to 100,000 lines of code that was just fully abstract, everything design pattern, this dependency injection that and just every time I wanted to do something like where does this live? How can I tell what it does? I know like somehow it's assembled at runtime. So this thing happens, but like there's so many pieces and patterns contributing to it. It was really, really not good. And I think that's what she's kind of riffing on. But I also think there's, it doesn't hurt to necessarily encourage people to write small functions, but if they get too small, it is certainly a problem. My, my rule of thumb that I use is, does the function need documentation to tell what it

does? If it does, it's probably wrong. Now, that doesn't necessarily apply to like, it's an API in a public package, and you've never seen it, right? But in your own code, like, do you need comments to tell you what that function does? Or does a short, simple name tell you what it does? Like, that, I feel like anytime I'm about to write a comment and Martin Fowler, I think it's Martin Fowler has a really interesting way of talking about comments. He says, comments are deodorant for bad code. So I feel like if I'm about to write a comment about a function, I'm like, Oh, this probably just should be rewritten. So it's really clear what it does. It's certainly attention, but I guess maybe the warning is don't take it too

much to the extreme. It makes it at least as bad or as bad. And I want to touch on one more thing because I've been thinking about agile and agility a lot lately, especially with refactoring code. And one of the comments she brings up is that breaking up your code into small pieces can create premature abstractions. So you're breaking it up into multiple pieces and that makes it harder to, it might make it harder to refactor once you completely understand the problem space. So I think, I think the time to break up things is after you've completely mostly solved the problem and you're just making it maintainable for the future. Yeah. That's an interesting point. Like once you fully understand and have solved the problem,

like apply some refactoring tooling or concepts against it, and then it's much more likely to be stable and you've got the big picture and then you break it up. Sure. I agree. Nice. You know what I've been thinking about lately? What? Datadog. Oh yeah. Yeah. So Datadog, they're sponsoring this episode thank you guys what they do is basically they let you have an entire view of your entire system not just your

application so you got your python code but maybe your python code is running on a web server it's built on flask it's talking to monga db it's hosted on a set of scaled out ubuntu servers or an nginx and micro whis, you can actually integrate Datadog into all those things that I've mentioned and get an entire view of how your overall system, those things all taken as a whole work, not just logs or performance monitoring for your Python app,

which is pretty awesome if you have a big distributed system. Yeah. Yeah. So they actually have a cool little tutorial you can take at pythonbytes.fm slash Datadog. And it takes just a few minutes. And they'll even send you a cool Datadog t-shirt if you do the tutorial. So check it out at pythonbytes.fm slash Datadog. It helps support the show. Yeah. Yeah. If I do the tutorial, can I get a t-shirt even?

You can get a t-shirt. I don't think you've been excluded. Okay, great. Awesome. We could both go get a t-shirt. Awesome. So think you've been excluded. Okay, great. Awesome. Yeah, we could both go get a t-shirt. Awesome. So we talked about the death clock a little bit. Let's talk about more sugar, less of a stick type of a thing to encourage people to use modern Python. I ran across this site. I can't remember where I found it, but it's really cool. It's called WhyPython3.

And what it is, is if you pull it up, there's a simple little code sample of some Python three feature that's awesome that you can't use. And there's a button like show me another cool feature. And it'll like randomly generate another code sample of something that you could do. And so I hit it a few in that cool. So it's really simple and quick. So I hit it a few times, I got annotation. So type annotations, like functions, say it takes two integers and returns a string or something like that. Keyword-only arguments, which is pretty cool. So a way to say like you're only allowed,

you can basically say like you must pass these certain arguments as keywords, which was not a thing in Python 2. Yield from for basically consuming generators and turning them into generators. Enums and a bunch more. You can sit there and keep clicking, give me another random sample. It's fun, right? That is nice. Yeah, cool. So just go play around with that. Actually, there's a few things that I learned

about that I didn't know, like the secrets. I just have no reason to really play with the cryptographic secret stuff, but that's apparently new in Python 3 and pretty nice. Nice. So let's talk about something a little above the code, but something happens a lot in technical spaces. Yeah. Drinking. Drinking, definitely. And speaking of secrets as well, there's a secret that is not so much the secret that not everybody drinks alcohol. So I actually got, I thought about this a lot because Trey Hunter brought it up recently on Twitter, and he said that a lot of the conferences and tech events that he goes to, and I'll quote him, I sometimes feel excluded when events include nice alcohol, but cheap soda. And I've never really thought about that before. And I want everybody

else to think about it. And so there's this acronym called ENAB, E-A-N-A-B, which is equally attractive non-alcoholic beverage. And I think it's a cool idea. So, um, there's a tray also linked to us to got us onto a Stanford site because there is like an alcohol.stanford site, which is cool. ENABs are required for all Stanford parties and it's a, it's a cool idea. So if you're going to have like, like, let's say we have, um, a get together and you got like some specialty beers, we'll go out and try to find some specialty local sodas also, or, uh, make sure that you have a nice, if you got a spiked punch, make a non-alcoholic version. And then, uh, the Stanford site also has quite a few mocktail recipes that look easy and delicious. Yeah, that's cool.

And those are pretty easy to do, right? Like here in Portland, I know we have a bunch of like locally brewed root beers, for example, and things like that. Yeah. So yeah. Hot lip sodas, yum. Yeah, hot lip sodas. Those are really nice and not alcoholic unless you spike them.

And I think most events now think about having non-alcoholic stuff too, but it's the equally attractive part of make sure that you're not getting cheap stuff if you're going all out on the alcohol. You could have either that really cool minty cocktail or RC Cola. Yeah. And if you're in the Portland area and you are serving cocktails, let me know and I'll show up. Yeah, yeah, exactly. I'll be there with you guys. Yeah.

Awesome. So there's probably a theme. I don't know, maybe I was show up. Yeah, yeah, exactly. I'll be there with you guys. Yeah. Awesome. So there's probably a theme. I don't know. Maybe I was just in a particular mood today or something because I've kind of chosen related type of topics. But we've touched a few times on the popularity of Python. And I keep coming back to this, not just to like be a cheerleader and rah, rah, rah. Things are great.

But people bet their careers, at least short term, on studying certain technologies and pursuing one thing over the other, show Node.js over Python and web apps or something like this, right? So there's a really interesting article from Stack Overflow. And Stack Overflow, I think, is killing it in terms of deep insight into the developer community.

And the title is not so bad here. It's The Incredible Growth of Python. How about that? Yeah, this is actually a fascinating article. So I'm glad that you brought it up. Yeah. So I just, it came out today, like just a few hours ago. I'm like, we have to cover this today. So the idea is they recently wrote it. This is not this article. Previously, they wrote an article exploring how wealthy countries, those that are defined by high-income countries by the World Bank, tend to visit a slightly different set of technologies than the counterpart of developers in the world. And they said, well, if we actually look at that set, the largest difference we saw was among Python programmers,

and the Python programming language. And in high countries, Python is even more popular, more extreme in its popularity than things like Stack Overflow Trends, Google Trends, and other language rankings would make it out to be. So they basically said, in this article, we're going to make a case that Python has a solid claim to being the fastest growing major programming language, period. Yeah, so did you look through some of the graphs in there? Yeah, well, the one that I didn't understand, hoping you can explain to me, is the predicting future growth looks like an even larger gap between Python and everything else.

Yeah, yeah. So they started out by saying in June 2017 was the first month that Python was the most visited tag on Stack Overflow, period. That's, of course, all those conversations restricted to these high-income nations, right? US, Europe, Canada, Australia, those types of places. But if you restrict your attention to those areas, Python is by far the most visited. It's actually grown two and a half times in popularity since 2012. And there's one that compares it to, there's a graph called Python compared to smaller growing technologies.

But what was the first one? You asked me about which one? Looking at future growth. Oh, right, right. The prediction of future growth. So they said, look, if we're going to look at these graphs over from 2012 until now, and then the guy who wrote this article is actually a data scientist. And he said he used to do a little Python, but he only does R. So he doesn't really have much of a

horse in this race. But he said, let's apply statistical modeling to the growth curve out to 2020. And if you look at that, it's just like crazy. So they say, well, maybe there's going to be a back and forth with Java as students go back to school this month, and they're going to look up issues for their homework because Java's taught a lot of the first year computer science. But if you follow this trend, it's like it's domination. It's basically what he said. There's another one that's really interesting

because I feel like people compare this a lot. It says Python compared to smaller growing technologies. So Python often gets compared to things like Go and Rust in the data science world. It gets compared to R and so on. And there's a graph showing it just like 10, 20 times more popular and steeper growth curves than all of those languages, which I think is really interesting because people kind of see these shiny new languages and go, oh my gosh, I should just abandon Python and go write Go or whatever. And that may be true for some particular case, but not in general. Yeah. And some of the strong languages that have been around for a while, like PHP, C++, Java. It's interesting to see that those charts are,

they've been either relatively flat or slightly declining for the last few years. Yeah, a lot of the standard well-known ones, the ones you named, right, they are definitely slowly, slowly trending down, which is not amazing for them. Yeah, so also related, there's another article. I almost covered this one, but in fact, this one was just so, so neat and had so much data behind it that I thought I'd rather cover this. But there's another one that says Python overtakes R to become the leader in data science and machine learning platforms. So these are of course related. So I linked to that one in there as well. And finally, one, one wrap up is this was applied

to high income countries. If you apply to countries that are not in that group, they said Python has the exact same growth curve. It's just, it's starting at a lower point. So they expect in the future in a few years that to also be able to make these kinds of statements there, but there's like a lag and they talk a little bit about that. It's kind of interesting. Yeah. I'll have to go back and read those other article because I don't understand why the difference between different countries. I didn't get a good solid answer there either. Okay, cool.

But definitely worth checking out. Hey, that's our six, man. That is our six. That was fun. What's up with you? Any news? Well, I've been doing the joyful bit of the decay of online courses and been re-recording some of my online courses, sections of them as the web properties they depended upon, like web services or something, changed their model or went away. So that was fun.

But it's all good to be able to keep that stuff fresh. Also, I'm going to Pi Cascades. So this is a new PiCon in Vancouver, British Columbia, beautiful place of the world in January, 2018. So I already booked my flight and I'm trying to get you to go and you're on the fence, man. Yeah, I really want to go. I don't know what my January is going to look like yet, but I should decide soon so I can get a flight. Yeah, you definitely should. Awesome. How about you? What else is new? Well, I just got back from Germany. And one of the things I did there was I met up with the, I want to shout out to everybody at the Munich Python user group that like less than a week's notice decided to come together and hang out with me for an evening,

which is like totally awesome. And it was a lot of fun. We talked about PyTest, of course, but we talked about quite a few other things as well. Yeah. That's awesome. They were able to put that together on a short notice for you. Yeah. And then something happened just today and I didn't even know it was going to happen. So the PyTest book I'm now no longer working on. The last beta was beta five, but beta six just came out today, which is the, I wasn't involved at all, but it's all the copy editing changes. They fixed all my typos. Oh, nice. So this stuff has been pushed off to the editors and they're rolling it back out to the readers, huh?

Yeah. And so it's just a, there's some magic machine now that turns it into a book, a physical book. So that's. Does your book have a version number? Like 1.3, 0.7, 0.6? No. It should. Well, I mean, all of it's stored in revision control,

so it has versions that way. Yeah, it just has a SHA really long, hard to make any sense of. Awesome. All right, well, it's great to be back together with you, Brian. I think we're both going to be relatively stable for the next few episodes probably, so that'll be good. Yeah, definitely. So thanks a lot.

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 Auchin, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.