5 ms·

I'd argue that python needs an async django, which will hopefully be django in a few releases.

by m_ke 8y ago

scardine 8y ago
There is an async Flask in the form of Sanic[1]. Looks quite usable compared to raw aiohttp or twisted spaghetti I had to help maintain a couple months ago. [1] https://sanic.readthedocs.io/en/latest/ https://sanic.readthedocs.io/en/latest/
- m_ke 8y ago
  We actually use Sanic alongside Django for some of our machine learning services. Has been working well so far.
- amorphic 8y ago
  I used aiohttp for a small project recently and found that it to be very good. Combined with aiohttp-json-rpc I had a very effective websocket-based JSON RPC backend service up and running in a very short time and with very little boilerplate. I'll be using this pattern again for sure. What would have been the advantage of me using Sanic instead (I haven't RTFM for sanic yet but I'm about to...)?
  - abuckenheimer 8y ago
    [disclosure I am a sanic contributor] aiohttp is a great project, very similar to sanic, I'd say the big thing is sanic is slightly more flask like than aiohttp in ergonomics (which is something aiohttp has been working on[1]). Sanic also makes performance a key development goal so you can feel comfortable the project will scale gracefully. But I will stress I don't have current benchmarks to compare against aiohttp [1]https://aiohttp.readthedocs.io/en/stable/faq.html#id1 https://aiohttp.readthedocs.io/en/stable/faq.html#id1
  - scardine 8y ago
    The thing I like about Django is that it is an opinionated framework so lots of decisions were already made for me. Flask is a not too distant second place. With aiohttp you can make neat things it is operating a level below Sanic - in my experience people end up writing their own half-baked undocumented framework based on a combination of aiohttp, some ORM and a template engine - sometimes with half a dozen combinations in the same company.
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 ago
  Async 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 ago
    I'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 ago
    Andrew 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 ago
  Yo. 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)
jklehm 8y ago
If you can manage with Flask there's Quart [1] [1] https://gitlab.com/pgjones/quart https://gitlab.com/pgjones/quart
- bpicolo 8y ago
  I've been using quart for some projects recently. Was super easy to move to from flask (though had to upstream a couple compat fixes). Overall, super pleased
yla92 8y ago
Tornado[0] is not on per when it comes to features richness of Django. Yet, it's async and a joy to write. You should check it out if you have not. I would like to hear more from others about Tornado vs other Python frameworks as well. [0]: http://www.tornadoweb.org/en/stable/ http://www.tornadoweb.org/en/stable/
- amorphic 8y ago
  +1 I used Tornado in the past because it had an async event loop before it was native to Python. So much simpler than having to set up wsgi servers etc with the added benefit of easily-configured background tasks (like having cron jobs built in to your application). This is really good when you're building an application that you want other people to be able to install and run easily. It seems that Tornado is now offering the choice of its own event loop or the asyncio event loop. I built something recently in aiohttp because it felt like it had been built on asyncio from the ground up but will explore Tornado again.
crgwbr 8y ago
Django’s channels project actually gets pretty close to this. It’s not flawless, but it makes it fairly simple to support websockets, etc.
biggio 8y ago
There are numerous async frameworks already, aiohttp to name one, in addition to others mentioned above.
- m_ke 8y ago
  I'm aware of all of the flask inspired async micro frameworks. By django like I meant a batteries included framework with an integrated async ORM, auth, DRF and etc. From what I've seen we'll probably have to wait for django to get there, which might take a few years.

I'd argue that python needs an async django, which will hopefully be django in a few releases.

by m_ke 8y ago

I'd argue that python needs an async django, which will hopefully be django in a few releases.

There is an async Flask in the form of Sanic[1]. Looks quite usable compared to raw aiohttp or twisted spaghetti I had to help maintain a couple months ago. [1] https://sanic.readthedocs.io/en/latest/ https://sanic.readthedocs.io/en/latest/

m_ke 8y ago
We actually use Sanic alongside Django for some of our machine learning services. Has been working well so far.
amorphic 8y ago
I used aiohttp for a small project recently and found that it to be very good. Combined with aiohttp-json-rpc I had a very effective websocket-based JSON RPC backend service up and running in a very short time and with very little boilerplate. I'll be using this pattern again for sure. What would have been the advantage of me using Sanic instead (I haven't RTFM for sanic yet but I'm about to...)?
- abuckenheimer 8y ago
  [disclosure I am a sanic contributor] aiohttp is a great project, very similar to sanic, I'd say the big thing is sanic is slightly more flask like than aiohttp in ergonomics (which is something aiohttp has been working on[1]). Sanic also makes performance a key development goal so you can feel comfortable the project will scale gracefully. But I will stress I don't have current benchmarks to compare against aiohttp [1]https://aiohttp.readthedocs.io/en/stable/faq.html#id1 https://aiohttp.readthedocs.io/en/stable/faq.html#id1
- scardine 8y ago
  The thing I like about Django is that it is an opinionated framework so lots of decisions were already made for me. Flask is a not too distant second place. With aiohttp you can make neat things it is operating a level below Sanic - in my experience people end up writing their own half-baked undocumented framework based on a combination of aiohttp, some ORM and a template engine - sometimes with half a dozen combinations in the same company.

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 ago
Async 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 ago
  I'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 ago
  Andrew 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 ago
Yo. 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)

jklehm 8y ago

If you can manage with Flask there's Quart [1] [1] https://gitlab.com/pgjones/quart https://gitlab.com/pgjones/quart

bpicolo 8y ago
I've been using quart for some projects recently. Was super easy to move to from flask (though had to upstream a couple compat fixes). Overall, super pleased

yla92 8y ago

Tornado[0] is not on per when it comes to features richness of Django. Yet, it's async and a joy to write. You should check it out if you have not. I would like to hear more from others about Tornado vs other Python frameworks as well. [0]: http://www.tornadoweb.org/en/stable/ http://www.tornadoweb.org/en/stable/

amorphic 8y ago
+1 I used Tornado in the past because it had an async event loop before it was native to Python. So much simpler than having to set up wsgi servers etc with the added benefit of easily-configured background tasks (like having cron jobs built in to your application). This is really good when you're building an application that you want other people to be able to install and run easily. It seems that Tornado is now offering the choice of its own event loop or the asyncio event loop. I built something recently in aiohttp because it felt like it had been built on asyncio from the ground up but will explore Tornado again.

crgwbr 8y ago

Django’s channels project actually gets pretty close to this. It’s not flawless, but it makes it fairly simple to support websockets, etc.

biggio 8y ago

There are numerous async frameworks already, aiohttp to name one, in addition to others mentioned above.

m_ke 8y ago
I'm aware of all of the flask inspired async micro frameworks. By django like I meant a batteries included framework with an integrated async ORM, auth, DRF and etc. From what I've seen we'll probably have to wait for django to get there, which might take a few years.