A Django Async Roadmap

2018-06-04 Thread Andrew Godwin
Hello everyone,

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.

This proposed roadmap, in its great length, is here:

https://www.aeracode.org/2018/06/04/django-async-roadmap/

I'd like to invite discussion on this potential plan - including:

 - Do we think async is worth going after? Note that this is just async
HTTP capability, not WebSockets (that would remain in Channels)

 - Can we do this in a reasonable timeframe? If not, is there a way around
that?

 - Are the proposed modifications to how Django runs sensible?

 - How should we fund this?

There's many more potential questions, and I really would love feedback on
this. I'm personally pretty convinced that we can and should do this, but
this is a decision we cannot take lightly, and I would love to hear what
you have to say.

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/CAFwN1up4%2BP%2B4bCSSiG6t845idoM8dvktnuTs4dH2R5aAuCz3iA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports - May 2018

2018-06-04 Thread Tim Graham


Week ending June 2, 2018


I also spent time spinning up some new CI servers with Ubuntu 18.04. That 
required the GIS test fixes below.

Triaged

---

https://code.djangoproject.com/ticket/29455 - MySQL Backend & features 
detection are not taking MariaDB Aria engine into account (invalid)

https://code.djangoproject.com/ticket/29464 - Move collectstatic post 
processing messages to verbosity 2 (accepted)

Authored

--

https://github.com/django/django-contrib-comments/pull/134 - Added testing 
for Django 2.1

https://github.com/django/django-formtools/pull/127 - Add testing for 
Django 2.1

https://github.com/jazzband/django-hosts/pull/84 - Add testing for Django 
2.1

https://github.com/django/django-localflavor/pull/335 - Add testing for 
Django 2.1

https://github.com/django/django/pull/10003 - Refs #28748 -- Reallowed lazy 
model field choices.

https://github.com/django/django/pull/10014 - Fixed #29460 -- Added support 
for GEOS 3.6.

https://github.com/django/django/pull/10007 - Fixed #29462 -- Fixed 
ogrinspect test failures with GDAL 2.2.

https://github.com/django/django/pull/10018 - Fixed #29461 -- Fixed 
ogrinspect test_time_field failure on SpatiaLite.

Reviewed/committed

--

https://github.com/django/django/pull/8908 -  Fixed #28044 -- Unified the 
logic for createsuperuser's interactive and --noinput modes.
https://github.com/django/django/pull/9920 - Fixed #28462 -- Decreased 
memory usage with ModelAdmin.list_editable.

-- 
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/e7979cb5-08f7-4478-af01-2191c7a24015%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- May 2018

2018-06-04 Thread Carlton Gibson
Hi all,

Calendar Week 22 -- ending 1st June.


Reviewed Patches on:

https://code.djangoproject.com/ticket/29301 -- Reorder management command 
arguments in --help output to prioritize command-specific arguments
https://code.djangoproject.com/ticket/29419 -- Document the change in 
permissions required to perform admin actions
https://code.djangoproject.com/ticket/28687 -- Add a 'Not Empty' option to 
admin's related filter
https://code.djangoproject.com/ticket/11964 -- Added support for check 
constraints in model Meta.
https://code.djangoproject.com/ticket/29452 -- makemessages command doesn't 
set .pot file charset properly
https://code.djangoproject.com/ticket/29457 -- Spaces between argument 
separator and argument in template filter generate error
https://code.djangoproject.com/ticket/29385 -- Made Admindocs 
ModelDetailView show model properties.
https://code.djangoproject.com/ticket/26067 -- Added support for ordering 
ArrayAgg and StringAgg.
https://github.com/django/django/pull/10015 -- Minor correction in 
outputting-csv.txt


Triaged:

https://code.djangoproject.com/ticket/29456 -- Django 1.11 same filter_list 
get redisplayed in different model admin page (needsinfo: did not 
reproduce.)


Released: v2.0.6. — Thanks to Tim for the help!


Kind Regards,

Carlton

-- 
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/2203129b-6a7b-46bf-9496-007f0b880748%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: A Django Async Roadmap

2018-06-04 Thread Rigel
Hello Andrew.

I like your proposal and want to help out. In particular, what I'm really
fond of is the approach of making async available only if you want it,
while keeping Django backwards-compatible. Django is brilliant in that,
like the Python language, it's easy and fun to pick and learn, but flexible
and powerful at the same time.

Rigel.


On Mon, Jun 4, 2018 at 3:17 PM, Andrew Godwin  wrote:

