Brought to you by DigitalOcean - grab your $50 credit and deploy your first project for free


« Return to show page

Transcript for Episode #111:
loguru: Python logging made simple

Recorded on Friday, Jan 4, 2019.

0:00 KENNEDY: Hello, and welcome to PythonBytes, where we deliver Python news and headlines directly to your earbuds, this is Episode 111, recorded January 4th, 2019. I'm Michael Kennedy.

0:12 OKKEN: And I'm Brian Okken.

0:12 KENNEDY: Hey, Brian, can you believe it's 2019?

0:14 OKKEN: Yeah, it's kind of hard to remember to say that.

0:16 KENNEDY: Yeah, it's going to take awhile. 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. Never really enjoyed the built-in logging in Python. It's never seemed 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.

0:46 OKKEN: You know, I was playing with this, this morning, so what we're talking about is, I think it's Loguru, I think that's how you pronounce it, L-O-G-U-R-U.

0:54 KENNEDY: Right, like log and guru smushed together? Joined by the G?

0:58 OKKEN: Yeah, or it could be Loguru.

0:58 KENNEDY: Loguru?

1:00 OKKEN: But I don't think so.

1:01 KENNEDY: I'm going to go with Log Guru.

1:02 OKKEN: 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 multiple logging entry points and multiple logging output points, and everything, and Loguru 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, just a few lines of code and it works just fine. You can just say from Loguru, import logger, and just use the logger and say 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 'cause 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 log it into a file, and then at some point 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 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.

2:29 KENNEDY: I love the zipping aspect, that's awesome. It just does that automatically or do you have to tell it to?

2:34 OKKEN: 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 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 right off the bat. It's cool.

3:01 KENNEDY: Yeah, that's super cool, on one of my websites I had 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 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, 'cause by default it prints, it logs to the terminal, right? Standard out or something like that.

3:40 OKKEN: Yeah, and it looks really nice, so I tried about that, just to make sure it was cross compatible and stuff like that. I tried it both on 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.

3:56 KENNEDY: That's awesome, and it also has the ability to wrap functions and catch the unhandled errors, so the syntax is like logger.catchall or something. It's a decorator, and if there's an error it'll print a colorized, properly indented, formatted traceback.

4:13 OKKEN: Yeah, and then it has some traceback options too, and the traceback options are even pretty cool, they'll blow it up into these little mini-graph, and you can specify how deep, just the traceback for the function that it got hit, or its parent, or how many parents. It's pretty cool. One of the things I like about the, the honesty of here is the last feature is crossed out. The last feature says it's 10 times faster than built-in logging and then 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 how to figure out how to get email notification in some cases, like in particular, like if you had a critical log error and 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, it works cleanly with the notifiers library to be able to send email.

5:21 KENNEDY: 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, GIF thing on the GitHub Repo, you can just watch. It says there are several options available. If you want options to be blue you put

5:47 OKKEN: 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.

5:57 KENNEDY: Yeah, it's very cool. This might be my new favorite logging library. Now I have to get over the inertia of actually having that other stuff already working and wanting to switch to it. That's going to take awhile, 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 Guido 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? 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 is 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.

7:12 OKKEN: Yes, it's a, yeah.

7:12 KENNEDY: Finally. Finally, things can start going. Now, don't get too excited.

7:18 OKKEN: Yeah, there's a lot of holes left.

7:20 KENNEDY: 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, 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 the aclusion of the one that I mentioned, and so he did a really nice writeup of what was the problem, where have we been, what are the options, and how they decided. So we'd covered before, like we said, that there was 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 was 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. So, people who were 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. Brett said even that some of the language of the PEP here was copy and pasted directly from Django.

9:00 OKKEN: Interesting.

9:00 KENNEDY: 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 and 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, the 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?

9:42 OKKEN: Yeah, right, so now we got to figure out who the council is.

9:46 KENNEDY: Yeah, so the next step is to elect the council. That'll be done Monday, so 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 the nominations. The voting starts on Monday, January 21st, so some time in February we'll know who, which five people are on the Steering Council.

