Opened 3 years ago
Last modified 3 years ago
#33611 closed New feature
Allow View subclasses to define async method handlers. — at Version 3
Reported by: | Carlton Gibson | Owned by: | nobody |
---|---|---|---|
Component: | Generic views | Version: | 4.0 |
Severity: | Normal | Keywords: | async, asgi, views |
Cc: | Andrew Godwin | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The current 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__()
oras_view()
).
This isn't really appropriate for Django's class-based views:
- We don't implement
__call__()
, rather going viaas_view()
— for a per-request instance — and thendispatch()
. - 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!")
Change History (3)
comment:1 by , 3 years ago
Cc: | added |
---|
comment:2 by , 3 years ago
Component: | HTTP handling → Generic views |
---|
comment:3 by , 3 years ago
Description: | modified (diff) |
---|
Note:
See TracTickets
for help on using tickets.
PR