> Hello everyone,
>
> 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.
>
> This proposed roadmap, in its great length, is here:
>
> https://www.aeracode.org/2018/06/04/django-async-roadmap/
>
> I'd like to invite discussion on this potential plan - including:
>
>  - Do we think async is worth going after? Note that this is just async
> HTTP capability, not WebSockets (that would remain in Channels)
>
>  - Can we do this in a reasonable timeframe? If not, is there a way around
> that?
>
>  - Are the proposed modifications to how Django runs sensible?
>
>  - How should we fund this?
>
> There's many more potential questions, and I really would love feedback on
> this. I'm personally pretty convinced that we can and should do this, but
> this is a decision we cannot take lightly, and I would love to hear what
> you have to say.
>
> 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/CAFwN1up4%2BP%2B4bCSSiG6t845idoM8dvktnuTs4dH
> 2R5aAuCz3iA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAD9P0JrY%3DwdtPsk9-xLhALM_4Y4ZK2uSaT6MEjKt7Nd2-DDjUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: A Django Async Roadmap

2018-06-04 Thread Tom Christie
> Do we think async is worth going after?

I think this is hugely important. Django's advantage in the field currently 
is in it's developer productivity and maintainability. As frameworks based 
on Node or on languages with co-operative concurrency built-in continue to 
mature it's going to face more of a squeeze there, while being less 
resource efficient than many alternatives.

Although performance characteristics are often over-stated or over-valued, 
it's still a substantive point against a team choosing Django in some 
circumstances. It's particularly relevant in super successful high-scale 
cases, and I want Django to continue to be a great choice both for single 
person building out an MVP on a couple of instances, all the way up to 
large teams working on massive systems, with many running services.

If we don't attempt to tackle this I think we may end up very slowly 
starting to write Django out as a contender for some teams.

> Can we do this in a reasonable timeframe? If not, is there a way around 
that?

I can't speak to the ORM work, as I don't know the internals well enough, 
but I think how everything else is proposed makes sense. The minimal first 
step, of tackling the request/response path is already potentially valuable 
for any teams that include an API gateway as one of their services - being 
able to have a Django-based app that can make non-blocking requests out to 
other services would immediately benefit a decent chunk of real-world use 
cases.

> How should we fund this?

It's a pretty serious amount of funding you'd want to see, so I guess 
ideally not as a single backer.
A joint combination of Mozilla's MOSS program, PSF grant, and corporate 
sponsorships all orchestrated together? (Waves hands magically)
Wrt. corporate sponsorships I think we might well want to set realistic 
expectations about how much developer time money actually buys, and a set a 
decently high minimum tier. What I think works especially well is tying in 
contributions, so. eg. an agreed-in-principle grant that's conditional on 
also achieving a certain amount of corporate sponsorships might be a great 
motivator for companies to make a shared, collaborative investment. ??

Thanks Andrew - *really* exciting proposal.

-- 
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/72d08b8d-06e8-4447-8017-9f3629b43656%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Redirect using HTTP status "303 See Other"

2018-06-04 Thread Duane Hutchins
The "302 Found" redirect is used by default in ​django.http.response 
HttpResponseRedirect.

Could we discuss changing this to use "303 See Other" redirects?

303 redirects are more in-line with the intent of the redirect after a 
change, and also 303 redirects disallow browser caching.
If a browser serves a cached response without revalidation, then the server 
would not receive the request.

303 redirects are not supported by HTTP/1.0, but all modern browsers now 
support HTTP/1.1 or higher.

What does everyone think about changing 302 redirects to 303?

-- 
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/829cedfb-855b-496a-9bf9-f60c6772f212%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Redirect using HTTP status "303 See Other"

2018-06-04 Thread Collin Anderson
I don't think we should make any changes to HttpResponseRedirect, for
backwards compatibility reasons if nothing else.

It might make sense to encourage people to use HttpResonse(status=303)
directly, rather than using subclasses.

On Mon, Jun 4, 2018 at 3:51 PM, Duane Hutchins  wrote:

> The "302 Found" redirect is used by default in ​django.http.response
> HttpResponseRedirect.
>
> Could we discuss changing this to use "303 See Other" redirects?
>
> 303 redirects are more in-line with the intent of the redirect after a
> change, and also 303 redirects disallow browser caching.
> If a browser serves a cached response without revalidation, then the
> server would not receive the request.
>
> 303 redirects are not supported by HTTP/1.0, but all modern browsers now
> support HTTP/1.1 or higher.
>
> What does everyone think about changing 302 redirects to 303?
>
> --
> 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/ms
> gid/django-developers/829cedfb-855b-496a-9bf9-f60c6772f212%
> 40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAFO84S4w7T9sbepdTkQ4rKLy6dtL9u5fRBhJ_7_FRV4qZq_V6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: A Django Async Roadmap

2018-06-04 Thread Tom Forbes
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.




On 4 June 2018 at 14:18:19, Andrew Godwin (and...@aeracode.org) wrote:

Hello everyone,

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.

This proposed roadmap, in its great length, is here:

https://www.aeracode.org/2018/06/04/django-async-roadmap/

I'd like to invite discussion on this potential plan - including:

 - Do we think async is worth going after? Note that this is just async
HTTP capability, not WebSockets (that would remain in Channels)

 - Can we do this in a reasonable timeframe? If not, is there a way around
that?

 - Are the proposed modifications to how Django runs sensible?

 - How should we fund this?