10:08 OKKEN: How do you feel about this? I think it's the right, not that I, nobody asked my opinion, but this seems reasonable to me.

10:14 KENNEDY: 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? No, 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 can never be a deadlock, all right, whereas if they had been even, you could have to have like a, definitely a win-over 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 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 have 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, 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.

11:27 OKKEN: 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 guide the language itself, for language design, and so yeah, it'll be interesting to watch how that.

11:42 KENNEDY: Yep, it sure will. So there's a lot of details in Brett's article, so you should all go check it out, but it looks like things are starting to move again, just six short months later. 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?

12:09 OKKEN: You're doing it wrong. At least according to Trey, and I agree now. I am with Trey, so Trey Hunner 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.

12:35 KENNEDY: And recursive globbing.

12:37 OKKEN: Yeah, recursive, I had actually looked for that before because in some shells you can do ** to recursively look for stuff, and you can use ** for the glob library, or the glob whatever. But it's built in, you can do rglob with pathlib. It's pretty cool.

12:55 KENNEDY: That's pretty awesome.

12:57 OKKEN: 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 and 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 methods, Path object methods return Path objects, so you can chain 'em together.

13:22 KENNEDY: Right, I love the fluent API. You say Path and it give it like a directory, you can say, mkdir, and all nice options like parents=True, exist_ok, so it'll create the whole directory chain, it won't fail if it already exists. That right there, might convince me to like put my os.path away.

13:42 OKKEN: Yeah, and also right off the bat, he shows and example where, how do you import os.path and os, do you import 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 if you're opening a file and say like, with open(file_name) as some_file_object: then you work with it, it closes automatically, that all works with pathlib objects now too so you can use a lot of the other standard library things just with pathlib objects.

14:31 KENNEDY: Right, long as you're on Python 3.6 or above.

14:33 OKKEN: Yes.

14:35 KENNEDY: Now this is really cool, I definitely like it.

14:37 OKKEN: Why wouldn't you be?

14:38 KENNEDY: Exactly, why wouldn't you be? It would be wrong, not as wrong as the Legacy Python but you know it's okay. I do know that some of the Linux distributions lag behind a ways and if you haven't upgrade that for a while that could be a reason actually. This definitely something people should be checking out, I really like the fluent API and the chaining, that's cool. 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 support 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 metric logs, distributed traces all in one place. Like one of the big problems you have is I made a request to my web server, the web server talked to this service, that service talk to a database. Those all seem like separate things, but if you want to track them all together, you can use Datadog for that. You can trace clients, including support for auto instrumenting, like automatically tracking request 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.

15:57 OKKEN: Very cool.

15:58 KENNEDY: Yeah, for sure, thank you Datadog. Now, this next one is actually a two in one sort of thing, because there's a new, newish, let's call it newish library for visualizing stuff, mostly around data science and notebooks, so we've talked about things like matplotlib and Seaborn and other stuff but maybe they haven't heard about Altair. So Altair comes from Jake Vanderplas 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 like matplotlib and your like, "Why do I have to do all these things? I just want a line on the screen." You know, there's like 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. It take's Pandas stuff and visualizes it really well. So for example, if I had a Panda data frame called cars, I could say, chart of cars markpoints and x encodes x equals horsepower, y equals mass per gallon and it colors it based on origin and boom you got a nice graph. Like really declare, if you just state what your axis are and stuff and it does it. So that's really really nice, right? You said you're actually using it a little bit.

17:11 OKKEN: Yeah, I actually, we had a project for visualizing your test result data and since I knew about this, and I get to make like 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, wait, actually working with data frames makes this easier because we can do a lot of manipulations within the data frame model."

17:41 KENNEDY: Yeah, that's pretty cool, they're like, "Wait data frames are kind of awesome, we should use them."

17:44 OKKEN: Yeah, definitely.

