Fixed #33611 -- Allowed View subclasses to define async method handlers.

1 files changed, 19 insertions, 0 deletions

diff --git a/docs/ref/class-based-views/base.txt b/docs/ref/class-based-views/base.txt
index 5c2eb712c1..f60950d1fa 100644
--- a/docs/ref/class-based-views/base.txt
+++ b/docs/ref/class-based-views/base.txt
@@ -77,6 +77,17 @@ MRO is an acronym for Method Resolution Order.
         <how-django-processes-a-request>` to the ``args`` and ``kwargs``
         attributes, respectively. Then :meth:`dispatch` is called.
 
+        If a ``View`` subclass defines asynchronous (``async def``) method
+        handlers, ``as_view()`` will mark the returned callable as a coroutine
+        function. An ``ImproperlyConfigured`` exception will be raised if both
+        asynchronous (``async def``) and synchronous (``def``) handlers are
+        defined on a single view-class.
+
+        .. versionchanged:: 4.1
+
+            Compatibility with asynchronous (``async def``) method handlers was
+            added.
+
     .. method:: setup(request, *args, **kwargs)
 
         Performs key view initialization prior to :meth:`dispatch`.
@@ -111,6 +122,14 @@ MRO is an acronym for Method Resolution Order.
         response with the ``Allow`` header containing a list of the view's
         allowed HTTP method names.
 
+        If the other HTTP methods handlers on the class are asynchronous
+        (``async def``) then the response will be wrapped in a coroutine
+        function for use with ``await``.
+
+        .. versionchanged:: 4.1
+
+            Compatibility with classes defining asynchronous (``async def``)
+            method handlers was added.
 
 ``TemplateView``
 ================