There have been a bunch of new Python web frameworks coming out in the past few years.
Generally, these have been focused solely on Python 3 and have tried to leverage Python's
new async and await features.
However, these frameworks have come with their own new APIs.
They may be amazing, but it's still something new to learn and a barrier to migrating over
to them and between them.
That's why when I learned about Cort from Philip Jones, I was excited.
It's an async-enabled web framework that attempts to be 100% compatible with Flask,
including the extensions.
This is Talk Python to Me, episode 147, recorded January 18th, 2018.
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.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is brought to you by SmartKets and Rollbar.
Be sure to check out what they're offering during their segments.
It really helps support the show.
It's that conference time of year, everyone.
There's actually a bunch of interesting things happening around Python conferences.
So let's do a quick update.
First, we'll do this chronologically.
First, Pi Cascades is happening in Vancouver, BC, January 22nd and 23rd.
I'm going to be there.
So if you are one of the lucky people to have actually gotten a ticket before they sold out,
hope to see you there in Vancouver.
Next, we have Pi Colombia in Medellin, Colombia.
This is February 9th, 10th, and 11th.
So if you're in South America or want to go to South America and would love to go to this conference,
please check out the Pi Colombia conference.
Those guys are doing cool stuff down there.
Next up, PiCon Slovakia.
This is March 9th to 11th in Bratislava.
And I'm actually going to be speaking there and doing a workshop.
If you're in Europe and you can make it to Bratislava in March, that would be awesome.
Please come say hello or attend one of my talk show workshops.
And finally, the big one, PiCon US in Cleveland, Ohio, May 10th.
I personally just finalized all my travel plans.
I hope to see you there.
There's still tickets available.
They're not yet sold out as far as I know.
So hurry, hurry, because just like Vancouver, they will sell out.
We're also going to have a booth with lots of cool giveaway stuff there.
So please stop by our booth and say hello if you make it to PiCon US.
All of these conferences are amazing.
And I hope you can make at least one of them.
Now let's get to the interview.
Phil, welcome to Talk Python.
Thank you.
Hello.
It's great to have you here.
I'm a big fan of asynchronous programming.
And I consider myself really a web developer at heart.
And so this project that you are creating is really, really interesting to me.
Port, kind of an asynchronous version of Flask.
And we're going to get into all the details in that and really dig into it.
But before we do, let's start with your story.
How did you get into programming in Python?
So I got into programming to really to make games when I was a teenager.
The first one was specifically was to try and make my own version of Cannon Fodder, which
I quite enjoy playing around my friend's house.
So that's how I got into it.
And it was VB originally for me.
VB, like VB6 type of thing?
Yeah, I think it must have been.
Yeah.
Or like the Microsoft Visual Basic, right?
Yeah.
Oh, yeah.
Very interesting.
That's a long ways from the web.
Yeah, definitely.
It is cool.
So you started out in Visual Basic and created that.
And that sounds really fun.
Where'd you go from there?
Originally figured of doing computer science at university, but I did physics instead.
But over the time, I got more and more into coding.
And by the time I did my PhD, that was quite heavy on the simulation parts.
And later on in the postdoc, I switched, roughly speaking, from C++ to Python.
So I'm reasonably new to Python.
But that's the kind of overview of how I progressed in the languages.
Oh, yeah.
Really cool.
What was your PhD focus?
It was background rejection in neutrino experiments in Canada.
And the simulation of the experiment itself.
So a lot of physics simulation.
Oh, yeah.
That's cool.
And of course, computation is really front and center in that kind of stuff, right?
You can't really explain it anymore without the Monte Carlo simulation.
It's too complex.
Yeah.
Monte Carlo simulations are really amazing.
They seem like magic to me.
Here's the thing that'll take a month.
Oh, but we can do it in five minutes.
Very cool.
If you're willing to accept a little uncertainty, we can do it really quick.
All right.
That's cool.
So what do you do day to day?
Not still physics simulations, right?
No.
I left physics about three years ago now.
I work for a company called Smartkits in London.
And they're a betting exchange or event trading exchange.
So ideally, we become like the prediction market.
So you go to figure out who's going to win an election, for example.
That's what we want to be.
Oh, that's really cool.
So probably a lot of website traffic.
Do you have APIs and stuff people can consume?
Exactly.
So we build the website and the API to interact with the exchange to allow people to trade.
So yeah, it's quite heavy on Python.
There's some JavaScript and some Erlang as well.
Erlang.
Okay.
Very cool.
That sounds like a fun thing to do day to day.
And it's not that far removed from this project we're going to talk about.
So I kind of want to start the conversation and set the stage by just talking about
asyncio in general.
So this was introduced in what?
Python 3.4, right?
I think so.
Yeah.
I think it was the Tulip project before then, which you could use with Python 3, I think.
So yeah, I think it came in the standard library in 3.4.
All right.
So what's the main idea behind Async IO?
I think it's about trying to utilize the CPU as much as you can.
So instead of just being idle while you're waiting for IO, you've switched to something
else.
You gain the concurrency that way.
To me, that's what it's about.
Yeah.
I think one of the real interesting things is web requests are so often waiting on other
things.
Like at the web server level, at the web framework level, a request comes in and it says, hey,
I'm this user.
I care about this data.
What's the very next thing you do?
You either call a microservice.
You maybe find it on disk or you go talk to a database.
Regardless, that whole process is just going, and I'll just be here for when you need me
waiting for you to get back to me on that data so I can give it to the user, right?
Yeah, exactly.
And so if you could somehow say, well, let's pause that until that bit of work has an answer
back from the Async IO, from the IO conversation, right, to the database or whatever, and let some
other part of code that's going to run, run, so it can then begin to wait, you know, a lot
of hurry up and wait on the web server.
And so the Async IO basically means if you're waiting on IO, that same thread can be processing,
can release the GIL and be processing other things, which I think is especially important
in the web world.
I think it goes a bit further as well.
Like if you compare it to say threading, which is another way to achieve the same thing in that
it's obviously a coroutines are much more lightweight.
So you can handle many more of these requests at any point in time than you can with threads.
So that's the other part of it that makes it really useful for web servers.
Yeah.
The lightweight part is really, really interesting.
I mean, anyone who's sort of worked with a generator, it's kind of, kind of like that.
And threads themselves have all sorts of overhead that comes with them, creating a thread, destroying
a thread.
So maybe you put them into a thread pool, but threads themselves, they have context switches
at the kernel CPU level.
They may mess up the cache, right?
The L1, L2 cache.
And so then they kind of can wreck performance as you cycle between the threads.
You know, the cost of a thread varies by operating system, but they can have like a meg of stack
space allocated to them.
There's all sorts of things that limit how many you can have.
So you can have a 10, no problem.
A hundred, no problem.
A thousand starts to, you know, maybe push the actual memory limits of your computer.
With these, the sort of asyncio stuff, you can have many thousands, which is, I think, really
awesome.
So maybe give us a quick comparison to this concept with like Eventlet or GeoVent.
How are they similar or different?
So I think Eventlet and GeoVent are the ones you typically use with Flask at the moment.
And I think Eventlet is roughly started out as a fork of GeoVent.
So they're similar in principle, those two.
And they're all three, including AsyncIO, are very similar in principle.
They're an event loop that runs tasks or greenlets or coroutines and allow yielding when there's
IO.
But I think the crucial difference and what AsyncIO, I think, does differently to all the
choices I've seen so far is that it makes the yielding explicit.
You have to write the await keyword.
And that fits the Python philosophy a lot better.
Obviously, explicit being better than implicit.
And I think it makes it a lot clearer to the user because you now know when these changes
are going to happen.
And you get a feeling that you're actually writing these yields in your code rather than
there's some magic in the background making it happen.
Right.
Exactly.
That's very cool.
So basically, anytime you're going to call one of these Async methods, you say await.
And that signals to the runtime to say, now we're going to give up this execution and pause
until this IO or this event completes.
Go on.
And you sort of really clearly know and call out where things are going to sort of pause,
at least for that request, but also yield the execution.
Right.
I think it was probably a little clearer before they introduced the Async and await keywords
because you'd write an explicit yield to actually yield and a yield front to just switch control
to your next coroutine.
Whereas just with the await keywords, you could await a coroutine or await something that does
yield, but it's not quite clear as much.
But still, you know that that line could possibly yield, which makes it a lot clearer.
Yeah.
That's really cool.
So one thing that you've talked about is this AsyncIO color problem.
What's that?
I can't remember who termed it as such.
Yeah.
I certainly copied their choice because you could imagine coloring certain colors red and the
red functions call other red functions and other functions black and the same applies.
And the red functions would be coroutines asynchronous functions and the black ones just use synchronous
ones.
So I think that's where the naming comes from.
But the basic problem part of it is that the explicit design forces you to only be able
to trigger coroutines asynchronous code from coroutines.
So if you have a synchronous function, your standard Python function, it's quite hard to run a coroutine.
Right.
And that's one of the hearts of the problems of why so many popular web frameworks don't
just enable async.
Right.
Because it comes in through this WSGI interface.
It calls, you know, the one function that is in that API and it starts out synchronous.
And so there's really no layer, no place where you can sort of inject that easily.
Right.
Not only is it viral in nature, as soon as you want to await something, you need to be in a
asynchronous in a coroutine to do so.
To also call that coroutine, you need to be in a coroutine again.
So you go all the way up to the event loop that inevitably runs your coroutines.
And WSGI, at least in its current form, doesn't have a concept of event loop.
So it's not having that.
It's also not going to do the IO necessarily in a way that's going to yield to any event loop
for you.
So even if you introduce it later on, you're not necessarily getting the full advantage
of yielding on the IO.
You basically have to block and wait to give the request back at some point, or you're going
to get ahead of yourself.
And that pretty much cancels out all the benefits that you had.
So your project says, we're going to take this and we're going to start from this asynchronous
level.
One thing I do want to call out, and I can't quickly look up where it is, but there's this
great article by Christian Medina that says, it's titled something like Controlling Async
Creep.
And he talks about this problem, this asyncio coloring problem, and different techniques
you can have to sort of create boundaries or whatnot.
Very, very interesting article around this idea.
But let's stay focused on this.
So maybe before we get into how people work with Flask, I feel like the Flask API is showing
up everywhere.
For example, I just recently did a show on Flask Ask, which is like a Flask API for writing,
say, Echo Dot type voice interactions.
And you just write it as a Flask app, and it just magically plugs into that whole framework
from Amazon, which is really cool.
So why do you think Flask is so popular?
That does sound really cool.
I think it's a very clear and concise API to use.
I think if you're a very simple example that hello world with the decorator saying this
is the root and this is the view function, I think you couldn't get an API clearer than
that for a web framework.
It's so concise and nice.
And I think the design choices Flask has made as a whole just really kind of emphasize this
usability.
So it might be the request object being a global, for example, just because you're going
to use it that way, it makes life so much easier.
And so I think this and the familiarity of that API is what kicked it off.
And then I think that enabled the really strong community around Flask that probably makes it
really popular today.
So the great blog posts you can find, especially effectively the large blog post I think everyone
starts with from, I think, Michael Grinberg and the extensions on Miguel.
Yeah, Miguel Grinberg.
And he just, he's actually redoing that one for Python 3 and modern Flask and all that.
So like he's halfway through redoing that, which is really exciting as well.
Yeah, I'll be sure to link to that.
I agree.
I think there's also so many plugins you can get to sort of extend Flask, right?
There's extensions for almost anything you could want to do.
Let's talk about this for a second.
What if I have a Flask app, standard Flask, not Quart or anything, frequency like that, and
I want to do something asynchronous in it?
Like, let's say I want to do WebSockets, which are basically permanent connections, right?
That can't easily be done synchronously in sort of a request response style.
So how would that go?
Can you do it?
Yeah.
I think typically at the moment you'd use Gevent, at least the two popular ones, which
is Flask Sockets, the popular extensions, and Flask Socket.io, I believe use Gevent under
the HUD.
And you do need the event loop really to make it possible.
And with those, it's actually quite easy.
I think you just add that extension.
It takes care of the rest for you.
And you can just decorate a function that you say is a WebSocket root and deal with the WebSocket
directly.
It's very easy.
I see.
So does it basically like hand it off to that processing to just run asynchronously on its
own?
Well, if we take the Flask Socket example, what that does is it'll wrap your Flask app
in a Gevent whiskey server and introduce the WebSocket at that level.
So a WebSocket request coming in would be handled before it gets to Flask, although it looks like
it's going to Flask, but it would be handled beforehand.
And then everything else would just go straight through to Flask with the whiskey interface.
So yeah, it would work that way.
Yeah.
Nice.
This portion of Talk Python is brought to you by SmartKits.
And they're looking to hire someone to write some really awesome Python code.
SmartKits operates a world-leading exchange for peer-to-peer trading on sports, politics,
and current affairs.
As a business, SmartKits is widely recognized as one of the fastest-growing tech companies
in Europe and has won a roster of awards for its success over the past few years.
Headquartered in London with a new tech hub in downtown LA, the company is pioneering a
self-managed organizational structure.
This breaks down the traditional pyramid of hierarchical silos into a more fluid and
flat network of interlinked teams who are engineers of the driving force.
They're no formal bosses.
Staff are allowed to set their own salary, have unlimited holiday, and work where they like
within the company.
Over 60% of the staff are engineers who work on a modern tech stack predominantly based on
Python, complemented with Erlang and JavaScript.
SmartKits uses Python 3.6 throughout and deploys dockerized microservices multiple times a day.
Apply to work at SmartKits by visiting talkpython.fm/SmartKits or just click the link in
the episode notes.
Suppose I want to have some Flask view method and it's going to say call a web service.
It's going to talk to a Postgres database, for example.
There are asynchronous ways to do those things, right?
If I have AIO HTTP client, that's a really nice AsyncIO friendly way to call remote services.
And I could use the Async Postgres driver there and call that.
But with straight Flask, I can't put like Async on my methods, right?
Or await in it and really get it to honor that, could I?
I don't think so.
There was an extension called Flask aiohttp, which I think is no longer maintained.
But that, I believe, used the WSGI interface that aiohttp provided, which I think is also
deprecated now, sadly.
But that would allow you to fairly easily, I think, make your Flask view functions async.
But it wasn't, I think it had some issues whereby the locals, the requests, gee, those request
locals would get corrupted or could get corrupted.
So I think that kind of ruled it out.
Yeah, that doesn't sound amazing, right?
No, no, you certainly don't want that.
There was also a fork, a Flask I found that did make the view functions async.
It was designed around async AO for 3.4.
But I haven't quite tried to figure out how it worked or if it worked, but it hasn't been
touched for about three years.
So I don't think that's maintained either.
Right.
And so this maybe brings us to your project, Quart.
All right.
What is Quart?
So Quart is a web micro framework, much like Flask, based on async AO and the Flask API.
So the aim really is to provide the easiest stepping stone from someone who has a Flask
app or Flask knowledge to use async in that app or in a new app with that knowledge, basically.
So yeah, it's just a web framework, web micro framework.
Nice.
So you decided instead of, because there are other asyncio frameworks that have come
around, Sanic, Chepronto, others that we can talk about later.
But generally they said, we're going to come up with a new way to program the web and we're
going to sort of do it around this asyncio thing.
And you said, look, Flask is super popular.
It has this API that people already know.
People can go and take Miguel's tutorial and learn about it already.
But you just want to have it work with asyncio, right?
And so we're going to start from there, right?
How much did you borrow from Flask and how much did you have to start from scratch here?
I've tried to borrow the entire Flask API and quite a bit of the Verkser API, which is
the part under Flask that powers most of the HTTP stuff.
I've tried to borrow most of that as well.
So yeah, a great deal, hopefully.
What I'd really quite like is if you have a Flask app that doesn't use any extensions, you
can just find, replace Flask with Quart and then add the async and await keywords and it
just runs.
That's what I'm kind of aiming for.
That's great.
And how close is it to that goal?
I think it's quite close.
I think it's really the details now.
So for example, I need to work on the e-tag handling, how they're applied to static files
and stuff like that.
And subdomain handling in the routing system.
I think those are real details that I think most of the use cases, it should be possible
to just do that now.
To just, as in, find, replace.
Oh, that's awesome.
You could go like grab Miguel's tutorial and just, I don't know, what's the verb of making
it run on Quart?
Quartify?
Add Quart capabilities to it, right?
That'd be cool.
Very cool.
I guess one of the first questions is why not just fork Flask and just tack on the little
bits of asyncio handling that you need?
That would be ideal.
Well, but at the moment, at least, it's beyond what I'm able to do.
And I think it goes back to the Whiskey interface, which really isn't asynchronous.
So, again, like if you really want the event loop to be able to get the yield on the request
IO and the response IO, you need to be controlling that part.
And so I think you have to go start from Flask, go up to VerkSug, and then almost go up to the
WSGI servers themselves and make them asynchronous to really, well, I think IO compatible to really
make it possible.
And, yeah, I could really make that work.
It was quite hard.
I know a lot of people have tried and they've talked about adding like a Whiskey 2 or various
acronyms with A involving in there to basically asyncify that API.
But there's really not a lot of flexibility in there.
And the actual Whiskey API, which is what all the web frameworks use to plug into the
various web servers, right?
I want to run on MicroWSGI.
I want to run on Genicorn or whatever.
They all speak Whiskey.
So you can just plug Pyramid, Flask, Django, whatever in there, right?
One of them I was looking at is ASCII, which I think Django is pushing.
So I think the idea there is you just push out the messages to a queue and then you have loads
of things consuming it in an asynchronous fashion and then returning the results.
I don't think it would quite work for Quart either, but they seem to want to.
I think they're trying to suggest that as the next step for Whiskey.
Like it becomes ASCII.
Yeah, yeah.
That's one of the acronyms I was thinking of.
So how do you add on things like WebSocket support or HTTP2 pipelining where you can make
a request and actually through that in single network request punch like three CSS, a JavaScript,
an image, an HTML file response as one.
Do you think they could make that work there?
I think so.
Yeah, because each request could just be a separate message on their queue and then something can
consume and produce the output and send it back.
So I'm sure it would work for them.
Maybe you could somehow bundle up the multiple responses or something at the framework level
and then send it over to the network.
I don't know.
It's yeah, it's going to it's going to be pretty interesting with all the HTTP2 stuff coming
along and whatnot.
Oh, definitely.
I think HTTP2 is one of the most more exciting things I'm interested in.
And I'm very pleased that Quart can do it.
So it's very good to play with.
It can.
That's really cool.
So how much of that is the framework and how much of that is, say, just the server it's
running on?
Say if you run on G Unicorn, right?
How much is G Unicorn doing versus how much of is Quart actually doing to make the HTTP2
supported?
In a traditional sense, the WSGI server does all the HTTP passing and just passes through
the environment.
But for Quart, how it works with G Unicorn is we just use the socket.
So G Unicorn doesn't actually do any HTTP passing.
It all goes through to Quart.
So all the HTTP2, the HTTP1, it's all taken care of in Quart.
And we just pipe it back out through the socket that G Unicorn's provided.
Give us a sense around the kind of performance differences that people could expect.
If they, say, have a standard Flask app running on G Unicorn now, if they flip to using Quart
also on G Unicorn, what do you think happens?
I actually did a, I think you're going to link an article I did to look at this.
And I looked at a kind of production use case where you have a simple CRUD app with a database
in the background.
I used G Unicorn with eventlet.
So it was asynchronous, fairly similar type of work load pattern and the way it approaches
the problem.
And I compared it against Quart.
And I think with Quart, I got something like a free time throughput speed up.
So the latency or the request time itself didn't really make too much of a difference.
But the amount of requests it could handle at once really increased.
Yeah, that's really cool.
And I would guess that you're probably were not working with like a super slow database
or a tremendous amount of data in your simple test.
But it seems to me like the worse the database performs, the more beneficial having this asynchronous
thing could be to sort of free up the waiting.
The waiting, the worse the waiting is, the more beneficial is to have async methods.
Although that should apply to both sides of the test because eventlet would do the same
in the flask sense.
Right.
OK, yeah.
So if you're already switching to eventlet, then it would.
Have you thought about this relative to a non-async flask, like just a standard flask, if you're
not using eventlet?
Yeah, it makes a huge difference then because your requests effectively become synchronous.
You have to do one at a time.
So unless I suppose you used threading.
I haven't tried threading, but assuming you've got no asynchronous aspect at all, then it would
make a very large difference because you would have to finish the one request before you could
even start the next.
That's for sure.
How interesting.
OK, so you talked about flask and I said one of the benefits of it is these flask extensions,
right?
There's a bunch of stuff you can plug in.
Does Quart support flask extensions?
Supports a good fraction of them, I think it's fair to say.
So this goes back to that color problem we mentioned earlier, because, of course, all the
extensions are synchronous.
They have synchronous functions.
And inevitably, they're going to try and call some code that's now asynchronous in Quart.
And that's where it becomes a problem.
So I can go in the details of how it gets around that.
But that's why some of them work.
Yeah, that'd be kind of interesting, right?
Because people are going to pip install these extensions and generally not change the code.
And until your framework is popular enough that people are creating sort of async equivalents
of their extensions, you have to make these, you have to blend the colors, right?
So how are you doing that?
It's quite fun to look at.
It took quite a bit of time.
So if I go back to how you run a coroutine, you need to run it in the event loop.
And if you're outside of the event loop, it's quite easy.
You just either create or get an event loop and tell it to run a coroutine.
And it's all very good.
But if you're in a function that's been called by something within the event loop, you can't
do that.
The actual async arrow function run until complete, for example, will refuse to run because you're
inside the event loop.
And it turns out this was known back during the tulip days.
And someone proposed a solution to this, which was to actually run the event loop again within
the event loop to run this particular coroutine.
And I think it was rejected because it just made things quite complicated and wasn't a particularly
useful use case.
But in this case where you've got legacy, well, you have synchronous code, trying to call
asynchronous code is exactly what you need to do.
So what Quart will do if you want to go down this route is monkey patch the event loop to
add a method to run the event loop, if you like, manually for a coroutine that you specify.
So it will suspend the event loop it's already in, run it itself, and then restore everything
after it's complete.
So it probably sounds a bit messy.
So it probably is.
It sounds like it could create this cascading chain of nested event loops going down and
down and down.
Yeah, probably so.
But it does allow like these extensions with a synchronous call to another function to be
able to call an asynchronous function without them being able to tell.
There's just a layer in between that does this kind of mapping from sync to async.
That's really cool.
I'm very creative.
So you said it works for most of them.
When it fails, what happens?
Like, why does it not work?
Do you remember?
So Flask has these request locals, like the request object or the G object.
And when you try and do anything with them or access any attribute of them, it effectively
proxies that action to an instance that's local to the thread or greenlit that you're on.
And I hope that makes sense.
It's proxying, basically.
So what I can do in Quart is I can, during that proxy, also take it from a synchronous call to an
asynchronous call.
So that works really well for these local proxy objects.
The problem is when an extension uses the Flask class itself, like the app, because I haven't
figured out a way yet to effectively proxy the call and convert it from synchronous to asynchronous.
So if the extension just uses these globals, it's good.
If it uses the app, I need to be a bit more clever.
Hopefully you get that puzzle figured out, because it'd be really cool to have that supported
there.
Very nice.
So what template languages are supported?
You have Jinja 2?
It follows the Flask design in that respect and just does Jinja 2.
But I'm sure like the, I think there's an extension called Flask Maco.
It's quite popular.
I think that may work as well.
The question becomes whether that template in engine is asynchronous itself.
So if it isn't, you just get a bit of a performance hit.
Right.
I see.
So the Jinja 2 one supports asynchronous behaviors in directly?
It does.
It's actually, if you look at the code, it's kind of amazing how they do it.
So if you're running Python 3.6 and you ask it to be asynchronous, it will patch itself to
add the asynchronous methods.
It's, yeah, it's really quite good to look at.
Wow, that's quite awesome, actually.
I didn't realize it did that.
So I'm guessing you don't support Python 2 in this.
Is it Python 3 only?
It is.
It's even more restrictive than that, actually.
It's Python 3.6 only because I use asynchronous generators.
One of the uses being if you want to stream a response, you want to yield data back whilst
being asynchronous.
So because of that, you can't use anything other than Python 3.6 where they were introduced.
Yeah, that's really interesting.
So I feel like a few years ago, the story was, well, people can't move to Python 3 because
there's all this cool stuff that we're using that only supports Python 2.
And now I think more and more we're ending up in a situation where it's
there's all these amazing new things.
But they're only accessible to you if you're using the latest versions of Python 3, which
I think that's a good move.
The other thing it does as well, which really constrains it to Python 3 or I've used is I
type into everything, including the variables, which the syntax, well, the nicest syntax was
only introduced in Python 3.6.
So yeah, I quite like that as well.
I really do as well.
I find it makes the editors much smarter about the types of things you're actually working
with.
You can run tools and say, no, no, you're passing an answer.
You're supposed to pass the whole object, not the ID of the object here.
Things like that.
It's great.
This portion of Talk Python to Me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Relying on users to report errors, digging through log files, trying to debug issues, or getting
millions of alerts just flooding your inbox and ruining your day.
With Rollbar's full stack error monitoring, you get the context, insight, and control you need
to find and fix bugs faster.
Adding Rollbar to your Python app is as easy as pip install Rollbar.
You can start tracking production errors and deployments in eight minutes or less.
Are you considering self-hosting tools for security or compliance reasons?
Then you should really check out Rollbar's compliant SaaS option.
Get advanced security features and meet compliance without the hassle of self-hosting, including
HIPAA, ISO 27001, Privacy Shield, and more.
They'd love to give you a demo.
Give Rollbar a try today.
Go to talkpython.fm/Rollbar and check them out.
Yeah, so actually converting your Flask methods to Quart methods is quite easy, right?
You just, you have your, let's say, like a review function.
I think this is an example you have on your website.
You can say def add review data equals request.getJSON.
Or you can just say async def add review data equals await request.getJSON.
And you just add the async and await keywords and off it goes, right?
Yeah.
So I think it wouldn't be that hard to convert a small to medium-sized Flask app to Quart.
What do you think?
How much effort and testing has to be done?
I think you're right.
I think small ones should be quite easy.
What probably make it hard for people is that they're probably going to call something else,
like you were saying earlier.
If you're going to do a web request to a, or a PHP request to a microservice or something
to a database or something like that.
And those libraries are likely to be synchronous rather than async.
And while this comes back to the color problem, you're going to have to switch from, say,
psycopg to asyncpg or your py Redis to like aioredis or requests to aiohttp.
And that's probably going to be more work because those APIs are suddenly different usually.
I would think probably the Redis wouldn't be that hard.
Probably the AIO HTTP client, not such a big deal.
But I feel like when you get down to database stuff, that's where the complexity lives a lot
of times.
So maybe upgrading the database driver or package to be the async one is probably where it's
most challenging.
I don't know.
Have you tried?
Have you got some experience?
Yeah, I've played along with myself.
And yeah, it's because I typically use psycopg directly.
I don't use SQLAlchemy on top of it usually.
And that's not too bad.
It's fairly easy to change.
And it has a big bonus.
Like there's an asyncpg.
If you look at how MagicStack report the benchmarking for it looks much, much quicker, which is excellent.
But yes, if you have a lot of ORM stuff, I think you're almost stuck.
I'm not sure I've seen an ORM that's async yet.
I know that SQLAlchemy hasn't done it.
I feel like there is one out there.
And I'm hesitant to say which one I'm guessing it is because if it's wrong, I'll try to put
some notes in the show notes or something.
I've seen one that I thought allowed it.
But yeah, certainly SQLAlchemy doesn't.
And that's unfortunate, right?
So it kind of says, look, if you're going to do the async stuff, then you're kind of stuck.
I guess there's a few things you could do.
You could move your requests out, say like another thread that you wrap up and you await
that thing's response or something.
But it definitely makes it not easy, right?
Yeah.
So asyncio makes that bit reasonably easy.
I think there's a function called running executor, which will do almost exactly what you just said.
So yeah, that's probably what you'd have to do.
Okay.
So I found what I was looking for and it's actually not the ORM itself.
It's an add-on.
It's called P.
So the ORM is PeeWee, which is a sort of a small ORM type of thing.
Right.
It's, it's pretty popular.
It's got close to 5,000 stars, but there's PeeWee dash async, which is an asyncio interface
for PeeWee.
So that one, that one you can do it.
So you can basically say await objects.create or things like that, where you basically do
the queries and then you can await the response, which is kind of cool.
Oh, that is cool.
Yeah.
I didn't come across that.
Yeah.
But it's unfortunate that it's not like the most popular one, like SQLAlchemy or say the
Django one or something like this, right?
Like it's, yeah.
But if people are looking for it, like maybe you'd have to switch to PeeWee async if right
now it's written in say SQLAlchemy.
I don't know.
So what do you think?
I'm thinking about this database problem.
Like, can you take a SQLAlchemy Flask app or a MongoDB Flask app and somehow shoehorn
it in so you can still do these queries?
You don't have to completely rewrite your data access layer, but make it async friendly.
Easy?
Not easy?
I think it, in all honesty, it requires a bit of effort.
Yes.
You'd have to, you'd probably want to choose a different driver.
So you need to spend some time looking into it.
And then you'd probably have to rewrite a bit to actually make it work.
So yeah, I don't think it's all that easy.
It doesn't sound easy to me either.
Although it may be worth it.
It's definitely not going to be just a throw an async and a wait keyword here and there and
just go with it, right?
Indeed.
I think it is.
It does look to be worth it.
If you, there's some articles by Magic Stack and the way they talk of the performance they
can get through the async stuff.
It looks really, really good.
Really very fast.
Yeah.
I think it's really quite powerful, but it also probably depends, right?
Like you guys, I suspect have a lot of traffic.
If you do 10 requests a second on your server or one, maybe just leave it alone, right?
Pay $5 more and get a bigger server and just be done with it.
There's probably some threshold where below that it's not worth rewriting it until there's
enough demand.
What do you think?
Certainly, yeah.
It's, even for us, it's not necessarily worth it to wholesale replace our services with core.
I think we're only really kind of experimenting with async O systems at the moment.
Cool.
So let's compare this a little bit with some of the other, what I consider the Python 3 async
web frameworks.
So we've got Sanic.
We have Jepronto.
AIo HTTP.
Like, how do you see your work similar or different to these?
There's kind of two approaches have been taken here.
And most of the Python 3 async ones I've seen have been more the micro framework style than
the Django style.
I think there's the ones that are Flask-like, which are Sanic and Jepronto, I think.
And then there's AIo HTTP that I think for very legitimate reasons by design doesn't want
to go down the Flask approach.
So I think that's basically the first choice.
And then I think Quart fits in because it's not Flask-like.
Hopefully, it is the Flask API.
So I think that sets it aside and it's kind of the motivation for it.
So then I think there's kind of that scale.
And then there's the what is the aim of the project in that scale.
So Sanic and Jepronto, I think, are all about speed as far as I can understand what they're
aiming for.
They're really about trying to get performance out of it.
And I think AIo HTTP is meant to be kind of like an all-encompassing HTTP library, right?
So it does the client side as well as the server.
So I think there's these varying kind of aims for the projects.
Right.
And I think it is a massive advantage to say we're not going to create something Flask-like.
We're going to create Flask effectively, but async-enabled natively.
And one of the main benefits there is obviously people can migrate more easily to it.
You already talked about the Flask extensions, all those kinds of things, right?
To me, it's mostly about not having to learn something new.
So I did play with Sanic.
I quite like Sanic, but I didn't want to have to learn how Sanic did things.
Yeah, exactly.
And if you want to go on Stack Overflow and ask, how do I do this with my web framework X?
You'll have way more answers if X equals Flask.
It's true.
Definitely.
Yeah.
Just the more tutorials, more courses, et cetera, et cetera.
Although I suspect there's minor differences.
The majority of it is kind of still the Flask API, the Flask story, right?
Certainly, there is differences in the details and obviously async.
Yeah.
So what are the hangups people might get trying to switch to court?
Are there things they have to be on the lookout for just due to the async nature or how careful
they got to be?
I think one of the most annoying parts is if you have a coroutine.
Say you want the example you said where you await the request.getJSON.
If you forget to write the await word, then the data, let me start again.
If you have data equals request.getJSON in your Flask and you change it to Quartz, that line
of code will still run.
It's just that data would now hold a coroutine object instead of the data you're expecting.
And that could probably catch you up quite easily because until you try and use it, you
don't know that it's going to be something different.
What do you mean status code doesn't exist anymore on this thing?
Like, why did this start failing?
Why are the attributes missing, right?
Of course, because you didn't await it.
Yeah.
Interesting.
So let's talk about the deployment story.
You talk a lot about using G-Unicorn.
Is it, you said you can basically run both Quartz and Flask apps on top of that in more or
less the same way, but just different config settings, right?
Yeah.
You just change the worker and that should be enough.
Nice.
Yeah.
So you say eventlet is the one to use for Flask and Quart-UVloop for Quart.
UVloop's pretty interesting.
Why don't you tell people about that?
My understanding, which I think is wrong, is that the kind of history goes from libEvent
to libEvent, which is what eventlet and gvent, I think, are based on, to libUV.
And they're all improvements on the previous iteration.
And UVloop is the kind of Python bindings to change the async loop policy to use UVloop
instead of the default one.
And the reason you'd want to do this is because it looks like, from all the stuff that's been
published, that UVloop really does make things run a lot quicker.
And if I understand it correctly, it's the same kind of base event loop that Node.js uses.
So it's got some proven track record of being very good.
So yeah, if you switch it to the UVloop worker, you can really get some performance boosts.
I get the same impression reading around that UVloop definitely speeds that up.
And it's cool that it's the same one that Node.js runs on because Node.js, for all of its flaws
and challenges, is definitely good at handling lots of requests based on IO completion waiting
behaviors, right?
Yeah, definitely.
I find it kind of amusing if I've understood the history right, is that UVloop is a rewrite
of EV, LibEV, LibUV is a rewrite to work on Windows.
At least that was the original motivation.
But as I understand it, the UVloop kind of bindings doesn't work on Windows.
So I find that kind of like sad irony.
That is very ironic.
It's turned its back on its origin.
How interesting.
So have you talked with Armin Roedeker, the guy who maintains Creative Flask, about what
you've done, how it maybe could be contributed back to Flask, what those guys are up to, things
like that?
I haven't, no.
I was actually hoping, because I think you've spoke to him on this program.
I was going to ask if you could introduce me, which would be excellent.
Yeah, I'd be happy to.
Sure.
Yeah, I don't really know what's going on in official Flask around all this stuff.
So it seems like you've got a really nice head start.
So that's cool.
I don't know what's going on officially for Flask either, but it doesn't look like they're
actively pursuing AsyncIO at the moment.
It looks like they're pursuing the release one of Flask, as far as I can tell, which would
be great as well.
Yeah, it would be great.
I suspect making major changes to Flask in terms of APIs and stuff is a slow, tedious,
careful process.
Same thing for Django and for Pyramid.
These are well-established, long-living web frameworks.
Compatibility is probably a top concern.
And I think you probably have to make some difficult changes to introduce AsyncIO as well.
So I guess my hope would be that Quart proves that this is desired and useful.
And then there's more kind of desire to actually make some Flask changes and to be able to
merge the two.
Yeah, then you'll push a major, major pull request over to Flask.
Well, it would have to be Flask and Virgisk, I think, if it's ever going to be possible.
Yeah, yeah, for sure.
Yeah, very cool.
All right.
So where are you going in terms of the future for Quart?
What's next?
I said earlier, there's details about the API that don't fully match at the moment, which
obviously I need to get correct.
So like little details about how e-tags are used and how static files are served, that
kind of thing.
After that, I want to kind of like really demonstrate the robustness of the HTTP2 handling and the
WebSocket handling.
So luckily, there's some compliance testing projects out there, which I can use for that.
And then it's also about the development process.
So Flask and Virgisk have this really nice kind of debug web page that tells you what's
going wrong when you try and do something.
I think Quart needs something like that as well.
Sounds very cool.
One of the areas of performance that we spoke about was with Async and Await and sort of
the asynchronous view.
We also talked about HTTP2.
How do you see that affecting performance?
Do you see like the ability to have HTTP2 also adding like another layer of speedups?
I do see that it makes things quicker when I test it.
I haven't published anything yet because I haven't really figured out what a kind of safe
comparison benchmark is because the cost of opening connections is quite high.
Maybe you should include that.
But you could effectively pipeline your maybe 20 connections down one and get a big difference.
But whether that's fair or not, I'm not sure.
So I don't know how to talk about it in a fair way.
It's really precarious to publish benchmarks.
Yeah, definitely.
No matter what you do, there's always someone that's going to show you how you're wrong.
And usually what that means is you're wrong because I use it this way and you're measuring
it that way.
And if I used it the way I use it, it wouldn't give you the same results as the way that you
use it.
And so your results are misleading or whatever, right?
And it's just really hard to get something truly representative of what people are doing
when they're doing all these different things, I think.
One thing I'd really like to do if I could convince my colleagues is change one of our edge
servers to be HTTP2.
And then you'd be able to see quite a big difference in real use cases.
So that'd be excellent.
Yeah, well, let us know when it's out.
I'll definitely point people at it.
That'd be awesome.
It would be.
Yeah, yeah.
Very cool.
So one thing I noticed is you have your project on GitLab and a lot of people have their projects
on GitHub.
And you've talked about this a little bit.
So why GitLab over say GitHub?
Initially, it looks a bit silly because GitHub is way more popular than GitLab.
And projects tend to be judged by, I think, at least superficially to begin with, by the
kind of stars and forks they have, which is always going to be low on GitLab.
But for me, GitLab is open source, which sways a lot of it in my mind.
It certainly made a difference to the company I worked for when we were starting up, like
to have such a great open source project we could just use to begin with.
And the other thing I kind of like is its CI system is really nicely integrated.
And that works very well for Cort at the moment.
So it's very easy.
So Phil, if you want to work on Cort, what editor do you open up?
I use Emacs, although I think I use Emacs really badly.
I don't really add any plugins.
I tend to use it just in the terminal.
Very vanilla.
I went through a stage of having it reasonably optimized.
And I just reverted it all back to plain.
So yeah, I don't put too much in my editor.
I probably should.
But yeah, I just open Emacs and go from there.
All right, cool.
And in addition to Cort, which is pip install Cort, right?
What other notable high-PI packages are out there that you want to recommend?
I think I'll recommend two that I use in Cort.
I recommend Flacate, which has certainly caught loads of silly bugs and style issues.
I think mostly I use it to take away any discussion or uncertainty about the style.
And my-PI for the same reason of catching the bugs and to make sure the documentation is right.
Yeah, my-PI is very cool.
There's a lot of activity around my-PI right now.
It's really nice.
For sure.
All right, so final call to action.
People are interested in Cort.
How do they get started?
Are you looking for contributors to the project?
Things like that?
Absolutely, yes.
It would be great if people could give it a go.
Open issues or pull requests, merge requests of changes.
That would be absolutely excellent.
And hopefully it's easy.
It's just pip install Cort and give it a go.
Hopefully it's as easy as Flask.
It's like basically five-line quick start.
Yeah, that's really cool.
And you have a video that's now on YouTube from one of the PyCons, which I'll link to.
That's PyCon UK, right?
2017?
Yep, that's the one, yeah.
All right, so if people want to watch your video presentation as well, I'll be sure to link to that.
So yeah, it looks like a really cool project.
Thanks for creating it and coming on the show to share it with everyone.
Thank you for the insight.
Of course.
Talk to you later.
Okay, bye.
This has been another episode of Talk Python to Me.
Today's guest was Philip Jones, and this episode has been brought to you by SmartKits and Rollbar.
SmartKits is looking for talented Python developers to build amazing Python 3-based microservices.
Apply at talkpython.fm/SmartKits and level up your career.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my WritePythonic code course at talkpython.fm/pythonic.
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.
I'll see you next time.