17:45 KENNEDY: That's really cool. So that's Altair, which mean 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 linable in Altair. So what he's done, 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 boxplot or histograms or things like that, so there's a whole bunch of different examples of different types of things auto correlation, boxplots, heatmaps, histograms, all kinds of stuff that's down to just one line again using his code so, pretty cool. 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 I'll share recipes just click on the examples and you can go see all the different graphs and whether or not they're helpful.

19:00 OKKEN: Ooh, a layered histogram.

19:02 KENNEDY: Ain't that cool?

19:03 OKKEN: That's really cool.

19:04 KENNEDY: 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?

19:17 OKKEN: No I don't.

19:18 KENNEDY: I don't either but I'm really fascinated to figure out what the maintainability grade of my other stuff is.

19:22 OKKEN: Maintainability grade, yeah we should look into that.

19:24 KENNEDY: 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 your looking for visualization and especially if you're using Altair, check out altair_recipes, and it looks pretty cool. What do you got next for us? More testing? More coverage?

19:39 OKKEN: Yeah, I have 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.

20:13 KENNEDY: Some git repo yeah.

20:14 OKKEN: Yeah, and you're working with a test for 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 were modified so this plugin utilizes git status and allows you to run all of the modified test files in one test sweep without having to like specify them or keyword them or anything.

20:38 KENNEDY: 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 will say well these are the three changed test files, therefore, we're going to run just the testing of those three files in pytest?

20:57 OKKEN: Yep, you can run just those three or you can run those three first and the rest of the sweep.

21:02 KENNEDY: 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 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.

21:31 OKKEN: 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.

21:37 KENNEDY: 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.

21:45 OKKEN: 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 a lot of test files or you're debugging something and you're like throwing some logging, or something like that in the test.

22:06 KENNEDY: Yeah, I definitely see a good use for this. And you have a two first, that's just the one.

22:09 OKKEN: Yeah, so the other one is, kind of a new project but I thought it was fun, it's called the pytest-clarity, pytest-clarity, it's just another colorizer so it makes the diffs. If you have 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 left and right, right on top of each other and colorizes them differently so that's nice and helpful.

22:41 KENNEDY: Yeah, that's cool, definitely in colors. Colors are awesome. Right, shows you what's different, what's the same. It's beautiful, you know right away.

22:47 OKKEN: Yeah, the one thing I mean, 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.

23:10 KENNEDY: I can imagine.

23:12 OKKEN: But you can turn that off with a -qq and the clarity still works.

23:18 KENNEDY: 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. 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 for to make your website more secure. 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 https://bank.com or whatever the bank website is, its going to send maybe a logging 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 logging cookie over http the first time before it goes over to https. Things like this, 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 Flask-Talisman, which is the plugin for Flask that will automatically do that kind of stuff, it will 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 a 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 what it is, it's secure headers and cookies for the python web frameworks. It's pretty cool, it supports aiohttp, Bottle, CherryPy, Django, Flask, Falcon, hug, Masonite, Pyramid, Quart, Responder, Sanic, Starlette and Tornado. And if one of those is not in your list, you can actually just sort of feed it the response anyway. Ain't that cool?

25:46 OKKEN: That's actually very cool, wow.

25:48 KENNEDY: So it has built-in integration to those things like Pyramid Tweens or other types of stuff you can like 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 all said 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 the security right, are wrapped up and then packaged in a way you can use it cross framework.

26:34 OKKEN: Yeah, I should check that out.

26:35 KENNEDY: Yeah, it's pretty sweet.

26:36 OKKEN: Did you mention Pyramid Tweens? Is that a 12 year old using Pyramid or?

26:41 KENNEDY: Well, it's 11 to like an early 13 year old, no it's like a layer that you could put in between request response and it's like a thing that gets called before and after responses I believe.

26:53 OKKEN: Okay, apparently I'm not there in your Pyramid class.

26:55 KENNEDY: 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 and the response without doing it all over the place, right? You just plug in this little bit.

27:12 OKKEN: Okay, cool.

