Great work chrysn. Does the same limitation apply that you can't use Task
manually any more? I use them a lot in a sql driver library I'm working
on, and can see using them in other places as well.
As for the patch, give me your github account and I'll give you commit
access. I did send an email to the flask list and hopped on IRC, but
didn't get a reply in either forum. The good news is Flask-Async can work
with both sync and async Flask apps, though you do have to be careful for
things like SQLAlchemy that will block for everything. It does make me
wonder if we wouldn't be better off just forking or creating a new web
framework to make it more clear you do need async versions of everything,
kinda like Node has effectively done by using server-side Javascript.
In the meantime, I've taken Bottle, forked it, and made it work for async
apps. I did this by the usual sprinkling of yield from around, but also
rewrote all uses of thread-local variables to be explicit. This means your
handler method looks like this:
@app.route('/')
def home(request, response):
...
It seems to my Python newbness mind that explicit parameters are more
Pythonic as it matches how "self" is preferred to an implicit "this". It
certainly is more noisy, but not overly so.
Anyway, my Bottle fork is here:
https://github.com/mrdon/bottle
It also should work with normal and coroutine handler methods. Bottle
seems to have a much smaller set of extensions than Flask, which as I
mentioned, could be considered a good thing here.
Don
On Tue, Feb 18, 2014 at 6:53 AM, chrysn <[email protected]> wrote:
> hello don,
>
> On Tue, Feb 18, 2014 at 10:44:28AM +0100, chrysn wrote:
> > [... much ...]
>
> had i read the python-tulip mailing list more carefully, i would have
> seen the "ThreadLocal analogue" thread. the whole hackery described in
> the abovementioned mail can be easily avoided by using
> `asyncio.Task.current_task()`.
>
> the attached new patch is much smaller, and i'd like to propose it for
> inclusion in your flask branch to solve the "Popped wrong request
> context" problem.
>
> compared to my last approach, it might cause troubles when users create
> a Task manually -- but then again, that only happens in asyncio aware
> applications, and they can pass on the request object explicitly again.
>
>
> i'll keep playing with your flask version, it feels pretty usable. (for
> the time being, even with sqlalchemy). afaict, your patch to flask is
> very small (just some additional yield-from, and some call_maybe_yield),
> and not even the werkzeug patch is too heavy. have you tried getting an
> opinion from the flask/werkzeug developers on inclusion yet, or an idea
> on how a version that can do both (classical and asyncio) can be
> maintained?
>
>
> best regards
> chrysn
>
> --
> You don't use science to show that you're right, you use science to
> become right.
> -- Randall Munroe
>
