#316: Flask 2.0 Transcript

00:00 Flask is one of the most popular Python web frameworks and they have a huge news to share with us, Flask 2.0 just released after a ton of work. And it's as big a deal as the version number suggests. Async changes are coming Python3.5 and below including Python 2 support has been dropped and much more. Join me as I discussed Flask 2.0 with David Lord and Philip Jones. This is 'Talk Python to Me' Episode 316 recorded may 10 2021.

00:41 Welcome to talk Python to me, a weekly podcast on Python, the language, the libraries, the ecosystem and the personalities. This is your host Michael Kennedy. Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes at talk python.fm and follow the show on Twitter via @talkpython. This episode is brought to you by us over at Talk Python Training. If you want to learn Flask, we built a fantastic course called 'Building data driven web apps with flask and SQLAlchemy'. In this course, we build a 'PyPI.org' clone from scratch using Flask and SQL alchemy, you'll learn many of the major ingredients needed to build most web apps. If this sounds amazing. Just visit 'talkpython.fm/flask' or email us at 'sales@talk python.fm'. David Phil welcome back both of you to talk with me. Hello. Hello. Thank you. Yeah, it's great to have you back. David, I've had you on to talk about flask. And Phil, I've had you on to talk about derivatives of flask, I suppose about core your project. And they're both kind of approaching the same type of thing and that sort of zeroing in so now we have you here together, I suppose working on flask 2.0. Right. It's all merging into one not really just our efforts.

01:55 So several libraries. Yeah. But it's really cool to see you working closely together, rather than just two disjoint things right. I think that gives a lot of credibility, especially the Quart , right? Because it was kind of this experimental thing. And now it's if not exactly is it a Pallets project officially or is it just working more closely? It's working more closely. In addition, it uses 'Werkzeug' now, which never used before. So it's been quite a lot of work in in that project to make that possible. Yeah, that's really cool. And 'Werkzeug' is like one of these foundational bits of flask. We'll get into I'm sure. Yeah. So the the idea is, because Quart is supposed to be API compatible with Flask, we want to get it using as much of what flask is using as possible. Our long term plan is to get it using the more Quarts and fixed. Yeah, yeah, super cool. Maybe some it's dangerous as well could get in there Who knows?

02:43 It's risky, but you guys can make it happen. All right. Now before we jump into the main topic, flask 2.0. You both have been on the show before, I often ask people how they got in programming in Python or whatnot. You've you both answered that question. Previously, people can go back and hear it if they want. So how much to catch up? What do you been up to? Since you've been on the show? Last, Bill, You wanna go first? Sure. I think you're an open source sensor. It's, it's been Yeah, working a lot on Quart and working more. At the time, I didn't think I was really helping with the 'Pallets'project. So I've been helping with them since. And, yeah, just kind of developing those two, and then a lot of work trying to get well, the Async support that's now coming to flask is quite exciting. I kind of personal note. Yeah. Very exciting. Yeah. On a personal note, I work in London. So I've just been, I've actually worked for a few companies tried my own startup it didn't work, sadly. But working in London now. So it's nice. I love London. It's a fantastic town. I haven't been there in a year and a half. Oddly, I don't know.

03:42 David, How about yourself? Where do you been up to? So I'm trying to remember when we did our podcast last, but it must have been like three years ago. It's been a while. So yeah, after that. I've just been working down the backlog of all the issues on flask, and pallets and all that. And now we're finally at the point where I'm confident about releasing all this stuff. So yeah, it's just been more and more open source work, and then still working for the same company I've been working for for 10 years now. So that hasn't changed at all. Yeah, that's cool. And I suspect they're pretty supportive of flask. Oh, yeah, we get to use it internally. I actually introduced Python and Flask to the whole company. We don't know. Yeah, I mean, how much of an advantage is that to have somebody like you? Yeah, so they definitely go with it. Everything right? Yeah. When we're bidding for contracts and stuff. They definitely Yeah, like use that as like, hey, we've got one of the maintainers of the libraries we want to use. What do you bring? Exactly what

04:38 what's the advantage you have? Well, have you met David? Now? That's fantastic. That's fantastic. And check this out. You were back on episode 177. And the title was flask goes 1.00 my gosh. Yeah, this is September 15 2018. So it's been a while, but also, it's time to have you back because now you guys have incremented the big number in the version

05:00 Well, not quite almost one more day.

05:03 One more day. Yeah, smart. Okay, so for people listening on your podcast player, that's like, a week ago. Oh,