27:13 KENNEDY: Yeah, it's pretty cool. So if you're doing a Web app and you care about security this is definitely worth checking out. Right, well, that's it for all of our items that we're officially covered, I have some extras. How about you?

27:25 OKKEN: I don't actually other than I've been podcasting away and I got like seven episodes of Testing Code in December.

27:33 KENNEDY: That's awesome, I've been listening to a lot of them, you got some good stuff going on lately.

27:37 OKKEN: And I'm going to keep it up, I'm not going to do seven in January but there should be four.

27:40 KENNEDY: Yeah, awesome, I'm really glad to see that come along. So I have a, it's good you don't have many 'cause 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 and 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 that can be embedded in like Electron JS apps for the same reason, stuff like that. It's really a lot of places. Now the problem is, it turns out that there is a bug in SQLite that was simple SQL select commands, you can do very bad things to anything that runs the SQLite that is vulnerable. This was just really recently so it seem like this could've been a really big problem in Python since Python has SQLite, SQLite has this problem and it would've had to been the case that there were some SQL injection like you took user input and you fed it to SQLite directly. 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, a lot of people shared it, a lot of people talked about it and somebody said, you know, actually that's an interesting thought and Borus on Twitter's 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, sounds pretty good right? So if you hear that there's this big problem with SQLite, seems like it's not a problem with Python but that's not for sure but it seems that way,

29:24 OKKEN: And also don't take user input and throw it into a query.

29:28 KENNEDY: 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 do all that regardless. Next one, this is a follow up on our AI and healthcare. 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.

30:02 OKKEN: Hey Google, do I have cancer?

30:03 KENNEDY: Exactly, send us three pictures, I'll tell you. Well, this guy named Bradley sent us feedback, 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." Says you know look healthcare is both science and an art and AI's going to have a really hard time on the art side of things, also probably the human interaction side of things. Bradley didn't think that there's a big danger that, well, I guess time will tell but that's, he's definitely got a lot more to go on than I do. He works as the data scientist with these folks so that's cool, got insight feedback.

30:50 OKKEN: Yeah, that's pretty much what we were speculating anyway, I mean it's not something you can break down into an algorithm.

30:55 KENNEDY: 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 home brew you can just do a brew update and a brew upgrade and you'll have Python 3.7.2 which is pretty awesome.

31:12 OKKEN: Neat.

31:13 KENNEDY: 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.

31:23 OKKEN: Yeah, I'm excited about this.

31:24 KENNEDY: Yeah, so I, this is one written by Matt Makai, a 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. Did you come with a joke this time?

31:47 OKKEN: I did not.

31:48 KENNEDY: Do you have a joke for us? Well luckily I found a joke, and by found a joke I mean a listener sent us a joke, one of our listeners and I'll tell it to you. Okay, so, hold on, got to zoom in, fonts are small, eyes are old. So, an engineer, a physicist and a programmer were discussing what was the oldest profession of the three. The engineer said, "Look all that 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 out done, the programmer says, "Aha but where do you think the chaos came from?"

32:33 OKKEN: Yeah, that's good.

32:34 KENNEDY: 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.

32:43 OKKEN: Not to like, we should be done now, but I just remembered another thing. 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 pythontesting.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.

33:09 KENNEDY: Let me see, I pull up. Oh my goodness, I got to get out of here man, this is not secure on it.

33:16 OKKEN: Yeah, what up? So I could just buy a SSL certificate or whatever do the free one and then 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.

33:32 KENNEDY: 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 yeah that'll be good.

33:41 OKKEN: That's all I got.

33:42 KENNEDY: Well, even though it says not secure I'm still going to go there, it's okay. Alright, great chat with you as always Brian.

33:49 OKKEN: Yeah, you too.

33:50 KENNEDY: Yeah, thanks.

33:50 OKKEN: Bye.

33:51 KENNEDY: Thank you for listening to PythonBites, follow the show on Twitter via @pythonbytes, that's PythonBytes 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 look out for sharing something cool. On behalf of myself an Brian Okken, this is Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page