00:00 Michael Kennedy: Flask is now eight years old, and until recently, had been going along pretty steady state. It had been hanging around at version 0.11 and 0.12 for some time. After a year-long effort, the web framework has now been updated to Flask 1.0. David Lord is here to share the big news with us. He's the maintainer of Flask, and we dive into the new features, as well as the future directions of Flask, with him. This is Talk Python To Me, Episode 177, recorded August 30th, 2018. Welcome to Talk Python To Me, a weekly podcast on Python: the language, the library, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy, keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via @talkpython. This episode is brought to you by Linode and 10x Agent On Demand. Please check out what they're offering during their segments, it really helps support the show. David, welcome to Talk Python.
01:10 David Lord: Hello, thanks for having me.
01:11 Michael Kennedy: Yeah, it's great to have you here. It's really good to see lots of vibrant activity around Flask, and I know you're at the heart of much of this activity, and I'm super excited about diving into it with you.
01:23 David Lord: Yeah, let's get started.
01:24 Michael Kennedy: Yeah, for sure, and so we're going to dive into Flask and the news that Flask 1.0 is now out, that's a big deal, but let's get started with just your background. How'd you get into programming in Python?
01:33 David Lord: Let's see, I've been programming most of my life. I got into it probably around like second grade or so, a book about HTML, started making websites.
01:42 Michael Kennedy: Nice.
01:43 David Lord: Where I really started, and what I thought I wanted to do, and I think this is the story for a lot of people, is I thought I wanted to make video games when I grew up, 'cause I started with Game Maker when I was in like middle school and everything, making 2D games that I wish I had saved now, but I didn't know about Git back then.
02:03 Michael Kennedy: So they faded into the digital dust?
02:05 David Lord: Yeah, unfortunately. So, yeah, I got started that way and then went to college for computer science, and eventually just settled on, "Oh, web apps are pretty cool." I started making some small things for groups I was involved with, and eventually, that's how I got into Python also. There was a Python course in college, but even before that, I started thinking, "Hmm, what can I do next, 'cause I'm just doing Java here and it's not that exciting." So I went one summer and I was looking at how to make a web application, and I came across Ruby On Rails and Django. So I looked at both of them, two very different directions I could have gone.
02:45 Michael Kennedy: I'd say looking at the growth curves and popularity curves of these two languages 10 years out or whatever, you probably got a good choice on the fork in the road there.
02:54 David Lord: Yeah, I mean, I'm sure there's plenty of good stuff you can do with Ruby also, but back when I was starting, I looked at both of them, looked at the code and said, not knowing Python or Ruby, "Hey, I can read this Python. It makes sense." So I just started using that. Picked up the Django tutorial back when I think it was 0.8 or so, and I think Flask may have just come out or was going to come out the next year. So it was 2008, 2009, around that. That's how I got started, and just kind of went from there.
03:26 Michael Kennedy: Yeah, that's awesome. So, I guess one of the interesting follow-up things is how'd you go from Django to Flask? I just interviewed some folks for the Python survey down at the PSF, and Jetbrains collaboratively, and the number-one framework, the most popular framework that anybody picks up for anything in Python is Django. So it's certainly really popular. So, you've strayed from Django, how'd you get over to Flask?
03:53 David Lord: It's funny, I want to touch on those most popular things also, I don't want to start a fight with Django or anything, but we'll go into how I did Flask first. So, for my job after college, I got put on a contract where it's just basically open-ended. This is literally the line I got the first day I walked into the client's office, was, "We have this spreadsheet. Can we put it online?"
04:18 Michael Kennedy: An Excel spreadsheet?
04:20 David Lord: The company I was working at, and I still work for them, they were a Java shop, and that's what my previous projects had been in, but I was the only person on this contract over at the client's office, and I said, "Yeah, we can put that spreadsheet online in Django, which I was learning before I started here." And I did it before anybody could say anything.
04:42 Michael Kennedy: You know, the best way to quiet dissenting voices in those situations is to show them something working. They're like, "Ah, you shouldn't, you should use Java; wait, that works? You're already done? Okay. Well, I guess, alright, fine, you can do that," right? Did it go something like that?
04:58 David Lord: By the time they checked in a couple weeks later, we already had a working prototype and we'd gone beyond the spreadsheet at that point.
05:06 Michael Kennedy: Had they been using the spreadsheet almost like a webapp database, were they mailing it around? What was the story?
05:14 David Lord: I don't know how many details I want to give publicly.
05:17 Michael Kennedy: Yeah, yeah, sure, no problem.
05:18 David Lord: It was basically, they were keeping track of how secure their computers were for various audits that they needed to do, and everybody was just basically recording about their computers and somebody was filling out a spreadsheet, and then they would go and look at the statistics every now and then. They wanted some way people can report that automatically, they can get the reports about compliance automatically, just data collection and reporting.
05:46 Michael Kennedy: Yeah, I asked because it seems like there's just so many holes like that that Excel fills, that with just a little bit of skill, a much better solution would be in place.
05:57 David Lord: Yeah, well, the contract ended up lasting three years and far outgrew what Excel would have ever have done, but it started from pretty humble beginnings.
06:06 Michael Kennedy: Nice. Okay, so that's Django, so how'd you get to Flask?
06:09 David Lord: Right, right. So I run Django, so we made this prototype, and it was working well, and they were like, "Well, we want to start using this for the company now." We deployed it, and it ended up being too slow. Now, I'm not saying Django's too slow. That's probably partially on me. I was still learning and everything, but at the time, it was a SQLLite database, the templates were slowing down in rendering, and the biggest problem was the ORM at the time. I know you can do clever things even in the Django ORM, but I was trying to do all these reports and aggregates and everything, and it was kind of fighting Django. So, I started looking for something, alternatives; I found SQLAlchemy, and I found Flask, which SQLAlchemy was used with a lot. So I said, "Okay, I'm just going to rewrite the whole thing in Flask and see what happens." That's about how it happened, I just had a Django site and I needed more performance, and more customizability, so I switched to Flask.
07:10 Michael Kennedy: Yeah. Was it pretty easy? Was it a couple days?
07:13 David Lord: This was six years ago now, but yeah, it was pretty straightforward. And like I said, I think I probably could have accomplished the same thing in Django, eventually. I knew a lot less at the time also, so I was more just exploring what was out there. But we built something on it for three years after that.
07:30 Michael Kennedy: Yeah, so it was a really good foundation in the end, huh? I'm a fan of the micro-framework style. A small web framework, pick the ORM and other tools that you want to use for that situation, and put them together. I don't know, that's my style, so I'm a fan of that style as well.
07:47 David Lord: Yeah, I'm not biased or anything, but I'm definitely a fan of that also.
07:51 Michael Kennedy: For sure. Yeah. So, we're going to talk a lot about Flask, but let's start a more higher level, umbrella style angle here. When I went to look about Flask, it's now under this Pallets Project umbrella, and a couple years ago, I don't think it was. So, what is Pallets, and how did Flask get there?
08:16 David Lord: Pallets is, it's basically the new organization that's managing Flask and the other projects related to Flask, so, Werkzeug, Jinja, Click, MarkupSafe, Itsdangerous. There was a previous organization called Pocoo, which your listeners are probably familiar with, because when you go to the Flask documentation, you're still going to flask.pocoo.org.
08:42 Michael Kennedy: That was Armin Ronacher's stuff, right?
08:44 David Lord: It was him and some of his friends; they had started various projects and Flask came out of that, Sphinx came out of that, other projects came out of it that I'm not remembering off the top of my head, but everybody just ended up moving on eventually. So it had become just Armin managing all these projects himself, and he wanted to open it up more to the community, so he created this new Pallets website and said, "Okay, everything belongs to this organization now, I'm going to try to get more community involved." That's about the same time that I got into the project as well. Honestly, we haven't really picked up a lot more maintainers since then or anything, it's still just a couple maintainers going at things, but it was more of a significant, it's-not-Armin's-project-anymore thing.
09:33 Michael Kennedy: Right, I was going to say, it kind of got Flask out of the shadow of Armin.
09:37 David Lord: Right, and he's still there, like I chat with him about, "Hey, do we want to do things like this?" or he still manages a lot of the assets behind the scenes, like servers and that sort of thing, but day-to-day, it's me and the contributors that I have gotten on board.
09:53 Michael Kennedy: Right, right. Are you looking for more contributors?
09:56 David Lord: Absolutely. I don't know if you want to go and jump on that now.
10:01 Michael Kennedy: Yeah, sure, let's talk about it just a little bit, because I know a lot of listeners will reach out to me and say, "Hey, I'm getting into open-source, and I'm getting into this whole Python world, and I would like to contribute to something." but I feel like they contemplate creating something for themselves, and they're like, "Well, I could build this thing, but I don't really have a great use case for it." or, "I'm not sure it'll be popular." and then they look at contributing to other projects. We talked about Django, Django's really a big, polished project that is super-hard unapproachable for people to get into. So they're like, "I can't get into these major projects 'cause they're too advanced or too widely used." whereas the small, simple stuff, "I don't think is going to make a lot of sense." so they ask, "Well, what projects could I get involved with, and where can I help out?" So, if there's a good place for people getting started, or people who love Flask and want to get more involved, that'd be great.
10:53 David Lord: We're definitely looking for more contributors in all of the projects that I mentioned earlier, so, Flask, Werkzeug, Jinja, everything out there. The biggest success I have at finding contributors is at PyCon. I'll run the sprints, and I'll find people who are interested. They'll come to me, basically, and I get to walk them through everything in person, which is really helpful, but I do get contacted occasionally saying, "Hey, can I contribute to Flask?" And I'm like, "Absolutely. Do you want to write documentation, do you want to write tests, do you want to make sure our configurations are consistent across all six projects, do you want to triage issues and see can you reproduce things, can you get more information out of people, can you identify where a problem is, even if..."
11:37 Michael Kennedy: Right, triage all the issues that come rolling in.
11:41 David Lord: Right, so even if you're not comfortable writing code yet, and you should be, you absolutely can contribute code to any of our projects, but there's plenty of non-code-related contributions out there that are really helpful to me, 'cause they give me more time to focus on the code.
11:55 Michael Kennedy: Yeah, that's awesome. Do you feel like it's a little easier to contribute to Flask 'cause it's six projects, and each project is a little easier to hold conceptually in your mind?
12:06 David Lord: It might be. There's four main projects: Flask, Werkzeug, Jinja, and Click are all pretty large codebases in themselves and they're pretty distinct use cases. So, there's not too much to do, actually, in Flask specifically anymore. 1.0 acknowledged, here, we're stable, and we have the features we want at this point. There's some bugfixes every now and then, but a lot of the work is in Werkzeug, and Click especially. There's a lot of stuff behind the scenes that people don't see when they use Flask everyday but it affects them. I think a lot fewer people are aware of those also, so people just being aware of those projects and looking at them also, and not just Flask, it would be really helpful.
12:50 Michael Kennedy: Uh-huh. And there's always tutorials and documentation that could use upkeep, right?
12:53 David Lord: Oh, sure, yeah. I went through and just for Flask 1.0, rewrote the entire Flask tutorial from scratch, just based on the questions and stuff I had experienced answering questions on Stack Overflow, helping people at meetups or conferences, so identifying those kind of things, like, "Hey, this didn't work for me in the docs." or, "This could have been clearer." and going and contributing there.
13:21 Michael Kennedy: Yeah, that's cool. I often think of, every time there's a question about something that I thought was explained well, but then it turns out there's a question about it, you're kind of like, "Eh," it's almost like an issue on that explanation, right?
13:32 David Lord: Most of the issues in Flask right now, the open issues on the bug tracker, are documentation-related. People have brought up, "This is confusing." or, "This could be clearer." and if you're looking for even more issues, just go on Stack Overflow, go to the Flask tag, and sort by most-voted questions, and just look at the top one, see if it's documented, look at the next one.
13:54 Michael Kennedy: Yeah, that's a really good point, actually. It occurs to me that it might be worthwhile to spend just a moment talking about these projects that you just discussed. We just quickly ran through it, like there's Flask, and there's Jinja, and there's Werkzeug, and stuff like that. Could you maybe give us a rundown of what each one of those actually is, so people know what they're about?
14:12 David Lord: Sure. Yeah, Flask is definitely the most popular, but if you're using Flask, you're using the five other libraries also, behind the scenes. Every time you pip install flask, you get all these also. Flask, obviously, is just a wrapper around all these other libraries. It's using what's provided there and just putting a nice framework around it. Werkzeug is the closest to what Flask is doing, it's also a WSGI library, but it's dealing with a lower level than what Flask is. Flask is providing an application framework and Werkzeug is providing all the parts for taking a HTTP request and a WSGI request and parsing out the headers, and producing some data structure, like a request that we can use and look at, and turning our response into something that our server can understand. Jinja is a templating library, which means you write text files with special syntax, and that it kind of looks like Python. It actually compiles to Python behind the scenes, and then you can render these templates and produce different webpages. For example, HTML pages with user information, or different details about different objects. Click is the most recent Pallets project but it's four years old at this point, so it's not that recent, I guess.
15:35 Michael Kennedy: It's also probably the one used most independently.
15:38 David Lord: Yeah, that's true. I wish I could name more projects off the top of my head that used it, but I do know pipenv uses it, Cookiecutter uses it, and Flask uses it, obviously. That's our command-line tool. It's kind of like Flask, in a sense, but for command-line applications instead, so you use decorators to turn functions into commands that you could run with options and arguments and produce terminal output.
16:08 Michael Kennedy: Right.
16:10 David Lord: Click is kind of unique; it tries to be very correct about how it interacts with the environment it's running in, in terms of encodings for the terminal, for the file system, for user input. I don't know the full history, but I think it part-influenced the recent changes in Python 3.7, where Python now handles UTF-8 encodings better, detecting those on Linux machines, because Click would actually complain, like, "Your system is not configured right, and I'm not going to try to guess." to a lot of headaches for people writing tools, but it did make people machines better.
16:50 Michael Kennedy: Yeah, yeah. One thing I want to highlight, I'm not sure people are aware of this, that GitHub recently added dependency computations or dependency reports for Python. That used to be just for Ruby and JavaScript, but if you go to pallet/click on GitHub and go to Insights, then Dependency Graph, and then Dependents, you can see there are 82,408 repositories and 4,774 packages that depend on Click, and there's a list of them.
17:16 David Lord: Okay, wow. I remember vaguely seeing that they had released that, and I haven't looked at it yet. That's really surprising.
17:26 Michael Kennedy: It's really cool.
17:27 David Lord: Dependency graph, I'm looking at it right now. Oh, yeah.
17:30 Michael Kennedy: Yeah, it just draws you in, right? And you can also see the dependencies in reverse, so it's good for seeing what does this project depend upon if you're trying to decide if you want to use it, but I think the other one is interesting for people like you who create these packages and then other people depend upon them, you can see what else is out there.
17:49 David Lord: Yeah, that's really cool, as just an absolute number. The other package I use for getting statistics like that is PyPInfo. I don't know if anybody's discussed that on your podcast before...
17:59 Michael Kennedy: No, I don't think we've talked about it.
18:01 David Lord: Yeah, they have all the statistics about PyPI downloads, and you can just query that through . That's why I was questioning your Django's the most popular, earlier, 'cause if you look at it month-to-month, it's not like I monitor this every month or anything, but Flask and Django are neck and neck, and some months, Flask will be higher by a couple tens of thousands, even, and sometimes Django'll be higher. It's really surprising, though, because despite them being downloaded the same amount, if you look at statistics like number of questions asked on Stack Overflow, Django has, I think, like, 50,000 times more questions, it's a ridiculous number.
18:45 Michael Kennedy: Well, I wonder if that's a micro-framework versus I think of more Lego building-block frameworks like Django. You wouldn't, say, tie a question about SQLAlchemy to Flask, 'cause it's about SQLAlchemy, but it's very common that you might do that for, say, Django ORM, being tied to Django, 'cause it's more grouped together? I don't know.
19:07 David Lord: Yeah, I'm not sure if you can even read anything into that. Maybe there's just a bigger community and so there's bigger awareness of Django, so people think to ask questions about it in the first place.
19:17 Michael Kennedy: Yeah, but I think maybe the main takeaway is Flask and Django are both well up there as some of the most popular frameworks for Python.
19:24 David Lord: Oh yeah, sure.
19:24 Michael Kennedy: So, let's see, we talked about Flask, Jinja, Werkzeug, woikzoy?
19:29 David Lord: Werkzeug.
19:30 Michael Kennedy: Yeah, thank you, and we just touched on Click, so we got MarkupSafe and Itsdangerous left.
19:33 David Lord: Right. MarkupSafe is used internally by Jinja, and it is just a very fast implementation of escaping unsafe characters in HTML.
19:45 Michael Kennedy: That's like if you're going to take something from a database and plunk it into the webpage as a string, you're going to HTML-encode that before you do that so it doesn't get owned.
19:54 David Lord: Right, right, so if you have user input or anything like that, you're going to make sure it's safe to display to people without them being able to inject unsafe code into their browser. So it's just a very fast of that, and plenty of other projects use it behind the scenes.
20:11 Michael Kennedy: Okay, interesting.
20:13 David Lord: I think Django might even use it?
20:15 Michael Kennedy: Yeah, you could go to the Insights and get 'em now. Or just their requirements on DXT. And then we have Itsdangerous as well, right?
20:24 David Lord: Yeah, so Itsdangerous is the last one, and that's just a way to securely sign messages. I know there's other solutions out there now like JWT, that sort of thing, but those didn't really exist at the time this was written, and this is a lot simpler than JWT, so basically, it's kind of like JSON.dumps, where you just throw it some data and it will dump it into a JSON string, then it will also securely sign that string, so that you know that it can't be tampered with.
20:51 Michael Kennedy: Right, tamper-proof marker.
20:54 David Lord: They can't edit it, so we use it for our secure cookies and for signing things like login tokens and reset tokens.
21:01 Michael Kennedy: Yeah, you don't want people tampering with that stuff. This portion of Talk Python To Me is brought to you by Linode. Are you looking for bulletproof hosting that's fast, simple, and incredibly affordable? Look past that bookstore and checkout Linode at talkpython.fm/linode, that's L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server with a gig of RAM. They have 10 data centers across the globe, so no matter where you are, there's a data center near you. Whether you want to run your Python webapp, host a private Git server or file server, you'll get native SSDs on all the machines, a newly-upgraded 200-gigabit network, 24/7 friendly support, even on holidays, and a seven-day money-back guarantee. Do you need a little help with your infrastructure? They even offer professional services to help you get started with architecture, migrations, and more. Get a dedicated server for free for the next four months. Just visit talkpython.fm/linode. Then there's a few other projects that are not directly under Flask but are under the Pallets or are related to Pallets, right?
22:07 David Lord: Yeah, there's plenty of extensions, there's some that I'm involved with. Flask SQLAlchemy, which is the official extension for tying SQLAlchemy sessions with Flask sessions. There's Flask WTF, which is a wrapper around WTForms, which is a form library that lets people interact with data submitted from webpages and render those forms that submit that data, do validation, that sort of thing. The other things I'm involved with, I wrote this library called Flask-Alembic, which is kind of like Flask SQLAlchemy. It takes Alembic, which is the migration library for SQLAlchemy and wraps that in the Flask configuration.
22:44 Michael Kennedy: That's really cool. I don't believe we've talked about Alembic very much, we've mentioned SQLAlchemy plenty of times, but I feel like Alembic, if you're doing real production, relational database stuff with SQLAlchemy, you should know about Alembic to be using it. Maybe give people a quick overview about what Flask-Alembic does to that whole mix.
23:04 David Lord: Yeah, I never just use SQLAlchemy, unless it's just a really quick example project. What Alembic does, it does something called migrations, so if you write your model in SQLAlchemy and you create a table in your database, if you want to change that model, the only thing SQLAlchemy lets you do is drop the table completely and then recreate it, but instead, you can run migrations, which lets you add or remove columns or change data, and just keep version control over what your database looks like as you add to it.
23:37 Michael Kennedy: Right, because with these ORMs, the structure and schema of your database has to be at least a superset of exactly what you have in your SQLAlchemy definitions, so if you add a column or field to your SQLAlchemy class, it can no longer talk to your database without also adapting the database schema, right?
23:55 David Lord: Right, so you need some way to tell the database there is this new column you need to know about, and that's what Alembic does, so Flask-Alembic just ties Alembic, which comes with its own CLI, for example, into Flask's CLI, and moves the configuration from Alembic into Flask, which is kind of a...
24:17 Michael Kennedy: So it's kind of like a wrapper.
24:18 David Lord: Yeah, it's a wrapper around it, mainly like Flask-SQLAlchemy is for SQLAlchemy. There's another library out there called Flask-Migrate which is another wrapper around Alembic, and that one's developed by Miguel Grinberg. We basically, from what I remember, 'cause it was like four years ago now, but I think we developed them at basically the exact same time, released them within a month of each other, completely independently. His is a lot more of a direct wrapper around Alembic, which, for a lot of people, is exactly what they need, and it's a lot more straightforward a lot of the time. Mine, on the other hand, I wanted to be able to dig into all the internals of Alembic and introspect exactly what was going on at any time, so it's more of a very opinionated framework on my end, and people can choose which one they use.
25:07 Michael Kennedy: It's good to have options, that's really cool. Let's spend a little time talking about maybe the biggest news for flask, in that it went from, what is it, 0.12 to 1.0?
25:18 David Lord: Yeah, 0.12.4 to 1.0.
25:22 Michael Kennedy: Well, here's a major open-source project going to 1.0, which is actually, I think, really, really positive, and I'm just super excited to see that you guys did that, because it's time, I think.
25:34 David Lord: Oh, it was absolutely time. I had been working on that, getting that happening for about a year prior to it, at least.
25:41 Michael Kennedy: We joked about it this PyCon, because Mahmoud Hashemi had come out with this thing called Zerover for zero versions, and making fun of projects that were still on zero dot something that were 10 years old, and Flask was on that list.
25:52 David Lord: Yeah, actually, I'd forgot about that until after I released 1.0, and then people were like, "Oh, it was because of ZeroVer." no.
26:03 Michael Kennedy: Set the record straight, this was going a lot longer before that.
26:05 David Lord: Yeah, ZeroVer, I was very amused by that, and I actually got them to put us on the emeritus list.
26:13 Michael Kennedy: Ah, nice.
26:14 David Lord: So we're graduated now on their website. But yeah, I've been working on it for a while, and we used to have people asking, "Hey, this is 0.12. My boss doesn't want me to use it 'cause it's not..."
26:24 Michael Kennedy: Exactly.
26:26 David Lord: We kept having to tell people, "This has been stable for years. Nothing's really going to change, there's no breaking bugs or anything, it's more just a number." I think for a long time, I told them, "Tell them it's version 12 and we misplaced the zero or something." But yeah, we finally got it out.
26:45 Michael Kennedy: That is the impression for a lot of people, especially people coming from commercial-oriented software backgrounds, I'm thinking Microsoft shops, .NET folks, I'm thinking Java, and those types of people. I think they even have a rule at the Microsoft shops, like you can't use it 'til version three, 'cause the first two are messed up, right? I just think there's so many large organizations that at least some of the folks in there have that mindset, and I think having this become 1.0 is a pretty big step to just sidestep that conversation.
27:19 David Lord: Yeah, and it feels significant, even if the actual stability of the software hasn't changed, or the acceptability to use it in production environments doesn't change, really.
27:33 Michael Kennedy: But there are some major changes in Flask 1.0. The list is not trivial.
27:39 David Lord: I was kind of surprised when I made that release log with these release notes, just how much had changed. It's a lot of small things, honestly, but it adds up.
27:50 Michael Kennedy: Right. You want to talk us through some of the major changes?
27:54 David Lord: Yeah, we dropped support for Python 2.6 and Python 3.3, which made me really happy.
28:00 Michael Kennedy: That's really nice.
28:01 David Lord: I was trying to use the PyPInfo, which I mentioned earlier, to figure out stats about how people are using it. I think less than 0.1% of installs were on Python 2.6.
28:13 Michael Kennedy: Yeah, 3.3 itself went unsupported, right?
28:16 David Lord: Yeah, 2.6 itself is unsupported, and in the future, I'm definitely going to be sticking with, as soon as Python drops support for a release, I'm going to drop support for it.
28:26 Michael Kennedy: Yeah, it makes sense.
28:27 David Lord: That doesn't mean we're going to rip out support and it's suddenly going to break, but we're not going to test on it.
28:33 Michael Kennedy: You're not going to inject breaking changes to force it to not work, but you're going to no longer run tests and not care if it breaks it.
28:40 David Lord: Right, and actually, Flask 1.0 secretly supports Python 2.6, even though I removed it a couple months before we made the release. I kept testing it internally, because I wanted to give people who are deployed at least one chance to be on 1.0 before they had to make a bigger upgrade.
28:58 Michael Kennedy: Yeah, that was generous.
29:00 David Lord: Yeah, I probably shouldn't have done it, in retrospective, but, stuff.
29:03 Michael Kennedy: You talked about the version eco in 1.0 and the comparison to Django. Django is now in this 1.0, 2.0 versioning as well, and they dropped support for Python 2 altogether. Do you have plans for that, outside of the deadline of 2020?
29:19 David Lord: Yeah. As soon as 2020 comes around, I am dropping support for Python 2, in all forms.
29:25 Michael Kennedy: Yeah, and I think that's basically what Django said, it was like their end of life, it was pretty far out before you were fully unsupported on an older version of Django or something.
29:33 David Lord: Yeah, I'm looking forward to that day. We'll still be supporting, probably, I think 3.4 and up at that point, so we're still a little behind in terms of features that we're allowed to use...
29:42 Michael Kennedy: Right, like async and await, for example.
29:45 David Lord: Yeah, that's a whole other discussion that we'll get into.
29:48 Michael Kennedy: Yeah, for sure; actually it is, isn't it? But do you think it will reduce the amount of code that you have to write? Do you think it will be easier for people to contribute if you don't have to do version checks or compatibility, or will it not matter?
30:00 David Lord: I haven't really considered it in a while. I think mostly, it'll just cut down on mental overhead. People don't have to think about it as much. When I write code at this point, I'm so used to doing it for Flask that I just, by default, write code that is compatible with both, and occasionally get a mistake that CI catches, but just having less surface to have to remember and to test I think will be beneficial. But for the most part, there's cool features that come out, but clearly, our code can be written in Python 2.7 and compatible code.
30:34 Michael Kennedy: Yeah. I think what's more important is that people that use Flask get to use the new features where and how they want.
30:42 David Lord: Oh, well, people writing applications in Flask can already use Python 3.7 if they want, and they can use f-strings, and what was the controversial change that got into 3.7?
30:52 Michael Kennedy: It's coming in 3.8, it was PEP 572, the assignment equality thing, the inline-assignment operator.
31:01 David Lord: Hey, I'm looking forward to when Flask only supports 3 and up, 'cause I'm going to switch all my code to that also. I personally like the change.
31:08 Michael Kennedy: Yeah, I do as well. Yeah, very nice. Okay, so, another major change is the CLI. Tell us about the changes there.
31:14 David Lord: Yeah, so I'll talk about the CLI in a second, but basically, a lot of the significant changes that went to 1.0 were basically me trying to make things easier for people. So, easier for people to learn, easier for people to understand, so a lot of this stuff is improving documentation, better error messages, and then a better CLI also. We did a lot of work on improving how the Flask command, which is the recommended way to run the development server while you're working, how it detects your application. So when you write code, you just write app equals Flask somewhere in your code, and there's even a common pattern called the application factory where you write a function that creates your application, so you never actually have an instance of your application writing code. That's what the server is in charge of setting up. So we did a lot of work to improve how the CLI can detect where your application is, what it's called, how it should be imported, and if it's behind a factory or not, so that everything will just work when you write it, instead of having to set up some extra glue in between.
32:23 Michael Kennedy: Yeah, that's cool. So, you no longer have to say set the flask_env, or the flask_debug, rather, or the flask_app environment variables, it can detect some of that stuff automatically?
32:35 David Lord: Yeah, a lot of the times, for simple applications, which is really useful for tutorials especially, flask_app will just know that you have a file called app.py, that's where your application is, I'll just look there. You do still have to set flask_app in most significant cases, like once you're writing a more significant application, you'll probably have to tell it at least which files are important, but nothing...
33:04 Michael Kennedy: This portion of Talk Python To Me is brought to you by 10x Agent on Demand. Here's a guess: if you're listening to my podcast, you're likely a Python pro. You may even be pretty well-paid to code in it. Here's another guess: you likely aren't being paid what you're worth. Why? Because negotiating isn't your thing. Even the best tech talent can get taken advantage of when negotiating their comp packages. Don't let this happen to you. 10x Agent on Demand has negotiated more than $50 million worth of deals for senior-level tech talent just like you. When you've got a job offer in hand or expecting one soon, contact 10X and they'll help you level the playing field. Just visit talkpython.fm/10x when you're ready to roll and mention Python for a free 30-minute consultation. 10X Agent on Demand; you handle the tech, they'll handle the negotiation. Another thing, actually I think this was in a warning message, it was an info message when I ran flask recently that I had a virtual environment named .env, and it said, hey, we think we can help you with some files that are hanging out in this .env thing. Yeah, so maybe tell us about the Python .env.
34:09 David Lord: Yeah, so as part of the CLI improvements, we also... Previously, when you were using the CLI, you had to type these environment variables in every time you opened the terminal, so you had to tell it export flask_app equals myapp, or export flask_app equals development, so we integrated Python.env, which is a library that reads these .env files and automatically sets up your environment variables based on it, so people can just have one of these sitting in a project and they won't have to set up their terminal every time they start working on the project again.
34:43 Michael Kennedy: Yeah, that's really cool. One thing I recently learned is the script that activates virtual environments, you can export stuff from there. You set up your virtual environment, go, and it actually configures your virtual environment, so in addition to having the packages you want, it kicks off with the right environment variables, which is handy.
35:02 David Lord: The downside of that, and we do have that listed in our CLI documentation, this is an option. You're using virtualenv's to edit your activate script, but the downside of that is, if you have multiple people developing, or if you're on multiple machines, and you recreate your virtualenv, you suddenly don't have that stuff, so it doesn't work again.
35:22 Michael Kennedy: Right, it's a pain in the CLI, sorry, continuous integration, and, also, you can check your .flask env into source control, whereas you can't, or you shouldn't check your virtual environment into.
35:32 David Lord: Yeah. If you managed to check your virtualenv into git and it works somewhere else, that's amazing.
35:39 Michael Kennedy: Yeah, exactly. A lot of stuff has to line up just so for that to happen. Nice. Okay, another one, another big change, I thought this was pretty cool, is it's going to help people when they're testing for performance and how my app's going to behave when I ship into production is the development server is now multithreaded by default.
35:56 David Lord: Yes, so, the development server actually had threading previously, pretty much for its entire existence, but you had to explicitly enable it, so when you were starting, you had to say threading equals true or something. So now, people were just always running into things like, "Hey, I'm trying to serve some media and make an API request at the same time, and suddenly it's hanging." Well, that's because the dev server would only handle one request at a time, but we decided, let's just enable threading by default. It makes some things more difficult to reason about, but debuggers nowadays are pretty good at figuring out what threads are running and where to do breakpoints and all that.
36:37 Michael Kennedy: I think it's a good change. We're living in a multithreaded world, right? A multicore world?
36:41 David Lord: That's actually one of the big hidden bugs, not bugs, but things that need to be improved in Werkzeug now, because we're threaded by default. Wekzeug has this nice debugger that pops up the traceback and lets you interact with it when there's an error, but it only works in single-threaded environments. It'll still output correctly, but if you have multiple requests going on at the same time and you try to interact with the traceback, you might just get junk data back, so figuring out how to get that working in a threaded environment is actually on my to-do list. It still works for most people, it's not a huge issue.
37:20 Michael Kennedy: How many people are actually interacting with the debugger and hitting concurrency at exactly that moment, right? Probably...
37:27 David Lord: Very few; I think we got the couple people who reported it and I just said, just try to make your thing synchronous when you're debugging, at least.
37:35 Michael Kennedy: Right, right. use this command line that makes it not threaded.
37:38 David Lord: Yeah. So, there's still things to be fixed, but we're basically trying to improve the 80% hit rate. 80% of the time, you're going to fix the, or whatever that saying is, 90-10, or something.
37:52 Michael Kennedy: Yeah yeah. Get people to fall into the best-case scenario most of the time.
37:56 David Lord: Right.
37:57 Michael Kennedy: So, another thing that changed is accessing missing keys from request.form. That's one of your error-message-type things, right?
38:06 David Lord: Yeah, we had a couple things. Basically, the way Flask looked up error handlers and reported errors was improved, so it's more consistent in more cases, and as part of that, I noticed that, and this is an issue that comes up on Stack Overflow all the time, is, "Hey, I tried to access request.form_name and I got a 400 error. Why?" Well, the answer is because you didn't submit a form field called Name, but we don't tell you. The dev server never told you that.
38:43 Michael Kennedy: Because if you're deeply familiar with status codes, you would know that 400 means that something is wrong with the data you submitted, but it's still not even obvious there, right?
38:53 David Lord: Yeah, so now, when you're running in debug mode, the error, we still raise the same error, but I inject some extra information into it, about, hey, you're trying to access this key and it wasn't there, so go check your HTML and see if you're sending what you expect.
39:09 Michael Kennedy: Yeah, that's cool, that could be the difference from, "Oh yeah, of course, I'll check my HTML." versus hunting Stack Overflow.
39:16 David Lord: I know Stack Overflow probably isn't the best metric for this, but we still get plenty of questions about, why am I getting 400 error? I've even gotten questions with the error message saying, "You're missing this key." right there in the question. So I'm not going to solve everybody's problems, but it's a lot clearer, and that was basically the number one problem where we saw. I'm seeing it less, at least.
39:39 Michael Kennedy: Yeah, it'll definitely be less. That's cool. You're never going to solve the problem of somebody just sees it doesn't work, "I'm just going to Stack Overflow and pasting the error." and not reading through or thinking through, or maybe they're just so new that they don't see what should be obvious.
39:55 David Lord: Sure, there's still a lot of information even if that's, so I understand, obviously.
40:01 Michael Kennedy: Yeah yeah, for sure. Let's see. You changed error handlers a little bit, like the thing that will run if, say, there's a 400 bad request, or 404, or something like that.
40:10 David Lord: That's more of an internal change, I don't think most people noticed, but technically, you can register error handlers on Flask and on the blueprints inside of it, so that when certain errors are raised, they'll be handled by those instead of causing a 500 exception to be sent to the browser, and in certain cases, or for certain types of exceptions, the behavior was just inconsistent, so we just went back and looked, like, how is this actually working? Oh, there's this mess of different if statements. Well, let's just simplify that, so there's a strict set of rules that it goes through now, and it's documented and all that.
40:47 Michael Kennedy: Yeah, it's cool. So, one thing that you just mentioned that I think is worth touching on for a little bit for the listeners: a lot of the frameworks, it's a little easier to partition your view methods into different files and categorize them and stuff, because you just take a static decorator that comes out of, say, Pyramid, you say @view_config, and you just drop it there. In Flask, you create the app and then you say app.route, so in order to split that stuff apart, you have to pass that app around in certain ways, but then you also have blueprints, which really simplify that. You want to just tell people real quickly, who maybe only know about app.route, about blueprints and about the problem it solves?
41:24 David Lord: Yeah, so I mentioned the application-factory pattern earlier, where you don't actually ever have an instance of your application when you're coding, you have a function that creates it, and that's actually the recommended way to use Flask in the official tutorial now, is use an application factory, because it solves a lot of problems that people run into, even if it's a little more confusing, but one of the problems with using that is, well, you can't just decorate your view function with @app.route anymore, 'cause you don't have app. So instead, Flask has this thing called blueprints, which are basically ways to defer calling app.route. So, you call blueprint.route, and that just registers, hey, this is here, and now, later, when you have your application and you register the blueprint with your application, take all those deferred registrations and perform them now, so you don't have access to the application, you can split your code up into different modules so that all the stuff about users is over here and all the stuff about blog posts is over here, you don't have to worry about circular imports or any of that.
42:32 Michael Kennedy: Right, and that has been tricky, and I think the blueprint stuff is really beautiful. It just makes it so much easier to partition your code in a more healthy way for large apps.
42:39 David Lord: Yeah, it's a really good pattern. It's something that confuses a lot of users, I think they expect more of it than it actually does. Like you said, it's a pretty straightforward, or it's a pretty simple pattern. It just defers calls.
42:57 Michael Kennedy: People are doing Flask and they don't know about blueprints, they should go spend the five minutes and learn about it.
43:01 David Lord: Yeah, read the official tutorial, flask.pocoo.org/docs/tutorial. It'll walk you through an application factory, making a blueprint, all that.
43:10 Michael Kennedy: Yeah, yeah, very cool. Another thing that changed in Flask 1.0 is the testing got a little bit easier.
43:15 David Lord: The testing?
43:16 Michael Kennedy: The test client having a JSON request and then also a get JSON for response, right?
43:22 David Lord: This was another one of those, hey, there's an inconsistency here. You could test JSON before, plenty of people did, but the request object that Flask gives you when requests come into your views has this JSON property, and it basically automatically parses JSON from the request.
43:42 Michael Kennedy: Right, a dictionary pops out if it has JSON text inside.
43:46 David Lord: So people kept expecting that to work when they were testing, so they would make a request with the test client, get a response object back, and, unlike with the request object, the response object didn't have that, so they'd call JSON, it wouldn't work, and then they would have to go get the raw bytes and pass it to json.loads, and some people would use Flask JSON implementation, some people would use Python's. So we just made it consistent, so you can now get JSON from the response just like you can get it from the request body. Similarly, a lot of people expected, we have this test client where you can make a fake request without running the server, it'll generate the correct environment behind the scenes. So you just say, I'm going to request /users, and I'm going to pass name equals David to the form. It looked kind of like Python requests the library, so you'd make requests.get, name equals David, so people were expecting it to work like requests, JSON equals, so you had to encode the JSON yourself. Now, you can just, if you want to test your JSON API, you can use the test client and just do JSON equals this data structure.
45:03 Michael Kennedy: Yeah, that's cool. Another thing around that is the test CLI runner.
45:08 David Lord: Oh, right, yeah. As another testing thing, we have this test client which makes requests, but we didn't really ever document how to test CLI commands, and one of the selling points of the Flask CLI is that you can add your own commands, so if you want to add a user-management command, like, hey, have a create-user app command that I can run on the backend, or add a user when I'm deploying, there was no way to really test that. It was documented in Click's documentation, but even with that, it wasn't really clear how to get Flask's CLI object working in a test framework. So, we now have this test CLI runner that mirrors the test client, so you can test the CLI code.
45:52 Michael Kennedy: Yeah, that's great. I feel like that's the main items that I saw that are pretty interesting. Anything else that you want to tell people about 1.0?
46:02 David Lord: I think that was the big stuff.
46:03 Michael Kennedy: Yeah, I think so as well.
46:04 David Lord: I mean, you can go look at the full change log, it's pretty impressive. I think it's two pages long on my screen, vertically.
46:12 Michael Kennedy: That's awesome. Yeah, these seemed like a lot of great changes, and what do you say for people who are thinking about upgrading, like maybe they've got Flask==0.11 and they're afraid of change, and they don't want to change it? Should they change, and what would they get from doing so?
46:28 David Lord: They should absolutely upgrade, especially if they're on 0.11, because that's a couple years old.
46:33 Michael Kennedy: I'm thinking pretty out-of-date version when I said that.
46:35 David Lord: Yeah. One of the reasons to upgrade, if nothing else, is to continue to get support. Due to the size of our organization, we don't really offer support on old versions. I will do security fixes for 0.12 until 1.1 comes out, but nothing besides that.
46:54 Michael Kennedy: Right. If there's a problem and somebody has 0.11, the official answer is, "You want to fix that, make that problem go away, you install 1.0," right?
47:02 David Lord: Yes, install 1.0. Even if you're on 0.12, there's no real reason to stay on it at this point. Luckily, what I've heard from various users, when I was at PyCon, Flask 1.0 had just been released, and people were already telling me, "Yeah, I upgraded, and it was literally just changing the version number. Everything worked." There are some things that changed a little bit, but they're rarer cases, and it's documented on the change log, and it's pretty obvious when it fails, like, oh, this thing got renamed.
47:30 Michael Kennedy: Right, so there's not a whole lot of work to upgrading.
47:33 David Lord: No.
47:34 Michael Kennedy: Alright, excellent, that's good to hear. One of the things that I thought was interesting is you talked about on the Pallets organization website about being part of PSF's Fiscal Sponsorship Program. If people want to support Flask, maybe you want to tell them about that program and how they can help?
47:51 David Lord: Sure; it's really cool, it's also really new, so I may not be the best spokesperson for it yet.
47:57 Michael Kennedy: I hadn't heard of it before, I'm like, "Oh, we should talk about this, just so people know it's out there."
48:01 David Lord: Yeah, this is a little bit of advertising for PSF also, but they have this program called the Fiscal Sponsorship Program. They were mostly using it for meetups at the time that I tried to get in, and basically, what it is you submit your organization, and they accept you, or if they accept you, you become part of the PSF, essentially, so you gain their non-profit status, they will help you out with certain logistics, and they will also set up a donation page for you and a bank account for you, that they'll manage, which was great for me, 'cause it's not something that I have any experience with, and I did want to be able to start taking donations for Flask. So yeah, I've reached out to them, 'cause somebody had pointed out this program, and when I reached out to them, almost a year and a half ago now, I think, they didn't have this setup for developer organizations like Pallets yet, so we were their test project. We got into this program right before PyCon, and then I think they've accepted a couple more projects since then, in parallel with us. So, we now have a donations page. You can go to palletsprojects.com/donate, and that'll redirect your to the right place. Lets you take PayPal or checks, do one-time or recurring payments, and we're basically just trying to raise money to support the community. I'm not 100% sure what that means yet, I have some vague plans. We want to be able to support, maybe, if you want to have a meetup that sprints on Flask, for example, we can sponsor that. Maybe we sponsor the pizza or something, right? Or recognizing people, outstanding contributors in the community, sort of like Google does. Google has the, I don't know the name of the program, but they recognize developers every year, so we were thinking that would be a cool way to do it, and maybe, further down the line, being able to have a Flask Conference.
49:57 Michael Kennedy: That would be really good.
49:58 David Lord: Yeah, yeah. Those are outward-facing, and then, the other thing donations would support would be getting the current maintainers to more conferences, so we could run the sprints in person, and supporting our infrastructure and all that sort of thing.
50:13 Michael Kennedy: Yeah, I know, I'm pretty sure it was NumPy that had this, one of the scientific groups, basically, no, I think it was PyPy. Anyway, one of these groups, basically, a lot of contributors had never met, and they had taken their donations and they used it to get the contributors physically together, maybe like you said, at another conference like PyCon US or EuroPythonor something, and it seemed like it made a really big difference.
50:36 David Lord: That's absolutely something I want to do eventually. I've never met Armin, or Adrian, or Marcus in person, or any of the other core contributors, mostly because they're in Europe, and I'm over in California, so it's a little difficult to find the time and money to do that, and being able to get us all in the same room I think would be very productive.
50:55 Michael Kennedy: Yeah, I think so as well, and let me just put a plea out there, or a comment out there, for folks who work for companies that are large, successful companies that depend on their technology and that technology significantly involves Flask. I think there's so many large, multi-billion-dollar companies that are built on Python and some of its libraries, and they don't necessarily contribute anything back. If those companies could all just contribute a very, very small amount of what they pay their developers to keep the projects they depend upon healthy, that would go a huge, huge way. So, people who are out there in that situation, I'm not, but if they can make that happen, that'd be awesome.
51:39 David Lord: Absolutely. That was basically my entire PyCon when I wasn't in open spaces or sprints, was being on the floor. I actually printed out business cards, not for myself, but for Pallets, with the donate link on it, and I was handing them out to every single company, and saying, "Hey, do you use Flask?" I think it was something like 80% of the companies at PyCon use Flask, or Jinja, or Click.
52:04 Michael Kennedy: And if they all just recurringly added $100 or $1,000, that would just change things dramatically, I'm sure.
52:11 David Lord: Oh, sure, if everybody added $100,000, that'd be great.
52:16 Michael Kennedy: Or $100,000, obviously.
52:18 David Lord: No, I don't know what we would do with that much, gosh. Don't do that all at once. Give me a year to ramp up, at least.
52:23 Michael Kennedy: Exactly. You'll find David on his own personal island, he's no longer working on Flask; no, just kidding. Yeah, that'd be awesome if we got more support, for Flask and other projects that are in the same boat, basically.
52:36 David Lord: Absolutely, I think it's really important just to recognize the tools you're using and support the maintainers that are already working really hard on them. So, yeah, we're starting that. I didn't really advertise it that much after PyCon, but we've gotten a significant number of donations already just from personal donations, and it's really cool to see those notifications come in. I see a little notification like, "$5 was donated." every time it happens, and it's really nice to see that, 'cause a lot of the times, my experience with maintaining is, "Oh, there's a new bug, go fix it." and stuff, it's never really anything really positive...
53:09 Michael Kennedy: Somebody being impatient and frustrated, and then they've gotten to you finally, and now... Your frustration, right? Yeah, yeah. I hear ya. So, let me ask, I guess, a few closing thoughts here. What's next? You've got 1.0 out now. Now, where are you headed?
53:26 David Lord: I think I said this earlier, but Flask 1.0, all the features that I want, at least, are in there, and I think most of the features that people asked for are easy to do with extensions, at this point. That's not to say we're not going to add anything to Flask, but it's mostly, like I said, how can we improve people's experience with Flask, how can we make it easier for them to learn and work with it on a day-to-day basis, so, improving documentation, identifying better error messages, writing more tutorials, writing better tests. That's where a lot of the focus on Flask is. There's still a lot of focus on Werkzeug, and Click, and Jinja, for actual bugs and features to get in. Werkzeug is just never-ending, because there's always more HTTP RFCs coming out, changes in subtle ways. That's my favorite. I've gotten so good at reading RFCs now, and I still don't like it.
54:19 Michael Kennedy: I'm sure, I'm sure, that's pretty dry stuff. So, I guess the final question around this is, when will I be able, will I ever be able to write, let me rephrase that way: will I ever be able to write async def index...
54:34 David Lord: That's the one big secret.
54:36 Michael Kennedy: @App.route async def index.
54:38 David Lord: Yes. I've committed to this publicly in other places, but yes, we do want to have async support in Flask and Werkzeug.
54:46 Michael Kennedy: That's awesome.
54:48 David Lord: Getting there is going to be really difficult, because we also want to maintain compatibility with Python 2.7 for at least another year and a half, we want to maintain compatibility with Python 3.4.
55:01 Michael Kennedy: I think if what you told people was, "You have to wait until we drop support for 2.7 and 3.4," just knowing that it is coming actually would probably...
55:09 David Lord: I mean, honestly, even if we don't say that, it's probably going to take that long to get there. There's a lot of work to do. Werkzeug makes a lot of assumptions, behind the scenes, about the WGSI environment. I have gotten some contributors who are interested in working on that. There's an effort in Werkzeug to make it sans-I/O, which means separating the I/O from the parsing so that we can plug in different backends.
55:35 Michael Kennedy: I think you could plug in an async layer right there without really changing much.
55:37 David Lord: Right, and then on the Flask side of things, we're looking at ways, like the 2.0-to-3.0 migration tool, we're trying to look at some kind of async-to-sync migration tool, where we can write async code and get a version that can also work with sync code. I think there's been some work on that in urllib3.
55:57 Michael Kennedy: Have you seen the work they're doing with Quart?
56:00 David Lord: Yeah. I actually reached out to Philip, who's the author of that, a couple weeks ago, and said, "Hey, Quart can still be its own thing, but I know you were trying to be Flask-compatible, would you be interested in just making Flask async?" And he was onboard with that. I've met with him a couple times. He's still working on Quart, obviously, but he's going to at least be there giving input about how we can get Flask to be in that same place. So yeah, it's definitely a cool project and excited to work on it.
56:32 Michael Kennedy: Yeah, if that sounds interesting and people don't know anything about it, I interviewed Philip Jones about Quart in Episode 147, it was a while ago.
56:40 David Lord: Ah, okay, yeah.
56:42 Michael Kennedy: Yeah, I played with it a little bit, and it's pretty solid. It seems like if you could take what he's doing and where you're going and blend it.
56:50 David Lord: Yeah, the nice thing he has going for him is he can say, "I only want to support Python 3.6 and above, and I don't want to support sync at all." or, "I'll support sync in some worker thread, executors, but I'm all async." We have to be a lot more deliberate about how we handle backwards compatibility in Flask. We will get there.
57:14 Michael Kennedy: Well, I'm really encouraged to hear that you're on that path, even if that path is a long journey.
57:20 David Lord: Yeah. So, if some people are interested in contributing or using async code in Flask, that's definitely a place where I could use more contributors also. Check it out.
57:32 Michael Kennedy: Yeah, awesome. Alright, well, I think that's probably where we're going to leave it for Flask, but it's been great to get caught up with what you're up to.
57:39 David Lord: Yeah, thanks for having me.
57:40 Michael Kennedy: You bet. You're not out of here without answering the two final questions, though. First of all, if you're going to write some Flask code, what editor do you use?
57:48 David Lord: Pycharm. Pycharm Professional.
57:50 Michael Kennedy: I love it, I'm right there with you. Alright, and then notable PyPI package, we talked about six already: Flask, Werkzeug, and so on. Other ones that maybe people don't know about, you're like, "You should totally check out this"?
58:02 David Lord: Yeah, I gave this one a little bit of thought. I don't actually have the opportunity to use a lot of PyPI packages, but the ones that have been in my awareness lately are one called Authlib, so that's...
58:16 Michael Kennedy: A-U-T-H lib?
58:18 David Lord: Yeah, yeah, and that's a new, very thorough implementation of OAuth and OpenID, and OAuth2, client and server, for Flask and Django, and has all sorts of integrations with different existing OAuth implementations on different social sites.
58:37 Michael Kennedy: Oh yeah, that looks cool.
58:39 David Lord: It's pretty cool. If you go look at the documentation, it's pretty incredible how thorough it is in terms of what standards it's supporting and all that; and the other one I'm looking at is Flask Talisman, which is basically...
58:52 Michael Kennedy: What's that about?
58:54 David Lord: This one's really important, I think a lot of people don't really think about what it solves, and what it does is there's all these different headers that you can send in your responses to browsers that will tell the browser how to be secure. What stuff it's allowed to do, and what stuff it should block from happening. There's a lot of them out there. There's, maybe not 20, but close to 20 different headers and different configurations of them, and Flask Talisman will set all this up for you, for the most part, and will give you the secure defaults, and all you do, basically, is just wrap your application in the Talisman extension and it's done.
59:30 Michael Kennedy: Oh, that's cool.
59:31 David Lord: Your application is just more secure, and I really like that, I'm just plugging it in to all my applications now.
59:36 Michael Kennedy: Oh, that's cool; it looks like it comes from Google as well, which is pretty nice. Those are two really great recommendations there, and I'm definitely going to play more with Authlib, I got to get some single-sign-on stuff going on. So, that'll be great. Final call to action. People now know there's a Flask 1.0, what should they do?
59:52 David Lord: There's Flask 1.0, go upgrade, watch us on GitHub and start contributing to issues, donate, go to palletsprojects.com/donate, and help the maintainers all meet up, maybe.
01:00:05 Michael Kennedy: That's awesome, alright. David, thanks for sharing all of what you've been up to, it's really great work, and I'm super excited to see Flask moving forward like it is.
01:00:14 David Lord: Yeah, thanks for having me on, Michael.
01:00:15 Michael Kennedy: You bet, talk to you later. This has been another episode of Talk Python To Me. Our guest on this episode has been David Lord, and has been brought to you by Linode and 10x Agent on Demand. Linode is bulletproof hosting for whatever you're building with Python. Get four months free at talkpython.fm/linode; that's L-I-N-O-D-E. When you've got a job offer in hand or are expecting one soon, contact 10x Agent on Demand and they'll help you get the salary you deserve. Just visit talkpython.fm/10x and mention Python. Want to level up your Python? If you're just getting started, try my Python Jumpstart by Building 10 Apps, or our brand-new 100 Days of Code in Python, and if you're interested in more than one course, be sure to check out the everything bundle. It's like a subscription that never expires. Be sure to subscribe to the show; open your favorite podcatcher and search for Python, we should be right at the top. You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening, I really appreciate it. Now, get out there and write some Python code.