There's many more potential questions, and I really would love feedback on
this. I'm personally pretty convinced that we can and should do this, but
this is a decision we cannot take lightly, and I would love to hear what
you have to say.

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/CAFwN1up4%2BP%2B4bCSSiG6t845idoM8dvktnuTs4dH2R5aAuCz3iA%40mail.gmail.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
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/CAFNZOJMTTXPK5vjE7uKm8nKcZJOJTSyWA3xGVtxaGEtrQuUkfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: A Django Async Roadmap

2018-06-04 Thread Curtis Maloney

On 06/05/2018 07:54 AM, Tom Forbes wrote:

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?


One thought about the related field stuff... whilst having it makes it 
easy to get started, any site at scale will sensibly obviate their need 
in almost all cases by using select_related, for performance reasons.


--
C

--
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/4447805e-f035-8242-957e-ffb1e0c57d51%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Spaces between argument separator and argument in template filter generate error

2018-06-04 Thread oliver
Currently, django template system allow spaces between filter separator and 
filter name, also value name and filter separator. 
So, following is ok.

{{ value|filter:"arg" }}
{{ value|filter:"arg" }}

But, following can't be parsed

{{ value|filter: "arg" }}

I think that this syntax is inconsistent.
So allowing spaces between filter name and filter separator is better.


-- 
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/8d9bc320-222b-42cf-934e-644d29cb6ba0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Spaces between argument separator and argument in template filter generate error

2018-06-04 Thread oliver


2018년 6월 5일 화요일 오전 10시 52분 16초 UTC+9, oli...@kidsnote.com 님의 말:
>
> Currently, django template system allow spaces between filter separator 
> and filter name, also value name and filter separator. 
> So, following is ok.
>
> {{ value|filter:"arg" }}
> {{ value|filter:"arg" }}
>
> But, following can't be parsed
>
> {{ value|filter: "arg" }}
>
> I think that this syntax is inconsistent.
> So allowing spaces between filter argument separator and filter argument 
> is better.
>
>
>

-- 
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/dada5fc6-3fad-4811-af17-4c911d4ab2a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Spaces between argument separator and argument in template filter generate error

2018-06-04 Thread oliver
Currently, spaces between filter separator( | ) and filter name is allowed. 
Also, value name and filter separator.
So, following is allowed.

{{ value|filter:"arg" }}
{{ value|filter:"arg" }}

But, following is not allowed.

{{ value|filter: "arg" }}

users are confused by the inconsistency. 

I think that either the error message or syntax should be improved.

-- 
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/7152e2da-bd50-4496-b173-18466e2da01d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Spaces between argument separator and argument in template filter generate error

2018-06-04 Thread oliver


filter_raw_string = r"""
^(?P%(constant)s)|
^(?P[%(var_chars)s]+|%(num)s)|
 (?:\s*%(filter_sep)s\s*
 (?P\w+)
 (?:%(arg_sep)s
 (?:
  (?P%(constant)s)|
  (?P[%(var_chars)s]+|%(num)s)
 )
 )?
 )""" % {
'constant': constant_string,
'num': r'[-+\.]?\d[\d\.e]*',
'var_chars': r'\w\.',
'filter_sep': re.escape(FILTER_SEPARATOR),
'arg_sep': re.escape(FILTER_ARGUMENT_SEPARATOR),
}


allowing spaces can be done by adding \s* after (arg_sep)s

2018년 6월 5일 화요일 오전 11시 17분 51초 UTC+9, oli...@kidsnote.com 님의 말:
>
> Currently, spaces between filter separator( | ) and filter name is 
> allowed. Also, value name and filter separator.
> So, following is allowed.
>
> {{ value|filter:"arg" }}
> {{ value|filter:"arg" }}
>
> But, following is not allowed.
>
> {{ value|filter: "arg" }}
>
> users are confused by the inconsistency. 
>
> I think that either the error message or syntax should be improved.
>

-- 
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/2f27f356-e225-441a-8fd2-4f49d23f5d14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Spaces between argument separator and argument in template filter generate error

2018-06-04 Thread oliver


filter_raw_string = r"""
^(?P%(constant)s)|
^(?P[%(var_chars)s]+|%(num)s)|
 (?:\s*%(filter_sep)s\s*
 (?P\w+)
 (?:%(arg_sep)s
 (?:
  (?P%(constant)s)|
  (?P[%(var_chars)s]+|%(num)s)
 )
 )?
 )""" % {
'constant': constant_string,
'num': r'[-+\.]?\d[\d\.e]*',
'var_chars': r'\w\.',
'filter_sep': re.escape(FILTER_SEPARATOR),
'arg_sep': re.escape(FILTER_ARGUMENT_SEPARATOR),
}


allowing spaces can be done by simply adding \s* after (arg_sep)s

-- 
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/f87d71f0-c3d6-4155-bff3-b7693123c60c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: A Django Async Roadmap

2018-06-04 Thread Andrew Godwin
>
>
> 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?
>
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.