#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 [email protected].
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.