05:11 One more day. Fantastic. Super cool. So I see some really interesting questions from people who are watching the live stream. But let's dive into a little bit of background stuff. And then I think we'll go from there. So I kind of wanted to start with the larger landscape of the web. And maybe also you could tell us about, I just threw that out there as if people would know, the pallets project. We talked about it a little bit with both of you, David, give us an overview of what the pallets project is because we have flask, and we have Quart . And then we have these other libraries as well. What's the relationship of all these things? I know Quart is its own thing. But it uses like 'Werkzeug'. So like, for example? Yeah. Well, pallets is the organization like just an open source organization, not an actual company, or anything that maintains flask and the libraries that flask uses. And so that's flask Werkzeug, Jinja, Click, 'ItsDangerous' 'MarkupSafe'. And it was started, all these libraries used to be maintained by the original author Arman and his other group 'Poku'. And eventually, they kind of grew larger than that. And the original team kind of grew to do other things. And so he formed pallets. And that's about when I joined and started maintaining everything. And although recently, I've come to the understanding that as much as I push the name pallets, I will never have as much name recognition as flask. And so you can also refer to things as flask. And I will know what you're talking about. Yeah, no doubt, like the general flask, obviously, is made up of the foundational bits as well. Yeah, yeah. And so palates, for a very long time was just the GitHub organization that these projects, repos were under. And I've been working every time to expand that into an actual open source organization, kind of, not nowhere near this yet, but inspired by like how Django Software Foundation works, and those sorts of things where they do things besides just develop. So we've been working on you know, growing the community getting more maintainers involved. Running 'Flaskcon' last July, I think, and we're Another one is coming up. I think November is this tentative schedule. And this is obviously I will guess, online at this point. Yeah, it'll be online. So it was online last time also, and it worked out pretty well. You can go find all the videos on 'Py video'. They're up there. Yeah. Fantastic. Do you have Sprint's or anything like that around it? Or is it just presentations? Oh, we didn't do Sprint's last time, because it was just a first time running a conference. We'll see what happens this year. Yeah. No concrete plans yet. Yeah. Fantastic. All right, I kind of wanted to start off this conversation with a wider view, looking at the Python web space. So I put up here for us to look at the Python developer survey from the PSF and JetBrains. For 2020. Obviously, it's 2021. But the results for that was the last survey that they've come out. And over there, we've got the web frameworks being used. And you know, these things are never comprehensive. Like there's 6% of other whatever that means. But we have flask, now clearly being the most popular one. So first of all, congratulations on that. That's awesome. I wonder if 'Quart' was folded into flask, or if it went into the other, you know, innovations mind when they clicked the button, which they click, you know, I imagine is probably in the other hand, a small percentage. Very small. Yeah. Nice. Okay, well, so this is really neat. I guess the big interesting thing here as well, the beyond, I think it was you in Django, at least in this previous survey, 2019. We're just tied, basically. So now it's you talked about how there's a lot of growth and a lot of momentum. And I think that's even more than what you see here on the screen. Like I think a lot of the API's that Flask embraces in the way of doing web programming has been adopted by many of the other new frameworks as well. So for example, we have Fast API making a jump up to 12%. Here, which is probably the biggest difference from the year before, as well. What do you think about this picture here? And then like your What do you think about just the Python web space in 2021 . Fast API is definitely gaining ground. Flask I'm continually surprised that so many people use flask never, it's hard to wrap your head around like that many people, I was just looking at the downloads this morning, and it was 14 million in the last 30 days in the last 30 days. That's so insane. That's just flask like if you look at like ginger, because ginger is used by things besides flask like Ansible, right? We're like the 20. Somethings very cool. And you can use Ginger just on its own for super interesting things as well. Like, I recently did a project where I needed to generate a PDF that was like out of you know, here's data in a dictionary, and I need to make a PDF that looks formatted. And I just use Ginger and a Ginger template to generate the HTML, then feed it off to a PDF library that made it into a PDF, right. There's all sorts of little edge cases like that. And same with click I mean, people use click to make actual command line applications not just to provide a little CLI for flask so yeah, when you look at this, like you like you realize that like oh, they're also using like all these other libraries, but

10:00 I never really like think about the numbers, I guess every now and then I remember flask having more stars than Django on GitHub. But that's because Django joined GitHub late. And they surpassed us now. But that's about the only joke metric I follow. Really?

10:13 Yeah. But yeah, I've seen a lot of interest in fast API. And I think it's a, it's nice to just see that, like, none of nothing stagnating, you know, like everything. Like there's, there's new ideas out there, people are developed, like, they're stable libraries that continue to develop like us. And we were still adding new features. And there's like completely new ideas, or new formulations of libraries. Yeah, I feel like we're in a bit of a Cambrian sort of 1000 flowers blooming type of time, and many of them won't survive that. But there's a lot of fresh ideas out there. And it's pretty exciting. Yeah, it's like having a healthy ecosystem having choice that you can choose whether a certain framework is more appropriate for, you know, the project you're starting or working on, I think is really powerful for like users and for maintainers. Yeah. And you can borrow ideas to like, Oh, I see the way fast API is doing types, like mean this, maybe that makes sense to like, allow that as an option. somewhere else. Yeah, who knows? Right. But one thing that I quite like to take from this list is Falcon has a really quite exciting router. And I think it might be a little too, too much for Werkzeug, perhaps, but I've been playing around with taking the ideas for Falcon and bringing it to 'Werkzeug'. So what makes it exciting is it's very fast matching system. And yeah, should outperform the effects of 'Werkzeug' get it in? By Okay, like, a good fraction. So that'd be exciting. Yeah, there's a lot of interplay here that I think is pretty neat. And why we're on this sort of broad topic. Rohit asks, in the live stream, you know, what are the advantages of using flask over Django? Maybe that pairs them a little bit too tight. But you know, looking at this list, these are the ones that probably the trade offs people are thinking about. Yeah, this gets harder for me to answer over time, because I haven't used Django in a long time. But it's hard to compare one to one. It's like apples and oranges, right? Like I said, a couple minutes ago, like you're choosing the project that's most appropriate, or the the framework that's more appropriate for your project and the way you want to work. So it's not necessarily that you're going to be losing out or getting any given feature by choosing one or the other. It's about how they feel when you're working on them. You know, like, sometimes Django makes more sense to people or fast API makes more sense. Or Yeah. And then like, they also have different goals, right? Like flask is deliberately just the web framework and wrapping some other libraries around it. But it's cool is that if you want other features, somebody develops an extension that is specific to that. And you add that on. And I mean, Django and I don't know about fast API, but Django has the same idea. It's just how many batteries they decide to include is different. Yeah. Phil, you want to take a shot of this before I give my thoughts as well, maybe? Yeah, I think specifically flask, and Django is full, it came down to a kind of a choice about how to do things like flask doesn't really give you an answer. And you can go and choose from the extensions, whereas Django does. And yeah, I think it's, like David said, a bit of what your preference is really what you prefer. Yeah. I mean, Django is making huge strides. And like async, also, and we're adapting to that, too. But they all have different solutions to the same thing. approaching it from different directions. Yeah, definitely. There's a lot of interesting stuff happening in Django around this as well. The way I see it is, you know, flask, it's like an empty canvas. And it's got just a few really nice little building blocks. And then you can build what you want, right? You wanna use Postgres and SQL alchemy. Great. That's totally easy. You wanna use MongoDB and Mongo engine, equally easy, go have fun, right? Like you, you can pick just the little bits that you really like, you don't have any other bits to worry about. And then you're good to go, right? Django, like, well, if you want to break from the Django ORM, probably you can do it. But it's, there's a little bit of a mismatch there, you kind of got to work around it, its advantages kind of become less good, right? Like, it's Admin Tools might not work as well, if you try to say switch to Mongo, or something along those lines. And if what you want is like, I'm not really sure what I'm doing to build this website, and I just want some guidance, like, Just show me the main way, and I'll just do that I don't, I just would like to go along for the flow. I think Django is fantastic for that it gives you like, really good pre built tools, like the admin stuff, and whatnot. But if you really care very much about which little piece you pick, and you want to put them together, just so I feel like you're better off with a microframework or some sort of like flask. That's my, my view. And I know some people love one side and hate the other and vice versa. So it's, you know, it's also a personal challenge or a personal thing you got to work out for where do you fit on that spectrum? Yeah, I mean, I personally started with Django flask was just being started when I was starting to learn Python and web frameworks. And then I eventually ran into something where I wanted to do things that Django wasn't designed to do, obviously, yeah. And I started running into a bunch of stuff. And so I switched to flask. Yeah, that's cool. I know if you come from an ecosystem, where there's like, clearly one choice for a lot of things. You know, if you come from Ruby, you got your Rails.

