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 Okken.
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 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.
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 their special offer at pythonbytes.fm/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 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.
So first off, I think this is cool.
So if you're a Mac user, 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 it's a way you can get all Python 2.5 through 3.6 installed easily with just a couple of 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, Node.js, all the things that you need.
It's beautiful.
Yeah.
Okay.
Well, moving on.
Next up, we've got a request 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 await 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 dot 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's 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 Talk Python.
Thanks.
Yeah, he's doing amazing stuff.
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 in the Talk Python training site, this type of stuff.
I don't use this because 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.
Dun, dun, dun.
So I'm over here on pythonclock.org.
And it says, Python 2.7 will retire in two years, seven months, five days, seven hours,
33 minutes, and 35 seconds.
So that's pretty neat, right?
So here's this clock.
There'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.
And 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 if you're, 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 for 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.
Yeah.
So one of the things that I always push, I don't always, but I, my red flag goes up when
everybody, whenever anybody follows something dogmatically, like 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.
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 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 fun 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 a kind of a litters up your class namespace, your interface.
So you, it's harder to tell what the class is supposed to be doing.
Yeah.
I mean, you almost, 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 a hundred
thousand 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, 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 a tension, 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 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've got your Python code, but maybe your Python code is running on a web server.
It's built on Flask.
It's talking to MongoDB.
It's hosted on a set of scaled out Ubuntu servers or Nginx and MicroWSGI.
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.
So they actually have a cool little tutorial you can take at pythonbytes.fm/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/Datadog.
It helps support the show.
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.
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 Y-Python 3.
And what it is, is if you pull it up, there's a simple little code sample of some Python 3
feature that's awesome that you can't use.
And there's a button like, show me another cool feature.
And it'll randomly generate another code sample of something that you could do.
And so I hit it a few, isn't that cool?
So I hit it, it's really simple and quick.
So I hit it a few times.
I got annotations.
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 was 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.
Yeah.
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 as a 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, he, and I'll
quote him.
I feel, 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.
Yeah.
So there's a, Trey 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 a get together and you got like
some specialty beers, we'll go out and try to find some specialty local sodas also, or
make sure that you have a nice, if you've got a spiked punch, make a non-alcoholic version.
And then 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 just in a particular mood today or something because I've kind of
chosen a related type of topics, but we've touched a few times on the podcast.
And I keep coming back to this, not just to like be a cheerleader and rah, rah, rah,
things are great, but you know, people bet their careers at least short term on studying
certain technologies and pursuing one thing over the other, show Node.js over, you know,
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, as 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
a 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 Python, 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.
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, this is, 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 we have been around for a while, like PHP, C++, Java,
it's interesting to see that those charts are, they've been relatively, 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 all of course related.
So I linked to that one in there as well.
Yeah.
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 worth definitely worth checking out.
Hey, that's our six, man.
So that is our six.
That was fun.
What's up with you?
What's any news?
Well, I've been doing a couple of things.
I've been learning 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, change 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 pie cascades.
So this is a new pie con 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 5, but beta 6 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.
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 good to be back together with you, Brian.
I think we're both going to be relatively stable for 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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.