3 ms·
Yeah I mean the async landscape for web frameworks isn't exactly as populated as the "yet another web framework" statement makes it seem. This is how we get to
by diminoten 8y ago
Yeah I mean the async landscape for web frameworks isn't exactly as populated as the "yet another web framework" statement makes it seem.
This is how we get to async Django, and I think that's part of why Tom Christie is helping out. I also doubt Reitz thinks this is the usurper of Django anyway. It's more than an experiment, but less than "the new One True Way".
As for ASGI python web frameworks, there are no mature winners in the space yet (compare uvicorn's quickstart example to this project's before you throw that project out as an example). This is Truly New Shit, and I'm pumped these two devs are working on it together.
- m_ke 8y agoAsync support is actually planned for django in upcoming releases. Here's some info about that https://www.aeracode.org/2018/06/04/django-async-roadmap/ https://www.aeracode.org/2018/06/04/django-async-roadmap/ From what I understand ASGI was developed by Andrew Godwin for Django Channels.
- diminoten 8y agoI'm super excited for that development work to begin! But just thinking about my own experiences, being able to look at what other people have done so far with it would help immensely when building the nuts and the bolts of the feature. This project will help immensely with that.
- amorphic 8y agoAndrew gave a great talk on this very topic at PyCon AU in August. Still at the formative stages it seems... https://www.youtube.com/watch?v=-7taKQnndfo https://www.youtube.com/watch?v=-7taKQnndfo
- tomchristie 8y agoYo. Yeah my (bit of) involvement is mostly around wanting to help guide the new ASGI ecosystem. For example, I'd like to see Python's async frameworks building on ASGI middleware rather than all re-writing their own middleware APIs. That way we end up with lots of cross-framework compatible middleware implementations, and we're all working together much more coherently. Similarly for test clients. We don't really need frameworks to all be building their own individual test clients to interact against their own interfaces, when we can instead build test clients to interface against ASGI, and then be able to use them against any ASGI framework. That's part of what the Starlette project (which Responder uses) is all about: https://www.starlette.io/ https://www.starlette.io/ (FWIW Starlette also composes all those bits and pieces into a framework in its own right)