15:00 And the Ruby ORM, from Microsoft, you've got ASP. NET Entity Framework, like you don't have decisions, you just do the thing. And then eventually you build your app, right? You come to Python, there's like, you know, 20 different choices at each level. And you're like, this is like the Paradox of Choice this, even though it's in some ways, it's great in other ways, like, I have no idea what to do. And so I think that can be a challenge for people as well. Yeah, but also an advantage. Once you get into it, I think your best but if you're asking the question, should I use Django or flask is to just pick one and learn enough? You know about that framework? And I think you will be better equipped to answer that question for your project. Next time you have to ask. Yeah, it doesn't really matter what you start with. Alright, before we get into more specific, so sort of a general flask question as well. Project Yvonne says since I started April Fool's joke does the core team. David and crew have any traditions around April Fool's. I thought about that. Because you know, every time somebody brings up that it was made April Fool's. I remember that it was made I overhauls. I always forget that. So I'm guessing not not to do any. Do anyone's okay. Don't have like a birthday party or anything or celebration. Maybe we should bring it up to the community team. There you go. There you go. I think you put out a blog for last year 10 years, didn't you? That was quite a good celebration. But I think that was about it. Oh, maybe it? Yeah, it's been 10 years for a lot of libraries at this point. Yeah. Very cool. So let's talk flask 2.0, you know, it's been a couple years it went to one Oh, it was on the zero over train, like so many projects were before then. Right? That doesn't really mean that it was such a huge transition. But there's a lot of stuff changing. Not necessarily in a breaking way. But a lot of new things. And flask to give us the exciting news. Well, the biggest one is probably Async. I love Phil talks about that.

16:47 Yeah, there's like a async for flask directly. And then like maybe tighter integration with Quart type of next level async, right. Yeah, exactly. So with flask 2, you'll be able to write async route handlers, depending on what you like to call them before and after request handlers and teardown function. So it won't require any special effort other than installing flask with the extra support, but then you can just write async and await and carry on with your current setup. You don't have to change anything else. Yeah, that's super neat. And you actually gave a talk may 1 or something 10 days ago, what was it called? It was why isn't flask async? And yes, obviously, that's like leading into where things are going. You want to tell people a little bit about some of the ideas there. You talked about the history, obviously, flask being a whiskey or wsgi application. Those are all naturally having a hard time moving to async. Because, right, the server itself needs to know. But then you also talked about some of the things that are happening to allow some async stuff to run directly without any server changes. And then also moving to an ASGI server. Yeah. So what's the story there? So yeah, so obviously, flask started as a WSGI framework. I think it was probably WSGI from the start. Right. So yeah, I know. Yeah. I can't quite remember what whiskey is introduced. So yeah. And obviously, before async await is introduced, we have all these different servers. And I don't want to have just this framework run on that server. So WSGI born, right. But born in a world where async was less common. Yes, but what it has supported the whole time. And I think what's good to point out is flask has been async, the entire time just using green nets. And a lot of people use that very effectively, I think it's absolutely fine. And that, for us, I think was one of the key things to bear in mind that plus works Async in , if we introduce async await, we can't be breaking that at the same time. So that was one of the big constraints really. And then. So for the one side is keeping support with these existing async solutions. And the other is introducing the async await keywords which I think everyone has heard of the color problem and the virality associated with that, which makes it actually really hard to get a little bit deep into the call stack, if you will async without really having to change the whole call stack to async in one swoop. The other challenge, maybe I'll try to give a little bit of background just for people listening is if I've got some low level data access library or service access library, like h using HTTP x or something, in order to await the thing at the bottom, that has to be an async method, the next level up in order to call that method, it's got to be async. Then you got to await it to its methods got to be async. And it just it goes up the entire call stack in a lot of cases, right? Yeah. So what it came down to and what we what we did was follow Django what Django have already done really. And what they they've figured out is that you can run the async event loop in one thread than the greenlit based one or whatever you're doing previously in the main thread, and then everything coexists nicely you just need these wrappers to to move things from one thread to another. And that library if you're interested is called ASCII Ref, but using that allows us to have this spacing

20:00 code in the View handler, keep flask synchronous in the rest and keep support with green, which is really nice. Yeah, that's really nice. And in production and a lot of the servers, it has threaded modes already that if like, you're awaiting something, and then that something talks to a network, like a database call, or a web service call or something, it's going to release the GIL anyway, and the other threads can run. So that can probably push out pretty far. Just on its own. Right. Yeah, it's I think, has been very effective to a lot of companies. I know companies that use it, I think it'd be really nice. So yeah, that's what we've we've got to and I think you were talking about, where can we go? Can we go fully async and ASCII with flask? And this is possibly more of my personal opinion, I'm not sure it is possible to go there with flask. Because I think if you do, say your end up breaking extension support, because it's quite common for extensions to extend the flask class can change the methods, but of course, they won't be async. So how are they going to deal with that? Yeah, there's the compatibility problem. And then there's also just the problem of having mark, everything is async. And await if you mark one thing, and we might discover I'm a little more optimistic than Phil, but I'm also not as experienced with it. But I would like it to be possible, like at some point for us, you know, we're focusing on like making a 'Werkzeug' stands IO. So it doesn't require blocking IO operations, when you make requests and stuff so that you can use it in a ASGI situations. And that's gonna be a slow process. We're not like 100% done with it or a thing like that. But my hope is that as we make 'Werkzeug' suite completely, like IO, agnostic, we might discover some ways to adopt flask. Yeah, but it's also not 100% necessary, because Quart exists also.

21:46 That's an interesting point, maybe there's a way to implement some of those extension, the SU The problem is the extensions override certain functions that are part of the lifecycle of requests. And those are expected to be synchronous functions, because they had been for all of time, you can't just make those async and have those extensions still work, you know, at best are going to be kicking out unstarted co routines. You know, maybe it's probably worse than that. But maybe, maybe that's what they do, I don't know something is not going to go super well. But maybe you can create synchronous wrappers around the async stuff that can grabber an event loop and run it or some I don't know, like some there could be some sort of an adaptation thing where just the sync version, maybe it's not quite as fast or something I'm not sure. As much experience you guys have, I have way less than that. Just as a caveat, I was gonna say, I think we fast too. I think this is, in my opinion, where you want to be because the motivation in my mind is you want to use some async based library. And there's there's some exciting ones out there. So I can fully understand that. And you can now in flask and it will work will work with your existing setups. I think the only reason you could want to go fully async is because you only use an async libraries perhaps or perhaps you might see a bit of performance improvement there, which isn't necessarily guaranteed, by the way. For that, though, I think this Quart, so I kind of think all the users motivations might be covered now, which I think is really exciting. That is very exciting. Yeah. And our goal is just to get Quart and flask as API compatible as possible. And they're already very, very close. But you know, moving 'Werkzeug' that and so like, ideally, it should just be a drop in like name replace, for everything to keep. Yeah, and you could probably pull it off with just the right import statement, import court as flask or something potentially almost impossibly?

23:38 No, this isn't some monkey patching in court, where you can tell everything else that caught his flask. So you can use some flask extensions we've caught by allowing Quart to visit this flask is is kind of kind of fun. Yeah, that is quite quite wild. I did see a question. Will flask break current extensions? No, our goal was still compatibility and stability. We are making major releases, and we are adding new features, but it shouldn't break shouldn't permanently break anything. You know, there might be some unforeseen in compatibility that a library needs to update for, but it's not like they will suddenly have to rewrite their whole thing. async or something like there's not if it breaks it, it's not on purpose.

24:18 To sound bad, too, but no, no, I mean, like your intention is to have it be compatible, right? Yeah, yeah. That's always the intention of these libraries. They're meant to be very stable. And sectionally, one of the things I've been working on as a maintainer, as I've been maintaining these over the years, is when I do make releases, or when I make changes, I try to make everything show deprecation warning first, and then only remove it in the version after that. So I do want to evolve things and refactor things or, you know, identify patterns that more great or that don't, aren't needed anymore. Since we're dropping Python 2 do you want to evolve the libraries, but I don't want to break anybody without warning them first. And so

25:00 There's a ton of deprecation warnings in all the libraries this time that you'll see if you're running tests. It's cool. So speaking that Yeah, I saw this really nice flask 2.0 is coming. Please help us test by statio. I don't know. If you know, maybe give him a shout out. Oh, it's me. Yeah. Is that your name? Perfect. All right. Yeah. So from you, Phil. And he said, from the change log, one of the things coming? Well, first of all, one of the things coming is Python 3+, sorry, 3.6+ only dropping two for sure. And even 3.5. That's pretty interesting. Well, 3.5 is end of life now. Yeah, it seems so new in my mind. But it's clearly clearly not that new anymore. When I first made the announcement of dropping Python 2 . 3.5 I wasn't going to go end of life until like nine months later, but I decided to I was going to drop 3.5 anyway, we won't usually, usually we're going to our plan is to try to wait for the actual official end of life's for pythons for no one. But 3.5 just, it was so much more convenient to drop it at the same time. And 3.6 is still supported. But the next versions after these will be 3.7 only because 3.6 will have gone end of life, probably by the time making your releases. Right, right. Okay, very cool. And how much the 3.5 vs 3.6? Was it just that 3.5 is going out or versus f strings? We do use f strings all over the place now. But that wasn't the reason. I mean, since we were doing 3.6+, I decided to like use f strings and all the places I don't remember. What was inconvenient about 3.5, but there I mean, I do remember there was something this was a year and a half ago. Now when I made this decision, I think async was slightly different. I mean, look, if you're switching to two, it's a chance for a nice break from some of these things either. Exactly left, yeah, I was originally like, originally 2.0 was just going to be like dropping Python 2, and making maybe a few minor changes. And then I got anxiety about making releases and breaking stuff. And so I just kept working on more and more stuff into 2.0 instead of releasing it. But because it's 2.0 that also kind of gave me the opportunity to like, identify more stuff. So I wanted to deprecate the normal, maybe or more bigger features. Yeah, but it's a perfect time to do it with such a big version number change. I want to pull out a few more things from now that I know it's Phil, Bill's Reddit post here, which got 1.3 1300 uploads. That's pretty awesome. Short format decorators. So instead of for routes or routes for you in London, instead of 'app.route', you know, specifying GET or POST, you can just do 'app.get' , 'app.post'. That's easy, but nice. Yeah, it's just a bit of syntactic sugar. Really, it's, yeah, should make it look nicer. It's going back to the ecosystem. It's something the other frameworks are seem to adopt. And it's nice to see Yeah, yeah, that's one of the big differences I've been seeing from other frameworks that they're very much like flask, they kind of put the verbs on the decorators a little bit more, so why not take it back, if you inspired them in the first place. Also, you know, blueprints, and blueprints are something I think, do not get enough attention, and love because they are so nice for organizing your code into little bits and little categories of functionality. Instead of, you know, trying to associate them all with the main app, the app. So there's some news around that for updates as well. Right? Yeah, one of the oldest standing open issues, Phil decided to just like, Oh, I can solve this. And he's like, wrote something over a weekend. I think that way to go, Phil, now it's blueprints all the way down. I'll let Phil describe it.

