Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 111, recorded January 4th, 2019.
I'm Michael Kennedy.
I'm Brian Okken.
Hey, Ryan. Can you believe it's 2019?
Yeah, it's kind of hard to remember to say that.
Yeah, it's going to take a while.
So before we get into the topics, I just want to say thank you to Datadog,
they're sponsoring this episode.
Check them out at pythonbytes.fm/datadog.
More about that later.
I never really enjoy the built-in logging in Python.
It's never seemed like super, super clear to me.
So I've ended up using other packages, something like logbook or something like that,
or maybe just a print statement.
But what you found today, Brian, is pretty sweet, actually.
It might convince me to stop using logbook and use something else.
You know, I was playing with this morning.
So what we're talking about is, I think it's logguru.
I think that's how you pronounce it.
L-O-G-U-R-U.
All right, like log and guru smushed together, joined by the G.
Yeah.
Or it could be logguru.
Logguru.
I don't think so.
I'm going with logguru.
And the tagline is, Python logging made stupidly simple.
And I think this is, it's like a one API function for the most part.
So the built-in logging for Python, it does a lot.
And you can have like multiple, multiple logging entry points and multiple logging output points and everything.
And logguru kind of took the model of everything gets logged to all the places.
And there's a default place that's standard error.
And that's better than print mucking up your standard output.
And by default, it just, you know, just a few lines of code and it works just fine.
You can just say from logguru, import logger.
And just use the logger and say like debug or info or whatever.
But then if you want to do more advanced things, like one of the things I had to play with because I couldn't believe it was this easy, was file logging and log rotation.
So let's say you're logging some stuff and you want to be able to store it into, log it into a file.
And then at some point, like make that a new file, like a date stamped file or time stamped or something.
And it just has that really easy.
And then you can give it different options for if your file gets to like 50 megabytes, at that point, start a new file.
And there's even like compression.
So when you're rolling over to the new one, take the old one and zip it.
Or you can time it and just do a new log every hour or a new log every day.
I love the zipping aspect.
That's awesome.
It just does that automatically or do you have to tell it to?
You have to tell it to.
It's a fairly simple, easy thing.
And one of the bonuses of this package is the readme on GitHub is kind of a tour of all the features with examples.
So it's really easy to pop through and see what's going on.
I mean, I really spent like just a few minutes trying it out and I already love it.
So I think of this as the logging API that fits in my brain and I can do things right off the bat.
It's cool.
Yeah, that's super cool.
On one of my websites, I had like a bunch of logging happening and I went and checked it out, checked out the log directory.
And it was like five gigs of text files.
But they compressed down to like 200 megs or something totally manageable.
So that's pretty awesome that you can have it kind of do that step for you in the background.
A couple of things strike me really as nice here.
One is the use of color.
It'll print out like here's the time, here's the log level, like info or error or whatever, the message and so on.
And it'll actually show those in different colors because by default it prints just to logs to the terminal, right?
Standard out or something like that.
Yeah.
And it looks really nice.
So I tried it both on it just to make sure it was cross compatible and stuff like that.
I tried it both on a Mac and on a Windows machine.
And then I also tried it if I'm logging stuff from and running it within PyCharm, how does that look?
And all of this looks really good still.
That's awesome.
And it also has the ability to wrap functions and catch the unhandled errors.
So the syntax is like log or dot catch all or something.
It's a decorator.
And if there's an error, it'll print a colorized, properly indented, formatted traceback.
Yeah.
And then it has some traceback options too.
And the traceback options are even pretty cool.
They like blow it up into these little mini graph.
And you can specify how deep, how like just the traceback for the function that they got hit or its parent or how many parents.
That's pretty cool.
Yeah.
One of the things I like about the honesty of here is the last feature is crossed out.
The last feature says it's 10 times faster than built-in logging.
No, that's crossed out because clearly adding all these features isn't free.
It does cost a little bit of performance.
But there are plans for some of these, some of the things to be critical functions to be implemented and see in the future.
I think it's convenient right away.
One of the things I was always interested about is to how to figure out how to get email notification in some cases.
Like in particular, if you had a critical log error in a critical something, sending off an email to the right person.
I wouldn't know how to do that right off the bat.
But this one apparently works cleanly with the notifiers library to be able to send email.
Yeah.
Notifiers is nice as well.
I think we've covered it before.
One other final thing here is you can actually put color into your statements as well.
So if I want to have like, they've got a little screencast-y GIF thing on the GitHub repo you can just watch.
Like it says, there are several options available.
If you want options to be blue, you put bracket blue, like HTML tags around it.
And it colorizes it.
So I think it's really nice for communicating back what's going on.
Yeah.
I'm sure it does a lot of cool features.
One of the things I like about the API is once you've figured out something, other people will be able to tell what you're doing because it's not confusing to read.
Yeah.
It's very cool.
This might be my new favorite logging library.
Now I have to get over the inertia of actually having my other stuff already working and wanting to switch to it.
That's going to take a while.
But this is cool.
I like it.
Good find.
So we had a pretty big episode back in July.
We had Brett Cannon and Carol Willing on to talk about how Gita Van Rossum had stepped down as the BDFL, the overseer of the Python project.
Still involved as a core developer, but not making all the decisions and taking all the weight.
Right?
Remember that?
Yeah.
Well, things have more or less been on hold, stalled out until they can somehow come up with a group of core developers can come up with a way to govern themselves.
So, for example, Lucas Lange was looking at maybe moving the releases of Python from every 18 months to yearly, which has a bunch of advantages.
But that's a change that has to be decided on.
They had no way to decide things.
So all sorts of stuff like that had just been put on hold.
Well, we've covered the different governance models that were being considered.
The big news this week is Python now has decided that it has a new governance model, and they have decided on which one it's going to be.
Yes.
It's a, yeah.
Finally.
Finally, things can start going.
Now, don't get too excited.
Yeah.
There's a lot of holes left.
There are a lot of holes.
So what has been decided is the governance model.
They still need to decide how the new governance model actually drives Python the project itself.
So there's like a two-step process.
Find out how we're going to make decisions, and then the first decision is how does that new organization manage Python.
So we're like halfway there.
All right.
I think also there's still elections to be who's going to be part of this thing.
So let me give you the rundown by way of Brett Cannon.
So Brett Cannon, also a core developer, has been on the show a couple times, and it's including the one that I mentioned.
And so he did a really nice write-up of what was the problem, where have we been, what were the options, and how did they decide.
So we covered before, like we said, there were seven governance proposals.
One from like, we'll elect a new dictator, a new BDFL, maybe without the FL for life part, down to maybe we'll have like a panel or something like that.
So there's some votes.
The votes were open to all core developers, and they decided we're not going to have other people vote who are not core developers, because this is about the core developers governing themselves.
And why should other people decide how they get governed, basically, right?
They don't have as much skin in the game.
Yeah.
So people who are deciding sort of their own fate voted.
And in the end, the winning one was PEP 8016, which is called the Steering Council.
So from now on, Python will be driven or controlled or led by a steering council, which is very similar to what Django's project organization actually looks like.
They said, Brett said even that some of the language of the PEP here was copied and pasted directly from Django.
Interesting.
Yeah.
So this is a council of five people who will determine how to run the Python project.
So the only thing that they can't decide, they basically have absolute power, this group of five developers.
However, the one thing they cannot decide is how the council is elected.
So they can't go, you know, this council thing in elections, we don't like them.
We're going to get rid of those.
Right.
Other than that, though, they basically have BDFL like powers.
Right.
That's good.
It means basically that Python will not, project will not be leaderless, but it doesn't directly solve how to get the design and things like do we change the release cycle and things like that.
Cool, right?
Yeah.
Right.
So now we got to figure out who the council is.
Yeah.
So the next step is to elect the council.
That'll be done Monday.
So three, three, four days from now, three days.
And that starts on Monday and then goes to January 20th.
And then somewhere around there we'll know.
Actually, no, that's nominations.
The voting starts on Monday, January 21st.
So sometime in February we'll know who, which five people are on the steering council.
How do you feel about this?
I think it's the right, well, not that nobody asked my opinion, but this seems reasonable to me.
Yeah, I agree.
You have a mic.
You get a, that's the power of the mic is you get to just state your opinion, right?
Yeah.
No, I think it's, I think this is totally reasonable.
I think there's a couple of things.
I thought it was really interesting the discussion between having an even or an odd number of people on the council, right?
Because this way there's always going to be a majority.
There could never be a deadlock, right?
Whereas if they had been even, you could have to have like a definitely win over a majority, right?
If there were six instead of five, you always got to get that little extra vote to go through.
But yeah, I think it's, you know, this seems totally reasonable to me.
I think there would have been a lot of value in finding the next BDFL without the FL part, right?
The next leader dictator type.
I think that kind of might've been my favorite, but it's such, it's just such a risky proposition.
Because on one hand, if you get the right person, they can just move quick and it could be awesome.
But if you get somebody who doesn't take it in the right direction or a direction that you think is the wrong direction, like it could really go off the rails.
So this certainly seems like a safe path forward and it's definitely more community driven than it has been in the past.
Yeah.
I don't know if this will slow down.
So one of the things that Brett brought up is they still haven't figured out really how to, how to guide the language itself for language design.
And so, yeah, it'll be interesting to watch how that.
Yep.
And sure will.
So there's a lot of detail in Brett's article, so you should all go check it out.
But it's, it looks like things are starting to move again.
Just that six short months later.
Yeah.
Perfect.
So one of the things you often have to do is work with files and paths and all this kind of stuff.
And I don't know, you tell me, Brian, am I living in the path?
I still, if I got to work with files, import OS, OS.path, I still probably do that just out of habit.
Am I doing it wrong?
You're doing it wrong.
At least according to Trey.
And I agree.
Now, I am with Trey.
So Trey Hunter wrote a blog post called Why You Should Be Using Pathlib.
And it's basically just a fairly convincing argument talking about some of the different benefits of pathlib over OS.path and OS and glob and stuff.
I actually didn't know before reading this.
I didn't know that you could do glob-like stuff with the pathlib.
And recursive globbing.
Yeah, recursive.
I had actually looked for that before because in some, some shells you can do star star to recursively look for stuff.
And you can use star star for, for the glob library or the glob, whatever.
But it's built in.
You can do our glob with, with pathlib.
It's pretty cool.
That's pretty awesome.
Some of the things that are nice about it, he's comparing it to OS path and OS.path.
It's really working.
It's a string library.
It's passing it, figuring out strings that represent paths.
But now we have a more functional, the pathlib uses the path object,
which is a more functional thing that all of the path method, path object methods, return path objects.
So you can chain them together.
Right.
I love the fluent API.
Like you say path and then give it like a directory.
You can say make dir and all nice options like parents equals true exists.
Okay.
So it'll create like the whole directory chain.
It won't fail if it already exists.
Like that is like that right there might convince me to like put my OS.path away.
Yeah.
And also like right off the batty, that shows an example where how do you import OS path and OS?
Do you, do you import all the, all the little pieces from there so that you can have shorter methods?
Or do you just say OS path and you have to say OS path everywhere?
And it makes for kind of unwieldy code.
I copied some of the examples that he had into our show notes.
It's just really kind of a cool thing.
One of the things I didn't realize is that like the, like if you're opening a file, you can say like with open file name as some file object, then you work with it.
It closes automatically.
That all works with a path lib objects now too.
So you can use a lot of the other standard library things just with path lib objects.
Right.
Long as you're on Python three, six or above.
Yes.
Yeah.
Now this is really cool.
I like it.
I definitely like it.
Why wouldn't you be?
Exactly.
Why wouldn't you be?
It would be wrong.
Not as wrong as using legacy Python, but you know, it's okay.
I do know that some of the Linux distributions lag behind a ways.
And you know, if you haven't upgraded that for a while, that could be a reason actually.
But yeah, this is definitely something people should be checking out.
I really like the fluent API, the chaining.
That's cool.
All right.
Now, before we get to the next one, Brian, let me tell you about our sponsor, Datadog.
They've sponsored many of the episodes and they're a big supporter of the show.
So we're really happy to have them back this year.
And they're a cloud scale monitoring platform that brings together metrics, logs, distributed
traces all in one place.
Like one of the big problems you have is, well, I made a request to my web server.
The web server talked to this service.
That server's talked to a database.
Like those all seem like separate things, right?
But if you want to track them all together, right, you can use Datadog for that.
So you can trace clients, including support for auto instrumenting, like automatically tracking
requests through things like Django, Flask, Postgres, and others.
So you get all the tracking across service boundaries, which is pretty sweet for troubleshooting
slow requests and optimizing your Python apps.
So you can start monitoring your environment with a free trial and Datadog will send you a
cool little Datadog t-shirt.
Just go to pythonbytes.fm/Datadog and get started.
Very cool.
Yeah, for sure.
Thank you, Datadog.
Now, this next one is actually a two-in-one sort of thing because there's a new, new-ish,
let's call it new-ish library for visualizing and stuff, mostly around data science and
notebooks.
So we've talked about things like people know about matplotlib and Seaborn and other stuff,
but maybe they haven't heard about Altair.
So Altair comes from Jake Vanderplass and Brian Granger, who are both really big in the data
science space.
And this is a really cool declarative way to visualize stuff in Python.
Have you ever looked at matplotlib and you're like, why do I have to do all these things?
I just want a line on the screen.
There's so many steps, it seems like.
Well, Altair seems to avoid that.
So basically, it assumes that you're working with some sort of Pandas data frame, right?
So it takes Pandas stuff and visualizes it really well.
So for example, if I had a Pandas data frame called cars, I could say chart of cars, mark
points, and just, you know, X in code, X equals horsepower, Y equals miles per hour, and it
colors it based on the origin.
Boom, you get a nice graph.
Like really declarative.
You just state what like your axes are and stuff and it does it.
So that's really, really nice, right?
You said you were actually using it a little bit.
Yeah, actually, we had a project for visualizing our test result data.
And since I knew about this and I get to make calls like that, I said, hey, let's try Altair.
And one of the benefits of it is this data frame model.
So the people working with it have had to learn data frames.
And the result is they're like, hey, we actually working with data frames makes this easier because
we can do a lot of manipulations within the data frame model.
Yeah, that's pretty cool.
They're like, wait, data frames are kind of awesome.
We should use them.
Yeah, definitely.
Yeah, that's really cool.
So that's Altair, which maybe we should spend more time talking about it.
But the other item I want to talk about is Altair recipes from Antonio Piccolboni, who actually
is the creator of Altair recipes.
So the idea is you can create some of these charts, but not all the kinds of charts that
you might want to create are easily one lineable in Altair.
So what he's done is he's created a bunch of helper libraries that will take the data in
the similar way I described before, easily generate the other types of things that you might want,
like a box plot or histograms or things like that.
So there's a whole bunch of different examples of different types of things, you know, auto correlation, box plots, heat maps, histograms, all kinds of stuff.
That's down to just one line again using his code.
So pretty cool.
Yeah, very nice.
Yeah.
So basically, it's like a wrapper around more additional types of graphs.
And I'm linking to a whole bunch of different examples in here.
So in the little section on Altair recipes, just click on the examples and you can go see all the different graphs and whether or not they're helpful.
Ooh, a layered histogram.
A layered histogram.
Isn't that cool?
That's really cool.
Yeah.
And Antonio says it's fully documented, highly consistent API, 90% plus test coverage with a maintainability grade of A.
So very nice stuff.
Do you know how he computes the maintainability grade?
Did you see that?
No, I don't.
I don't either, but I'm really fascinated to figure out what the maintainability grade of my other stuff is.
Maintainability grade.
Yeah, we should look into that.
Yeah, we should definitely look into that.
Antonio, send us a note about how you computed that.
That's cool.
But if you're using, if you're looking for visualization and especially if you're using Altair, check out Altair recipes.
It's on GitHub and it looks pretty cool.
Very cool.
What do you got next for us?
More testing?
More coverage?
Yeah, I've been thinking about testing and I kind of do that a lot.
A couple of fun pytest plugins that were sent to me and I apologize for not remembering who sent these to me, but keep them coming.
I love trying out new things.
The first one I want to show is, talk about is called pytest-Picked, P-I-C-K-E-D.
And the name confused me at first, but after you start using it, it sort of makes sense.
Here's the idea.
You've got a bunch of, you're using GitHub or not necessarily GitHub, any Git repo.
Some Git repo, yeah.
Yeah.
And you're working with a test or something and you really, you know you're going to want to try to run the tests that you have modified.
So Git knows this.
With Git status, you can tell which files are modified.
So this plugin utilizes Git status and allows you to run all of the modified test files in one test suite without having to like specify them or keyword them or anything.
That's pretty cool.
So if I have like a thousand test files, that may be a little excessive, but let's just roll with it.
And I edit three of them since the last time I committed to Git.
I can go run this and it'll say, well, these are the three changed test files.
Therefore, we're going to run just the tests in those three files and pytest.
Yeah.
And you can run just those three or you can run those three first and then the rest of the suite.
Okay.
That's pretty sweet.
You know what I would like, which is probably a much harder problem to solve, but would be awesome, is if you could combine code coverage along with this and sort of reverse it.
Say like, well, these are all the source files and the test files that change.
But the source files that change, what tests touch some line of code in these source files?
So what do I need to run to get coverage on the changes that direction?
That would be awesome.
I think there is something like that, but it was last time I tried it.
It was a little clunky to use, but I'll look it up again.
Yeah.
Okay.
Cool.
But this is really nice.
I mean, certainly if the mode that you're in is I'm changing a bunch of the tests and I want to just run those.
This is awesome.
Yeah.
Well, and the mode for a lot of people developing tests or maintaining software really all together is either writing new tests.
When you're in that mode, you're definitely going to be having modified test files.
Yeah.
Or you're debugging something and you're like throwing some logging in it or something like that in a log in a test.
Yeah.
I definitely see a good use for this.
And you have a two for us.
That's just the one.
Yeah.
So the other one is a kind of a new project, but I thought it was fun.
It's called the pytest Clarity.
pytest dash clarity.
It's just another colorizer.
So it makes the diffs.
So if you have a assert equals comparison that fails, the left and right comparison, sometimes it's a little hard to read.
And this one is a colorizer that puts the changes from the left and right, right on top of each other and colorizes them differently.
So that's nice and helpful.
Yeah, that's cool.
Definitely colors.
Color is awesome.
Right.
It shows you what's different, what's the same.
It's beautiful.
You know, right away.
Yeah.
The one thing I'm in conversation with the person writing this, that it defaultly turns on verbose.
And for small projects, having verbose on, which means that every test file is going to get listed.
Actually, every test is going to get listed in the output.
That's fine for small projects.
But when you get into hundreds and thousands of tests, that can be unwieldy.
Yeah, I can imagine.
But you can turn that off with the dash QQ and the clarity still works.
Cool.
I've got...
Yeah.
Yeah, those are definitely nice testing additions.
Quite cool.
So the last one I want to close out with is a little bit of web security.
And we've talked about web security before on the show, various things like the Django Hunter and stuff like that, for example.
But this one has to do with headers.
Now, did you know that when you have a web app, it obviously exchanges headers and cookies and stuff with the clients.
But there's a whole bunch of things that you should send across, probably, to make your website more secure.
Yeah.
There's like a handful of them.
And the OWASP organization has a place that talks about, these are the headers you should send.
For example, about caching certain pages.
Or if you're setting a cookie, that the cookie should only be exchanged over a secure connection.
So imagine you've got like a site.
Maybe it's a bank.
You can log into it.
If you go to hdpsbank.com or whatever the bank website is, right, it's going to set maybe a login cookie.
But if you open up a browser and you type bank.com and just hit enter, maybe that goes over HTTP and then HTTPS.
But if you don't set the right headers or flags, it could pass that login cookie over HTTP the first time before it goes over to HTTPS.
Things like that.
So you can say only exchange these cookies over secure connections and things like little details like this.
But there's a bunch of them and they're hard to remember.
One of the guys that was actually listening to Talk Python on Flask, where David Lord talked about this thing called FlaskTalesman,
which is a plugin for Flask that will automatically do that kind of stuff.
It'll just take the response, set those cookies, not the cookies, the headers that need to be set and things like that.
So it's really nice that Flask has this option.
He's like, well, but why don't the others?
This security guy, pen tester, he's like, there should be something like this for all of the frameworks.
So what he did was he created this thing, which I'll tell you the package name.
And I can't believe that he got it on PyPI.
The package name is secure.
You think that would be taken by now.
But the idea is it's secure headers and cookies for the Python web frameworks.
It's pretty cool.
It supports AIoHTP, Bottle, Cherry Pie, Django, Flask, Falcon, Hug, Basinite, Pyramid, Court, Responder, Sanix, Starlet, and Tornado.
And if one of those is not on your list, you can actually just sort of feed it the response anyway.
Isn't that cool?
That's actually very cool.
Wow.
So it has built-in integration to those things like Pyramid Tweens or other types of stuff.
You can plug it in so it automatically happens.
But if you don't have it automatically doing it, you can just call the various bits as well.
So it sends things like strict transport security, same origin iframes, cross-site protection, all that kind of stuff.
It just does that automatically.
And you can also create secure cookies.
So you just go to the secure cookie thing and say, I'd like the secure cookie to have this name and this value.
And it'll set that it's over HTTPS only, that it's over HTTP rather than JavaScript only, things like this.
Same site origin, same site stuff.
So all these little details about getting security right are wrapped up and then packaged in a way you can use it cross-framework.
Check that out.
Yeah, it's pretty sweet.
Did you mention Pyramid Tweens?
Is that a 12-year-old using Pyramid?
Well, it's 11 to like early 13-year-old.
No, it's like a layer that you can put in between request response.
And it's like a thing that gets called before and after responses, I believe.
Okay.
Apparently it's not there in your Pyramid class.
Yeah, I guess not.
And I don't think I really talked about it there.
But you can basically plug it in and say, anytime you send a response, call this function.
And so you can just in that function say, upgrade the response to have the secure headers in the response without doing it all over the place.
You just plug in this one little bit.
Okay, cool.
Yeah, it's pretty cool.
So if you're doing a web map and you care about security, this is definitely worth checking out.
All right, well, that's it for all of our items that we're officially covering.
I have some extras.
How about you?
I don't, actually.
Other than I've been podcasting away and I got like seven episodes of Test and Code in December.
That's awesome.
I've been listening to a lot of them.
You've got some good stuff going on lately.
And I'm going to keep it up.
I'm not going to do seven in January, but there should be four.
Yeah.
Awesome.
I'm really glad to see that coming along.
So I have, it's good you don't have many because I have a bunch.
So I'll go through them kind of quick.
But there was this pretty big bug that came out about SQLite.
SQLite is an embedded database that runs in process.
That happens to be shipped and included in Python.
So that got my attention, but it's also included in the browsers for like Web SQL stuff that JavaScript can use and it can be embedded in like Electron JS apps for the same reason.
Stuff like that.
Right.
So it's really a lot of places.
Now, the problem is it turns out that there is a bug in SQLite that with simple SQL select commands, you can do very bad things to anything that runs the SQLite that is vulnerable.
And this was just really recently.
All right.
So it seemed like this could have been a really big problem in Python since Python has SQLite.
SQLite has this problem.
And it would have had to been the case that there was some SQL injection, right?
Like you took user input and you fed it to SQLite directly.
Yeah.
Right.
So that's already there have to be kind of a problem in your code for this to happen.
But it turns out I threw this out on Twitter and some folks came out there and really like, you know, a lot of people shared it.
A lot of people talked about it.
And somebody said, you know, actually, that's an interesting thought.
M.
Boris on Twitter is like, you kind of got me curious that maybe this is a problem for Python.
Let me check.
So he took the proof of concept exploits and ran it against SQLite and Python.
And it looks like it's not a problem.
That's pretty good, right?
So if you hear that there's this big problem with SQLite, it seems like it's not a problem with Python.
But that's not for sure.
But it seems that way.
And also don't take user input and throw it into a query.
Yeah, exactly.
It's already like in order for this to be a problem for your Python app, you already have to have a problem.
This just makes it worse.
So if this was going to be a problem before, you should probably deal with that regardless.
All right.
So next one.
This is a follow up on our AI and health care.
We talked about AI and the AI analyzing cancerous mammograms and helping doctors get much better at that.
And we were speculating, maybe I was speculating, that maybe there won't be a need for doctors.
We'll just upload it to the cloud doctor and we get an answer, right?
Things like that.
Hey, Google, do I have cancer?
Exactly.
Send us three pictures.
I'll tell you.
Well, this guy named Bradley sent us feedback.
He says, hey, I really found this interesting.
I'm a data scientist at the National Oncology Program.
And I work directly with clinicians.
And it's my strong opinion that AI cannot take the job from the medical folks, the MDs.
However, it will make it way more efficient for all the low hanging fruit.
He says, you know, look, health care is both science and an art.
And the AI is going to have a really hard time on the art side of things.
Also probably the human interaction side of things.
So really doesn't think that there's a big danger of that.
Well, you know, I guess time will tell, but he's definitely got a lot more to go on than I do, right?
He works as a data scientist with these folks.
So that's cool.
Got some inside feedback.
Yeah, that's pretty much what we were speculating anyway.
I mean, it's not something you can break down into an algorithm.
Yeah, for sure.
Next item really quick, Python 3.7.2 is out.
So be sure to get the latest Python 3.7 if you're trying to run that.
And if you're running homebrew, you can just do brew update and brew upgrade.
And you'll have Python 3.7.2, which is pretty awesome.
Neat.
Yeah.
So I'm already running that on my local machine, but not yet in production.
It's not on the right Linux version yet.
And then finally, I launched a new course, Brian.
Yeah, I'm excited about this.
Yeah, so this is one written by Matt McKay of Full Stack Python, and it's Introduction to Ansible.
So that one's been coming along for a long time, and he finally got it out.
It's really good, and I'm learning a lot about all sorts of things, also including Ansible.
So if you're interested in Ansible, check it out over at training.talkpython.fm, or just click the link.
Nice.
Did you come with a joke this time?
I did not.
Do you have a joke for us?
Well, luckily, I found a joke.
And by found a joke, I mean Joachim sent us a joke, one of our listeners, and I'll tell it to you.
Okay.
Okay, so hold on.
Got to zoom in.
Fonds are small.
Eyes are old.
So an engineer, a physicist, and a programmer were discussing what was the oldest profession of the three.
Engineers, look, all the matter engineered into amazing constructs like stars, galaxies, planets.
So obviously engineering.
The physicist says, before there were planets, the matter had to be made from chaos.
Physics is responsible for all the quarks, gluons, photons, and electrons.
Not to be outdone.
The programmer says, aha, but where do you think the chaos came from?
Yeah, that's good.
Yeah, pretty good.
So definitely, I'm sure we've all caused a little bit of chaos out in the world with our apps.
That's a good one.
Not to like, we should be done now.
But I just remembered another thing.
Okay.
Speaking of chaos, is like, in 2019, more and more browsers were saying, let's just try to have all websites be secure.
So I got hit by this.
And Python testing.net is not, doesn't have SSL on it, but it's just warning everybody.
By the way, like Brian might steal your information.
I'm not going to do anything with your information.
Let me see.
I pull up.
Oh my goodness.
I got to get out of here, man.
This is not secure on it.
Yeah.
What up?
So I could just buy an SSL certificate or whatever, do the free one, and jump through that hoop.
But I felt like it'd be a good time to change it anyway.
So I'm going to start the process of turning this into a static site generated site.
Oh, you are?
Okay.
Awesome.
Well, that sounds really fun.
And that'll be, I know some good sites that definitely run that way.
So that'll be good.
Yeah.
Okay.
That's all I got.
Well, even though it says not secure, I'm still going to go there.
It's okay.
Okay.
All right.
Well, great to chat with you as always, Brian.
Yeah, you too.
Yep.
Thanks.
Bye.
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.