Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 72, recorded April 4th, 2018.
I'm Michael Kennedy.
And I'm Brian Okken.
And we've got some awesome stuff for you.
Before we get to it, Brian, I want to say thank you to Datadog.
Check out what they're offering over at talkpython.fm/datadog.
And they've got a bunch of cool stuff, including a cute little doggy t-shirt.
I still need to get one of those.
I know.
I don't have a shirt either.
I really need to do that.
All right.
I guess the first thing we should talk about is versioning.
When I normally look at commercial software, they have numbers in the front, like version 6 or 12 or version 3 of this software.
It's pretty rare to have 3.anything in open source, isn't it?
I don't know if it's rare, but there sure is a lot of stuff that's still...
We think of stuff that starts with a zero as being in beta.
And it's not...
Well, like, for instance, with semantic versioning, you can...
Once it's at 1.0, the interface is pretty solid and you can depend on it.
But there was a website put up this month called ZeroVer to talk about zero-based versioning.
And it's sort of tongue-in-cheek.
It's from one of our friends, Mahmoud Hashemi, and some others that started it.
But they kind of wanted to call out a bunch of Python projects and other projects that are perpetually starting with zero by putting up this sort of mock website to say that you don't need to do anything other than zero-based versioning.
Yeah.
It really helps you.
It gives it...
Like, it starts out with a down-to-earth demo.
It's pretty awesome.
So it has, like, some versions and says, yes, these are good.
Zero.0.1.
Zero.1.0.dev.
Zero.4.0.
And then, no.
1.0.
1.0.0.0.
1.0.18.0.
2018.04.0.
Like, none of these are okay.
Right.
And, yeah.
So if you haven't figured it out, it is a joke.
But it is, like, for instance, I guess I hadn't realized this.
Flask is one of the ones that was called out.
It's currently 0.12.2.
Come on.
It's been eight years.
I think that maybe you can go to a 1.0.
I have a new solution here.
A new way to solve this problem.
Just whenever you print or look at the version number, just strip off all the left zeros and dots.
So it's, like, 12.2 is basically what Flask is.
You know, there's some pretty ones that are very dependent on by a bunch of people that, like, if they completely change the interface, the API, that would be bad.
So they're clear to the point where they could bump to a 1.0.
Yeah, I think eight years, absolutely, is a timeframe where you could say, you know, we're pretty stable at this point, right?
Like, also Pandas in here with a 0.23.
And it's 7.1 years.
So, and also they count the releases, right?
Like, 21 releases of Flask, 75 releases of Pandas, and it's still on a zero.
One thing I would like to point out is if you go and you look at a lot of the sort of manager folks at more commercial-oriented enterprise software groups, so people that use, like, .NET or other non-open source development ecosystems, when they see things like 0.1, they're like, oh, this thing is not ready for us to use.
We can't use this at our company.
And I think it actually sends a bit of a message that this thing's not quite ready.
I mean, I know, obviously, looking at this list, it doesn't mean that.
But a significant number of people, I think, interpret it that way.
And so, you know, I think it's worth considering maybe saying, all right, we're actually at a version where we're going to call it 1.0.
Like, Flask is probably fully ready for 1.0.
Anything that starts with it, it's just the dots and it's not date-based.
People kind of assume it's just semantic versioning.
So, I think semantic versioning is the way to go.
It's not an easy thing, though.
And that's part of the reason why they're being a little gentle with it.
If you check out the About page, it talks about, on here, it talks about really what you should do about it.
But when you're actually running a project, it's hard to decide what's something that's big enough to go to flip the major digit.
Django is doing that pretty well, I think, right?
They had their 1.0, and that was stable for a long time.
They said, we're going to make a major breaking change, so we're flipping to 2.0, right?
The DropPython 2 support and all that kind of stuff.
So, Django is one that's not following Mahmoud's recommendation.
Recommendation, yeah.
Yeah, I love it.
I love it how he branded that, him and all the folks involved.
It's very cool.
So, when we build these projects in Python and any open source system, really, you basically layer on a whole bunch of external dependencies and packages and stuff.
How do you know when something has gone terribly wrong?
Like, suppose you depend on Vexig in Flask, and there's some huge security vulnerability in that dependency.
Do you get notified?
How do you know?
No, I don't know.
You don't know.
Right.
And so, this is actually a really big problem.
It's like, when you think about problems or security issues with your application, it's not just what you have.
It's the stuff you're built upon.
I mean, the whole Equifax thing was a vulnerability in the, was it Swing?
Swing?
I don't know.
Some foundational library in Java, and they just didn't pass it in time, right?
So, getting notified of these things is really important.
And so much of our code lives on GitHub, and GitHub decided they're going to take some responsibility for this and try to help people.
So, there's a nice article that says, GitHub security alerts detected over 4 million vulnerabilities last year, I think it was in the year?
Yeah.
Actually, it's not even the year.
It's since, like, November of last year or something.
So, that's pretty insane.
So, they launched this thing called GitHub security alerts.
Initially, it's only for Ruby and JavaScript, which is lame, but they have Python support coming, which is why I'm talking about this.
And what it does is it looks at your GitHub repo, and it says, are you using a certain dependency?
Is that dependency of a known security vulnerability?
If it does, then, like, right at the top of your repo, you get this great scary warning that says, your application isn't insecure because it depends on this thing that is insecure.
Yeah.
Actually, that's a great idea.
Yeah.
I don't know if you get an email notice, but certainly, your repo looks scary when that's the case.
Like, this happened to one of my courses, and it just came back again because one of my courses, the PyTron course, demonstrates using ElectronJS, editing an ElectronJS app.
And ElectronJS had some security vulnerability.
It's not actually used, but, you know, whatever.
It still says, your app, it depends upon ElectronJS, and it's got this issue.
So, it's pretty cool.
And then, there's some good numbers and whatnot here.
It says, nearly half of all the displayed alerts were responded to within a week, and 30% were fixed within the first seven days.
Oh, that's great.
That's good.
That's a good thing that they're adding that.
And it does.
So, you said it's coming for Python, and I see that it is planned for this year for 2018.
So, that's good.
Yeah.
There's not a whole lot of details about exactly when it's coming, but, yeah, that will be great.
They said if you look at repositories that have had a contribution in the last 90 days, so things that are active, it says 98% of such repositories were patched within fewer than seven days.
Like, that's insane.
That's a really big deal.
Yeah.
So, they said they found over half a million repositories that had some kind of security vulnerability and were pretty much fixed up.
So, anyway, that's all really good.
I just want to give a shout out to PyUp as well, P-Y-U-P dot I-O.
I use that for my stuff, and it basically does the same thing and more for Python already.
So, you link it to your GitHub repo.
It'll, like, look at your requirements dot TXT.
If there's a new version, it'll send you a PR to upgrade your dependencies.
And if there's a security alert, it'll tell you.
Don't really want to get on this tangent too far, but I started using PyUp for the cards project that I started recently.
Since I'm sort of doing this project, I can't remember who I read it from,
but the packages that are intended to be used by other applications probably shouldn't have their versions pegged.
So, if I unpegged all my versions in a package, then PyUp dot I-O kind of complains about that.
Yeah, that's a little bit.
It does require you more or less pin your versions.
And you can do expressions.
Like, I want it to be this version or higher, and I think maybe it'll upgrade it.
I don't know.
There's a little flexibility.
It's not perfect.
But for, like, fixed apps, like my web apps, I'll have the stuff pinned, and it just automatically updates.
Because nothing depends upon it.
It's fine.
Yeah.
Yeah, pretty nice.
And it's free for stuff, so for open source.
Yeah, it's pretty nice.
Great.
Speaking of open source, PyPI is the place where it lives, and now you can describe it better, right?
Yes.
I'm very excited about this, because, like, the cards project I was working on, I was sort of bummed that I had to put the readme in rest.
Or not rest, but restructured text.
And now you don't anymore.
That's awesome.
So readme.md and a couple other variants of that extension are now supported on pypi.org.
And we're linking to a couple articles, one of them basically describing all the steps you have to do.
There's a little bit of changes you have to do to your setup.py file and a couple other things and update all your tools.
But for the most part, it just works, and that's awesome.
And then also, just recently, GitHub-flavored markdown has been added.
Oh, yeah.
That's nice.
GitHub-flavored markdown has a little bit more, I think, from the stuff that I played with.
Like tables and cross-
Yes, tables.
Markthrough and stuff.
So that's nice.
And I'm looking forward to changing a couple projects to utilize that.
And now the old legacy PyPI, which I think maybe they've taken from your legacy Python.
I love it.
Yeah.
It still renders the descriptions as plain text, but they comment, don't worry, it's going
away real soon.
Yeah.
I was just talking to Ernest, who's doing some of the work there.
And they're really, really close to just saying PyPI.org is where you go and doing a redirect.
He said, you know that little scary bar across the top?
He said, you can now dismiss that.
But I want it to just go away automatically.
When does this happen?
PyPI.org is really close to being the thing.
So maybe this will just hasten the move away from legacy PyPI with the descriptions looking
funky.
Yeah.
So hopefully.
Yeah.
Awesome.
I'm really excited to see PyPI making some progress.
It felt kind of stale for a little while.
And it seems like it's really been rocking the last nine months.
To be fair, even if your markdown gets displayed as plain text on legacy PyPI, that's the point
of markdown is it's still readable.
So that's okay.
Exactly.
If it were HTML with lots of styles, it would have been different.
That's right.
Yeah.
Nice.
All right.
So before we get to the next one, let me tell you about Datadog.
It's a monitoring solution.
Provides deep visibility and tracking into your distributed apps.
So your application, your data layer, your servers, your services, everything.
So within minutes, you'll be able to investigate bottlenecks and actually see where they are throughout
your entire distributed app, which is pretty cool to put it together.
So if you want to visualize your Python performance today, get started with a free trial and also
get that cool Datadog t-shirt, visit pythonbytes.fm/Datadog.
Earlier I said talk Python.
They both work, but pythonbytes.fm/Datadog.
Speaking of web apps and distributed things and whatnot, I think there's a really interesting
new web server that people should start paying attention to in the Python space.
So you probably heard of Nginx, right, Brian?
I know you don't do a ton of web stuff, but yeah.
Yeah, definitely.
Nginx is kind of like the static front-end server and load balancer thing for many web
apps.
Like on my sites, I have Nginx hitting, like it takes all the requests, does the SSL stuff,
any static resources, CSS, JavaScript, images, that just gets sent straight back.
And only the sort of data-driven stuff makes its way back to the Python web server, which
in my case is MicroWSGI.
And MicroWSGI is really nice.
But the Nginx folks have come up with this thing called NginxUnit.
And so the thing I want to link to is this performance comparison between NginxUnit and MicroWSGI.
So MicroWSGI is written in C++.
It's like one of the best high-performance things that will run and farm out your Python application,
Pyramid Flask, whatever.
And it works really well.
But NginxUnit is a little more flexible.
And for example, you can configure it over a RESTful API instead of just config files.
It'll run multiple languages and versions at the same time, improve TLS support, HTTP2, which is cool.
It'll run Python, multiple versions.
It'll run Go, Ruby, JavaScript, whatever, right?
So it'll run all these things in this one server.
It's not just I'm going to run one flavor of Python.
So anyway, it's pretty cool.
And the thing I wanted to look at was this comparison.
So there's this, I don't know who did it actually, a group that put together sort of a performance analysis
and said we're going to slowly add more and more traffic, concurrent traffic,
to both of these things running more or less a Hello World Flask app, right?
And so pull up the pictures.
And those of you who are listening, there's a little link.
You can pull up the pictures.
And this really tells it all.
Okay.
You got the pictures, Brian?
Yeah.
So if you look at that, there's like a line that's pretty much flat across its NginxUnit
as you go from zero to 500 concurrent users doing 10,000 requests per second.
And it's just kind of like, got it, no problem.
Microwisgee or with or without threads is sort of a linear slope equals one downward trend of performance
as you add more and more traffic.
Like, soon as you get to, you know, a couple hundred users, it just really becomes,
it goes from handling like 7,500 requests to handling 50 per second.
I mean, it really falls over.
So I thought that was pretty interesting.
This whole NginxUnit thing seems like it might be a really powerful and new way to run some nice backing stuff.
Okay.
So the high numbers are better.
You want to keep...
Yeah.
Those are requests per second.
Okay.
Basically.
Yeah.
So it just, once you do 100,000 requests, it goes to zero on Microwisgee where it's still
basically flat on NginxUnit.
So really, really cool.
I think that's quite promising in terms of making Python faster and scale better, which is, you
know, super important because people move to other languages, Go or whatever.
Because like, well, we need this concurrency, like, or you could just run something that
runs it better.
Well, so they have a little note that says it's still in beta, not for production.
Yeah.
It's pretty new.
It's not quite ready.
So my message, my takeaway is I'm going to start paying attention to this thing.
Maybe switch to it at some point, but yeah, don't switch to it yet.
I wonder what version number it is.
It doesn't say.
It's got to be zero something, right?
Yeah, I don't know either what version number it is.
That's a good question.
Okay.
Cool.
Very, very funny.
All right.
Awesome.
You've got something on looping, right?
Trey Hunter, who was on the show last week.
Didn't he do last week?
He was your fill and your stand in, your impersonator last week.
Well, he's got an article, which is a really good read and I'm going to not do it justice,
but it's called Loop Better, A Deeper Look at Iteration in Python.
And, you know, I'm glancing through this.
I'm thinking, you know, I already know how to loop in Python.
But the general, he shows a few gotcha examples of generators used in loops.
And generators are like, for instance, even a list comprehension is a generator.
You can't loop twice.
And if you use containment check, like is nine in my generator, it'll work once and then it
won't work the next time.
But it's not in there anymore.
And your collection's half the size.
And it's a little strange.
And it just behaves weird.
I mean, I don't know if I've ever run into these, but I didn't.
It hurt my head at first trying to figure out.
I didn't know why these weren't working.
So then the article goes on to describe in detail, really, the iterator protocol and what iterators,
iterables, sequences and generators and all that good stuff is.
And then go back and look at those gotchas again and explain with that information why they behave as they do.
And I think this is just a well-written article that'll be going to make you a smarter Python programmer to read it.
Yeah, it's cool.
Definitely covers a lot.
Well done, Trey.
I think this is one of those concepts where if you come from a language that doesn't have generators, this concept of generators, or maybe if you just never really use them, the stuff that comes out of these generators, it looks like you just treat it like a normal collection.
But you're right, they definitely don't behave like normal collections in a lot of ways.
And you can find these subtle bugs.
So nice to have them all covered like that.
Yeah.
And one of the things, I guess I'll go a little bit, is that generators, it's this iterator protocol and you keep it internally in a loop.
Python will call the next operator and then eventually it gets to the end.
There's not a way to reset them.
So they...
Yeah, they're done.
They're done.
And you got to generate...
But you can generate...
However you generate them, you can generate another one.
Yeah, pretty cool.
So the final thing that I want to cover is a little bit like the first one.
It's a bit of a warning, but this is not an automated system like GitHub saying, hey, there's all these repos.
We're going to tell you there's this problem.
It's just something people should be aware of.
So in Django, there's these configuration files and there's this part where you can set debug true or false.
And there's like a little comment by it that says, do not set this to be true in production.
However, do you think everyone goes into it, the big long config file and fixes that before they push it out?
No.
No, they don't.
So the article is called, misconfigured Django apps are exposing secret API keys and database passwords.
That sounds bad.
No.
Yeah.
So it says, researchers have begun stumbling upon misconfigured Django apps that are exposing information like these API keys.
Could be your stripe key, whatever.
In just like a week, they discovered 28,000 Django apps where the admin left the debug mode enabled.
And then, you know, you see, it'll be like screenshots of pulling up just random apps on the internet.
Here's the AWS secret key.
Here's the database password, et cetera, et cetera, just listed in the debug tools.
So that sounds bad, right?
Yeah.
Well, especially you're probably, you probably leave that on while you're developing it so that you can look at all that stuff.
Yeah.
It sounds really bad.
And it pretty much is.
It says, just skimming through a few servers, researchers found debug mode were exposing extremely sensitive information that would allow a malicious actor full access to the app owner's data.
But they were really, I like that they were really clear to emphasize this is not a failure on the Django side.
But in fact, you're just not supposed to do this in production.
And somebody on Twitter was like, it would be so awesome if there was like a comment or like a little note in Django that said, don't put this in production.
And then, of course, right under there's a screenshot of never run this in production in debug mode.
It's not supposedly not Django's fault.
However, I mean, maybe there needs to be more than just on or off.
Maybe there needs to be a I'm debugging my app, but I don't want to expose all the API keys mode or something.
Yeah, for sure.
I think or maybe just the debug stuff is off by default and you have to turn it on.
And the act of turning it on, you go to the section, you read that.
But you might never go and read that part of the config file.
So you just don't know.
Right.
I mean, Django is famous for like getting easy, like just getting stuff up really easy.
I don't have to be a super developer.
So maybe you just don't know.
Right.
Sort of make things worse.
Security researcher Victor Givas said some of these apps running Django have already been compromised.
And he found one server running the Weevily web shell.
That's bad.
I mean, they were somehow able to entirely take over the computer and just SSH into it.
And so he said, I've been notifying server owners about their leaky Django apps.
At the moment, we've reported 1,822 servers.
Well, 143 were fixed.
Not so many, right?
Yeah.
Or taken offline.
Which the taken offline tells me that there's some people out there that just don't know how to do that yet.
So they'll just take it down.
Yeah, there's like, you know what?
My little toy site is not worth getting hacked.
I'm just taking it off.
Right.
Yeah.
Right.
Well, so I guess takeaway, if you're running Django site, make sure it's not in debug mode.
Or you could be a statistic.
Don't be a statistic.
Yes.
Don't be a statistic.
All right.
That's it for our official six items.
Brian, you got anything else?
Yeah.
I just got ping today to tell me that in episode 70, we covered Wagtail, which is a CMS written in Python.
But the Wagtail team is trying to get some new features out.
And they're running a Kickstarter campaign to try to fund that.
So I think it's a good thing.
They're not looking for that much money.
So if everybody pitches in a little bit, it'd be good.
So we've got a link.
Yeah, they're pretty close to their goal, right?
They've got 10 days left.
They're about halfway there.
They should get there, hopefully.
Yeah.
Wagtail is one of the really nice CMSs that's based on Django.
Hopefully, if it's a bug mode, equals false.
Yeah.
Pretty nice stuff.
So yeah, if you care at all about Wagtail or the CMSs, go in there and help them out a bit.
I wanted to mention I've had a lot of great feedback on testing code.
I've been doing kind of a series of getting an open source project out.
And all of the sort of the testing requirements around it and talking about some of the common
test design patterns.
And that's been going well.
And I've actually been learning a lot about running an open source.
I thought, you know, lately I've just been using GitHub for just like a revision control.
But actually running an open source project, even if it's just got a couple of contributors,
you learn a lot.
So hopefully I'll get some of those learnings written up sometime soon.
You definitely should.
That's a really cool project you're doing.
So keep it up.
Yeah.
You got any news?
No news right now.
Nothing to report, but I'm always working on new projects.
I will let you know soon.
All right.
Well, thanks a lot for today.
Yeah, you bet.
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.