28:36 Yeah, it's exactly that you can nest blueprints in blueprints. So I think they kind of co-structure is really helpful, because now it doesn't have to be all in that one group plan, right? You can split over a few files and bring them in, which helps a lot. And there's other structures where maybe you want to reuse some part of something in another blueprint. So you just bring in parts. But yeah, you can just use that. And you could use the command register blueprint on a blueprint to register the blueprint. And yeah, used to have to say 'app.registerblueprint'. And they'll give you the blueprint, and that would help you build up the various pieces. But now you can. You can nest them. And they can be more hierarchical, which is great. Right? Before it was just one layer, you have the flask app, and then the blueprints. And so like each blueprint can have a prefix, but people haven't actually asked for it for a while. But it's still been an open issue. It doesn't seem unreasonable. People have wanted to, like have prefixes for prefixes. And so then you get nested blueprints, and now it's possible. Yeah. Awesome. Let me take a couple of the questions out of the first Doug Pharaoh out there. Hey, Doug, says, Hey, I'm working on a book that uses Python flask as a primary example application. When might flask 2.0 be released? And should I plan on updating the book to use it? I'm guessing Doug didn't catch the very first opening bit because you said tomorrow Tomorrow, if you're interested in following pallets news in general, there's '@palletsteam' on Twitter, and there's also 'palletsprojects.com/blog', which has an RSS feed and so

30:00 They actually have announced this already. But yeah, it's may 11. Tomorrow. Fantastic. And then john Shanahan says you right, we don't hear enough about blueprints, love blueprints? Yes, absolutely. right oh one says, in our Talk Python Training web training course, which is a flask covers, it's as fast basically rebuild PyPI org with flask is used as safe to use flask 2.0. I think so like David said, There shouldn't be any breaking changes, maybe deprecations. If you see them, let me know, I can update that. But I think it should be fine, right? Same reason that production apps work for, like example option where this is the first time we've tried to do release candidates before we've made releases. And so we actually have had release candidates up for about a month now for all the libraries where you could test your existing code with the new versions. But I think in the future, when we do this, we need to do a better job at advertising that so something will get better over time. But yeah, cool. Well, people listening now now, that also, I think, interestingly, related to both the microframework side of the story, but also the new features, like especially the async stuff, Rohit asks, which will be the most compatible databases supporting framework for flask, on one hand, like, just do whatever you want, right? But on the other, you've got flask SQL alchemy, as an extension, you've got the ability to use like Tortoise ORM. Because the async support, like there are new options, right? What do you think? Yeah, I mean, flask makes no requirement, it doesn't affect what database you use 'Flask SQL alchemy', that will have a 3.0 release similar to these soonish. I think I'm going to add a little break after this release first, but it should, it should continue to work. What's the as you know, SQL alchemy, 1.4, just released with the first async API, and they're moving towards 2.0 as well with a new API. What's the story around their their new API and the SQLAlchemy Async. Support? Yeah, Flask SQLAlchemy? Is there anything overlap in there? So SQL , Flask is compatible with 1.4? Right now, I did make a little bug fix release recently for that 2.0 is just deprecating things, so and nothing that flask SQL alchemy uses is going away. So it'll work with SQL alchemy. 2.0, when that happens, in terms of the async stuff, we might flask SQL alchemy, like the extension might have to do some thing if we want to enable using that pattern. But we might also not because it's using pretty clever use of 'Greenlet' to enable compatibility between sync and async code and flasks. async support should support that out of the box out of the box. But it's possible to extend it to do that. Supercool. Another thing I saw in the release notes was that around 'Werkzeug', there's performance improvements coming in Flask and 'Werkzeug', so we wanted to give people a little insight into what's coming there. Yeah, one of the things I think the one that got the most attention, got some interest on the Python subreddit was an improvement we did to the forum passing. So I think there's a this issue that's about five years old, saying it was a bit slow, especially for large files. And as David mentioned earlier, we were looking at moving that to be Sands IO. And in the work to do that, the original author of that issue actually came back and said, Oh, if you do this, you'll make it a lot quicker as well. And when we did that, he pointed out, we've made it about 10 to 15 times quicker than the previous form parser. So yeah, that's been sent files to flask server, it should be a lot quicker. Yeah, form data in general is faster. And then if you're uploading large files that's way, way faster than what it used to be. Oh, wow. Like multi part form upload type of files. Yeah. So if you're uploading even like hundreds of megabytes, it could be really slow in some cases. And so now you can just upload our big gigabytes ISOs if you want. should work fine. Just like streams and or something else will take as long as it takes to upload. Yeah, shut up onto the internet. Yeah, it doesn't make it worse. I see. Cool, but I don't know. I think I'm trying to think there were any other performance improvements in 'Werkzeug' I know a couple releases ago, we made a pretty big one were to our URL building, which made it like 10 times faster or something that's already released. So but it has been getting faster. Yeah, okay. We haven't measured it. I think the the work taking out all the compatibility shims. And just getting pure PY Free should should be noticeable. Yeah, sounds really interesting. All the compatibility code for Python two stuff, like literally the.com , 'compat.py' files are gone. And all the code that was calling that there's still some more work to be done on that in terms of like accepting both bytes and strings and a lot of places where it doesn't really make sense anymore. So there's still some overhead but there's a lot less compatibility overhead than there was before. But yeah, it hasn't been measured. But I expect that to be noticeable because when 'Werkzeug', and flask first added support for Python3, going the other direction, so it was Python2 only and then it became Python3, some people stuck with like really old version.

