Opened 4 years ago
Last modified 4 years ago
#33611 closed New feature
Allow View subclasses to define async method handlers. — at Initial Version
| 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
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() or as_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!")
Note:
See TracTickets
for help on using tickets.