>
>
> 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
> <https://www.python.org/dev/peps/pep-0567/> could help here, could we
> define some kind of ‘Django async context’ and do different things
> depending on if this is true or false?
>
Unfortunately even if you have context variables, you simply can't await
inside of an attribute reference because there's a synchronous call in your
stack. I even chatted to some Python core devs at PyCon US about this and
we couldn't really think of a way out of this problem without some very
serious changes to the language.
What will work, though, is attribute access from a sync context - the
related field references will only error out of they know they're in an
async loop, and we can detect that by looking for an active event loop on
the current thread (no context varaible needed).
> 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.
>
I'm not quite sure on this one. For backwards compatibility, we have to
keep sync methods working with the same name, but there are several options
as to how to separate them - keyword arguments (like "my_method(...,
async=True)"), suffixes ("my_method_async()", as you suggest),
automatically changing based on if you're in an async thread (which is a
bit... magic) or different module namespaces ("from django.db.async import
foo").
I want to sketch out what all of these look like as part of this project
and then work out which is best for Django.
> 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.
>
That would very much be a long-term thing, and honestly something I might
consider handing off to something like Jinja (which already has full async
support, I learnt yesterday)
Andrew
--
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+unsubscr...@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/CAFwN1upPVQCjHTxgJmzJSUzaevsfQ7evwi89hFt4OvHmMe5m2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