35:00 of 'Werkzeug' in class, because there was a noticeable performance degradation by adding all that compatibility code. So now that should be better. Yeah, fantastic. I know the NumPy people, they actually got a lot better. They shrunk their code a bunch by dropping 2.0 or python 2.7. And similar for you. Yeah, it's just, I mean, besides the performance improvements, it's just more maintainable. Now, I pushed really hard to drop Python 2, even before it went end of life, I started thinking about how to do it, because I never used Python2 back then. And I still don't know. So every time I had to fix something, I had to like, oh, gosh, now I gotta run the Python 2 version of the tests, and figure out how to, like make some weird compatibility Shim, you know, between the two. So it's a nightmare maintenance for like maintainers. And contributors? Yeah, I was gonna say it's probably easier for contributors as well now to come in, because they don't have to know a lot of people these days, they don't know Python to write great, exactly. They don't want to come in and like learn, you know, something from 10 years ago, just so they can keep it compatible. They just want to add the new feature. Yeah, if you somehow have like a Python 3.5 application, so you can stick with flask 1.1, you, you'll still get your application working just fine. I mean, we're not going to be supporting it, because we just don't have that capacity. But the libraries are fairly stable, you know, like, we almost never get bug reports asking us to backport something, for example, you know, I use the panda bot, like pretty much anybody who uses GitHub does, at least for security, right? I think people have become a lot more aware overall of that they should be pinning dependencies and how to do that, and how to upgrade them intentionally. And so hopefully, over time that you know, less people will be surprised by updates and their applications will continue working with the versions they work with. Right, exactly. And if you're worried about these changes, just pin it to 1.11, or whatever it is, and just let it be until you're really ready. But also, you'll get notified of any security issues that you might need to jump in and fix right. So I was gonna say is I don't remember seeing any around plascon werkzeug so I almost ever so they're pretty stable. It seems it's pretty rare for there to be like critical bugs or security related bugs reported. We get stuff every now and then. But we just make a Py release. Yeah. And Rohit asked previously about like, why would I use something like flask over say something like Django? I noticed security releases for Django more often. And I think it's because they just have so much more going on. Like they have a whole admin section with forums and input. And you guys just, if it's not there, it can't have a vulnerability. And there's a much larger attack surface. Yeah, yes, exactly. But it's not that Django is less secure overall, though. I mean, first of all, they're releasing all these security updates. So they're staying secure, but I think they have a much larger team. And so they have the capacity to do these sorts of analysis that maybe we don't, I'm not saying like, I think flask is insecure. But it could be that, you know, they're just, they've just got more eyeballs on these things. Fuck, like noticing like, Oh, yeah, we shouldn't do this. We can make it safer. Or something like Yeah, yeah. And I just think the surface area is so much larger. Yeah, it's bound to happen. Maybe someday we'll be in that position for flask to

38:14 Doug says, oh, man tried to get into Django, my new job, so much magic, too much magic happening there for me. But he also has a question that I think maybe you know, Phil, you spoke about in your presentation, like, does this release change how you run in production, like Unicorn versus micro whiskey, versus who knows what hyper corn, the good thing to say is that, no, it doesn't change at all, it still works the same. And you can still use the unicorn and use the async capabilities. Now in flask. If you wish to use an ASCII server, you can as well, you need some middleware and adapter to do it. And there's some examples in the pipe in their flask docs, if you want to see which one we recommend. So you can choose any server. But yeah, very important for me to point out that you don't have to change anything, you can just carry on as before. Yeah. So if you want, how would you categorize you, you actually, in your talk spoke about a spectrum of async capabilities. On one hand, you have flask with its decent async support, but not full, AGSI server capabilities. And then you've got core, which can be 100% ASGI. And so you kind of thought of it as a spectrum, right? Yeah. So my idea is that if your codebase is mostly sync, as you may have started, and flask is a great choice, if you want to add a bit of async here, and that's still a great choice. It's only when perhaps you want to go fully async or you've mostly async, maybe a few Sync, pieces of code that you actually would choose caught. I think they're really nice thing for the users, you can hopefully just go across the spectrum, eventually change the name, but then just continue and it is a pleasant experiences, my hope, Yeah, awesome, you should still be able to use the same WSGI servers, basically, like we've said a couple times, like, we're not breaking anything, we're not changing how flask works or anything like that. So you

