That looks nice. I think that integration is indeed the way to go. No point to implement yet another complete web stack in asyncio.
But make sure that WSGIServerHttpProtocol can also handle blocking code. Most existing Flask applications still have blocking ORM code, and you don't want such code to block the event loop. I think it should run every request in an executor, and when the response_class is a coroutine, it should start executing that in the loop. btw. Instead of inheriting from response_class, you can also use instancecheck [1] if it is only to trick flask at that point, but of course even better if Flask supports aiohttp in the end. Cheers, Jonathan [1] http://docs.python.org/2/reference/datamodel.html?highlight=instancecheck#class.__instancecheck__ Le dimanche 16 février 2014 15:06:11 UTC+1, chrysn a écrit : > > hello python-tulip list, > > i've played around with aiohttp and flask/werkzeug/pocoo (an wsgi based > classical python web framework), and found that they can be made to play > nicely with each other easily. some features of the werkzeug framework > are sidestepped, i'm waiting for the developers' feedback to see how bad > it is. > > the demo code can be fetched from [1], the discussion on > [email protected] <javascript:> is archived at [2]. > > what are your opinions on this? if it works out, is there still a need > for dedicated asyncio web frameworks, apart from the lowest layer that > provides a wsgi+async interface? > > if the topic fits here, i'd like to keep this thread updated if relevant > information comes back from the pocoo people. > > best regards, > and thank you all for providing this cool new python base technology > > chrysn > > [1] https://www.gitorious.org/aiohttp-werkzeug-demo/aiohttp-werkzeug-demo/ > [2] https://groups.google.com/forum/#!topic/pocoo-libs/mTS1X7hfnkk > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom >
