--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1up4%2BP%2B4bCSSiG6t845idoM8dvktnuTs4dH2R5aAuCz3iA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Hey Andrew, thank you for the very exciting proposal and the ongoing work on Django channels! There is a lot to consider here and some very interesting problems to work through - I’d love to help out wherever I can.
Do we think async is worth going after?
I think this is very much worth doing. Async interfaces to the ORM and templates would be a huge, huge improvement if we can get it right. I think Tom Christie summed it up really well however I would add that I think teams excluding Django as a contender may happen sooner rather than later if it’s not happening already.
Are the proposed modifications to how Django runs sensible?
I had a few random thoughts while reading your proposal:
I think getting rid of the related field references could be a big issue here and cause a lot of headaches for existing applications. Could we do this in a backwards compatible way at all? I wonder if PEP 567 could help here, could we define some kind of ‘Django async context’ and do different things depending on if this is true or false?
Regarding exposing an async interface alongside a synchronous one: are you envisaging something like appending _async
to methods or having some kind of wrapper class that could be optionally included to go from async->sync? I guess it would have to be appending _async
, as a wrapper class could be used in different contexts.
Async templates seem particularly powerful if we work out the details. We could eventually render different parts of the template concurrently, i.e example each iteration of a for loop could be it’s own future resolved independently, but this is likely a pipe dream.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
I think getting rid of the related field references could be a big issue here and cause a lot of headaches for existing applications. Could we do this in a backwards compatible way at all? I wonder if PEP 567 could help here, could we define some kind of ‘Django async context’ and do different things depending on if this is true or false?
Regarding exposing an async interface alongside a synchronous one: are you envisaging something like appending
_async
to methods or having some kind of wrapper class that could be optionally included to go from async->sync? I guess it would have to be appending_async
, as a wrapper class could be used in different contexts.
Async templates seem particularly powerful if we work out the details. We could eventually render different parts of the template concurrently, i.e example each iteration of a for loop could be it’s own future resolved independently, but this is likely a pipe dream.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1upPVQCjHTxgJmzJSUzaevsfQ7evwi89hFt4OvHmMe5m2A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7a958407-7dcf-4fd8-b09f-67e28346cb65%40googlegroups.com.
The only real concern I have at the moment is around your comments regarding on demand foreign key traversal. If existing code running synchronously is going to be impacted, that's going to be very difficult for a lot of people. If it's only asynchronous traversal that'll have issues, then I have no real concern, as on demand foreign key fetching is usually a bug anyway.
Having a brief read through the psycopg asynchronous docs[0], it looks like a number of features will be impossible or troublesome to use, like transactions, executemany, and named cursors (.iterator() with server side cursors). We'd also need to investigate how pgbouncer would work in async mode, as most large sites using postgres are also using pgbouncer. I would expect support can only further improve, especially if there is a driver like django pushing. Fallback would just be to run inside a thread pool though, so it's not a blocker for the rest of the proposal.
> <mailto:django-developers+unsub...@googlegroups.com>.
For a while now I have been working on potential plans for making Django async-capable, and I finally have a plan I am reasonably happy with and which I think we can actually do.
I also currently use `psycogreen.gevent` for postgresql async behaviour.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6ea76507-4041-4850-ac6c-bb13a09af941%40googlegroups.com.