40:00 still deploy it the same way. And if you do want to use an ASGI framework for summary or server for some reason, you can always use an adapter to serve a WSGI app over ASGI to you just don't get any of the benefits Really? Yeah. Hey, Doug makes a good point out there, that flask for the wind, still making g unicorn a good solution. With g unicorn, you can change the worker type, right, you can let it be the regular one. Or you can say it's dash K, for the opposite, you said change the worker type to UV corner workers, which would switch it to be an ASGI version. So you don't even necessarily have to change anything but like party, your command line for your startup of your G unicorn. And that could be the total change you have to do. And going back to a point that Phil made earlier. In the same way you could change the worker to use like Java or something. And already have an async flask, just you know, with an older version of async code, or an older implementation. Yeah. And Joe out there says I'd look at the new async IO features, but it seems from the docs that it's early days, and maybe later versions will get more async. io adoptions. I guess that's a good direction to have a quick chat about is a what's the two? Oh, is this where you see it? landing? Or do you see this as a progression? I think it's fair to say it's a it's a progression, definitely. I mean, the ideal outcome in the end would be to somehow merge flask in Quart uses be to use any amount of async and or be ASCII or whiskey and everything just just works nicely for them. Really. Again, as I said earlier, I'm a bit skeptical about whether that could be the one namespace I just call flask, whatever you need to split it up as it is now. But yeah, I think it's the start. Hopefully, we can we can keep going. Yeah, like the async stuff we've gotten there so far is for supporting the most important thing that we thought people were needing async for, which is I have some async code, where like, I'm using discord.py, for example, to write a discord bot or something. That's all async. Great. So if you want to write that code, you need to type async def, and put your code in there. Right? So we're enabling that we've got extension points to change, you know, what async IO loop you're using, like async. io versus trio versus greenback, or UV loop or something maybe or you I'm not sure if that would tie in, I feel might be able to answer that. And then like, you know, addressing things like being able to do WebSockets. And that sort of thing. We might be able to do that in flask eventually. Or that might be the place where you switch over to the court namespace. And yeah, but you're using the same API. It's just a different name. field. That's something I wanted to ask you about it. Just let you get a give a quick shout out about is the WebSocket support that you all have in Quart? Oh, yeah, as I said, I just want to say level that it is definitely support it and it just go ahead and use it. It was supports WebSockets. You did bring some of that stuff back to fix like though, because you're using Werkzeug in Quart, you needed to be able to route to WebSocket URLs, as opposed to http URLs. And so we now have a way to identify in our very sweet router, whether something is intended to be a WebSocket are not sort of changed based on the the scheme you're using. I think it's good to point out that Miguel has a kind of experimental support, I think in flask as well, for WebSockets, which is good to keep an eye on have to see how that goes. Oh, yeah, that was really cool. I don't have the I don't remember what it was called or anything. But there's like a way that g unicorn will like let you take control of the HTTP socket from an endpoint. And so within your flask view, you could like take over controlling the socket and start treating it like a WebSocket. Instead, like an upgrade type thing. Yeah. So you still are in flask and WSGI mode. So you're still like sync in terms of one worker is blocked handling that one thing, but it's pretty clever. Yeah. And Joe out there throws out that it's Miguel Greenberg, Miguel, you're talking about? Yeah, there's also flask socket. io. But this is like a more native thing where you can just do this directly in flask and certainly in the extension. So okay, cool. So yeah, super cool. All right. We're getting sort of short on time. So I want to ask a couple of questions, hit on some high notes as well here. The one of the things that I think is pretty exciting that GitHub has done, you know, get up I think continues to be pretty neat. And one of the things they've done is they've added sponsor support for projects. Has that been helpful to you all? Yeah, we've gotten quite a lot of support, or part of the PSF. And so we take donations through them. If you go to "palletsproject.com/donate", you get the PSF donation page. We've got lots of people, you know, making one time donations or scheduled, you know, monthly donations. And we're also part of tide lift, which is a commercial sort of open source support service that we're getting funding through. And we were also I mean, this isn't really a sponsor link. But since we host all our docs on read the docs, we're partnered with ethical ads, which is their advertising platform to share the advertising revenue on docs, and so we're getting quite a bit of funding. Put it towards Flask conferences. Yeah, that's fantastic. That's good to hear. I do feel like there's probably a

45:00 handful of billion dollar companies that are using flask at the core of that, maybe click that link and do a little more. But yes, no. But if you're using flask in your company, take a look at the sponsor links. Yeah, we have lots of playlists for what to do with it. Yeah, I was really happy to see get up with this in here, because like, just having like a little, you know, buy me a coffee link on the side of a page that didn't seem like it worked. I think this sort of Central way. And what's interesting is, I didn't realize that I that you could link to external sponsors, like my thought was that that sponsor button really was going through the GitHub sponsor, channel, or framework or whatever. people recommend that we use GitHub sponsors as well, because a lot of companies who are already in GitHub ecosystem have an easier time clicking that button than something external. So that's something I will be looking at, like App Store versus not apps, like vs go to our site to buy a type of integration, right? I feel like it's almost like that. I would definitely recommend it. I've sponsored some things through the sponsor button there. And it's super easy. Okay, bars. How about that? Yeah, flask is on Mars are held to the lander get to Mars. And I bet if I pull this up, let me see if I can find your user profile here. I just have to hack the URL, it's gonna have to be that way. And I go down here. Here we go. You have the official achievement Mars 2020. Helicopter contributor. How awesome is that? Phil, do you have one of these as well? Yeah, I think so. Yeah, I'm so jealous. I want one of these. Everybody who's gotten a code contribution to the repositories should have that badge. And there's been so many more people who have contributed in other ways that should have that badge. But don't maybe you should also have the Artic vault contributor, I have the article in but I turned it off a while ago, because I thought it was kind of silly. Yeah, that's like, way more. I don't know how that whole system works. But if they had archived flask, 2.0, after all, my work was like done, I'd be much happier.

47:02 They did like two years ago now. Yeah. So there's a lot of ways in which Python is being used on Mars, when the lander first landed there. And, you know, people said, Oh, look, there's the f prime library that was used to power the the ingenuity, helicopter. That means pythons there like that looks like maybe Python just trained the model and C++ was there. But it turned out the lander that went down actually, the cameras, all the different angles were controlled by Python, and then getting those images back to jpo was part of Python. And yeah, what's the story of the flask? and Mars? This is so cool. Yeah. So flask is actually part of f prime. So f prime is like their, I'm not an expert on this, but it's like their flight control software. So it's like a monitoring dashboard for everything. So they're using flask to provide like all this information about the launches and flights and landings, and get updates in real time. So I think that's where our stuff came in. But I'm sure other parts of their code are using Ginger. Or click in other ways, not necessarily through flask. Yeah. That's so cool. What did you think when you heard this every now and then I'll see like a, you know, some big thing like this f prime, and I'll, they won't have mentioned flask or anything, I'll have to like somehow have like this intuition that it was used. And so like I, I went and just looked at f prime, and I like, I'm like, Oh, it's Python requirements.txt. flask

48:30 it on GitHub. I'm like, wow, check this out. And that's super cool. Go to the dependency graph. I'm sure we'll see. Yeah, look, what number one dependency right there. There we are in flask. restful. Yeah. Something to do with API is here, right? Yeah. Cool. All right. Let's, I guess, round this out with two things. Actually, real quick, I want to take a question, I think or follow up comment from Keanu might be off topic. They say they would love to know more about how to convince a large employer to spend money sponsoring an open source project. I wish I had a good answer for this. I know, there has been thought on this, but I'm just not the best person to talk about it. Next, I would say look at tide lift their company. And their whole like job is to be that in between, between open source who doesn't know how to convince companies to do this, and companies who are using a lot of open source, but don't know how to analyze their dependencies and divide up their support. And so if you go look at tide lifts, you know, their their whole goal is to enable that sort of thing and discuss it with manage management, all that if not guys lift it, maybe tide lifts. That's not good. If they're getting me down temporarily. They're seeing that before maybe HTTP versus HTTPS connection. Oh, yeah. So that place, I do think this is a good option as well. You know, they sponsored talk python to me for a little while, and I think they're definitely trying to be creative. And that's right. They're trying to offer something to employers. That's not just put it on your charity column in the balance sheet. They're like, we don't have a charity column in the balance yet. What are you talking about? Right? So

