#33611: Allow View subclasses to define async method handlers.
------------------------------------+--------------------------------------
Reporter: Carlton Gibson | Owner: nobody
Type: New feature | Status: assigned
Component: Generic views | Version: 4.0
Severity: Normal | Resolution:
Keywords: async, asgi, views | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------------+--------------------------------------
Description changed by Carlton Gibson:
Old description:
> The current [https://docs.djangoproject.com/en/4.0/topics/async/#async-
> views topic docs for Async views] say this about class-based views:
>
> > For a class-based view, this means making its __call__() method an
> async def (not its __init__() or as_view()).
>
> This isn't really appropriate for Django's class-based views:
>
> * We don't implement `__call__()`, rather going via `as_view() — for a
> per-request instance — and then `dispatch()`.
> * Users expect to implement the HTTP method handlers — `get`, `post`, and
> so on — rather than these ''more internal'' bits.
>
> Ideally we'd allow specifying `async def` at the method handler level, to
> allow using `await` in the handler, and writing views such as this:
>
> {{{
> import asyncio
> from django.http import HttpResponse
> from django.views import View
>
> class AsyncView(View):
> async def get(self, request, *args, **kwargs):
> # Perform io-blocking view-logic using await, sleep for
> example.
> await asyncio.sleep(1)
> return HttpResponse("Hello async world!")
> }}}
New description:
The current [https://docs.djangoproject.com/en/4.0/topics/async/#async-
views topic docs for Async views] say this about class-based views:
> For a class-based view, this means making its `__call__()` method an
async def (not its `__init__()` or `as_view()`).
This isn't really appropriate for Django's class-based views:
* We don't implement `__call__()`, rather going via `as_view()` — for a
per-request instance — and then `dispatch()`.
* Users expect to implement the HTTP method handlers — `get()`, `post()`,
and so on — rather than these ''more internal'' bits.
Ideally we'd allow specifying `async def` at the method handler level, to
allow using `await` in the handler, and writing views such as this:
{{{
import asyncio
from django.http import HttpResponse
from django.views import View
class AsyncView(View):
async def get(self, request, *args, **kwargs):
# Perform io-blocking view-logic using await, sleep for
example.
await asyncio.sleep(1)
return HttpResponse("Hello async world!")
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33611#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107017fdecfd641-b3877524-350f-47c5-9e85-6b20cf059bc1-000000%40eu-central-1.amazonses.com.