50:00 Doing something a little bit different there, you can look at it. I think as a company as part of your recruiting spend. I think every company knows how competitive the market is. And I do think engineers do like it, what interest in what you do in the open source community and look at it in a positive light. So I think that might help. I totally agree. A couple other quick follow up questions. Olga asks, Can f prime connect to API's on earth like Wi Fi? Is there anything about this? I think it is used on Earth as well. I mean, like I said, it's like a monitoring dashboard. So it's not something that's actively running on the rover, I think, from what I understand, I think it is accepting data from sources like the rover and other systems and then displaying that and coordinating it. Very cool. And then Joe s if Armen runacres still involved with the project, any Armen is not, he's still part of the GitHub organization. And he's like in our maintainer channel on discord but he's moved on to other things, you know, he's he's working in RUST a lot and others. Yeah, my impression that he's kind of moved on to rust and it's just enjoying his time there, which, yeah, totally fine. Like people don't have to stick with one technology, that whole life, right? contribution. So that's one of the things I've been trying to do to since I became a maintainer was get more maintainers Great. So it's not just Armin and it's and then it after Armin, it's not just me. You know, I'm trying to expand it. So it doesn't matter if Arman or I are still involved. Yeah. And box of ninjas out there. It says, I need the Mars endpoint.

51:31 Yeah, I don't think they just anybody. Yeah, there's probably they don't, but often there's hard to find the endpoint. No, it just is a satellite the right time. Exactly. You can just turn over there. Alright, so I think that's probably all the stuff we got time for. But you know, thank you guys, for covering this. Let me ask you these. Last two questions we got here. You're gonna work on flask or Quart. What editor Do you use these days? I've been using PyCharm for almost a decade now. I feel like pretty much and so I started using Python. So PyCharm all the way right on. I use Emacs. Although I've used VS code a few times. If I ever record something, I use VS code. But yeah, Emacs is why I do the way I do write down the bare metal.

52:15 Cool, and then recommend some library package you all come across recently that you're like, Oh, this is super cool. People should know about x. Any ideas? I'm really enjoying using Pydantic to validate the incoming requests, like just as a data class setup. I know you can do it with different ones as well. But the syntax seems so clean just to say this is looks exactly like a data class. And I just use it to validate my incoming it's great. That's fantastic. Yeah, one of the things I've started to do is like the first line in my flask API endpoints, is to say, pydantic model = you know, class **. What does that request '.JSON', something like that. Like just immediately try to convert it to invalidate it with pydantic something I learned recently I had Jamie on the show who creates and maintains Pydantic is I didn't learn about how to show someone else pointed out to me, there's a like a secrets capability built right into pedantic that like works with like, '.CSV files', and all sorts of stuff. It's got this whole mechanism. So yeah, that the library does a bunch of cool stuff. I don't have a good answer for this, because I've been just dealing with flask itself for so long, and getting those ready. But I haven't really been exploring new stuff for myself, this just may not get enough, you can have another. Yeah. So hopefully, I get to learn about some new libraries. As soon after, you know, flask 2.0 stable, I will say at work. This isn't official yet, because we're going to, we need to write documentation. It's totally unusable right now, because it's not documented. But we've been working on a open source library called auto invent, which takes a data model like such as your SQLAlchemy models, and produces an entire GraphQL API and React front end from just the data model plus like customizations to submitted data. Now, that's cool. It's super handy. It's really cool. It's completely undocumented. So I will, at some point, maybe half a year from now announce the actual project. But if you go to an 'autoinvent.dev', you can see all our messy code right now. Nice. You got one more Go for it. Oh, yeah. So Trio, if you've not heard of it, it's a different async await based event loop implementation. And I think I really like it because the structure concurrency it introduces is the way I think the most pythonic way to do async and await Yeah, true is neat. I had to remember that maintainers name but had him on the show and Nathan Nathaniel. That's right. If they add Nathaniel on the show, and yeah, it's super cool. Like how you have dependencies between you know, this task created those tasks and you cancel one, you cancel them all. There's a lot of interesting patterns that come out of there during each. Alright, I think that's it. David, Phil, thank you. quick shout out or a quick final call to action. People want to get into flask 2.0, they want to upgrade their stuff. Maybe they want to take advantage of the async stuff.

55:00 For whatever, what do you tell them? Where do they go from here? Well look for that look for that new version releasing tomorrow or a week ago, depending on where you listen to this. Follow pallets team on Twitter, if you want to see announcements for new things. And also, if you're interested in like contributing to these projects, I would encourage more people to go on GitHub, you know, at least start the projects you're using, but also watch them, you know, watch for new issues coming in. Anybody can pick up one of these things and help out. Yeah, you know, I think star and fork are the ones that get all the attention. You know, one thing that GitHub just recently had, I know, I said that, but I just want to give a little quick awareness to people I think is super cool. If you forked a repo, it used to be you'd have to go to a line, you know, add an upstream origin. And then you have to kind of keep that in sync. Now they've added a button that if you go to a fork, and as your as unions, click a button, go sync my fork with the original now, and I think that, you know, encourage people to forget and to stay up to date a lot a little bit easier. So that's pretty cool as well. Bill, final call to action. What do you say to folks? Maybe some core focus, I think it would be go and use it and let us know if it solves your needs, if it does what you want. Yeah. Awesome. All right. Thank you both for being here. Thanks. Yep. Bye. Bye.

56:18 This has been another episode of talk Python to me. Our guests on this episode were David Lord and Philip Jones, and it's been brought to you by us over at Talk Python Training. Want to level up your Python. We have one of the largest catalogs of Python video courses over at talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription insight. Check it out for yourself at "training.talkpython.fm". Be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the iTunes feed at /iTunes, the Google Play feed at /play and the direct RSS feed at /RSS on talkpython.fm. We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at 'talkpython.fm/youTube'. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code