From 41725602afebe2ddb018b99afe134384cc3bf69e Mon Sep 17 00:00:00 2001 From: Juan Pedro Fisanotti Date: Thu, 20 Aug 2020 04:06:50 -0300 Subject: [PATCH] Improved wording in async views docs. --- docs/topics/async.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/topics/async.txt b/docs/topics/async.txt index c820f54879..5612235622 100644 --- a/docs/topics/async.txt +++ b/docs/topics/async.txt @@ -39,7 +39,7 @@ class-based view, this means making its ``__call__()`` method an ``async def`` to ``asyncio.coroutines._is_coroutine`` so this function returns ``True``. Under a WSGI server, async views will run in their own, one-off event loop. -This means you can use async features, like parallel async HTTP requests, +This means you can use async features, like concurrent async HTTP requests, without any issues, but you will not get the benefits of an async stack. The main benefits are the ability to service hundreds of connections without @@ -63,7 +63,7 @@ If you want to use these, you will need to deploy Django using messages about *"Synchronous middleware ... adapted"*. In both ASGI and WSGI mode, you can still safely use asynchronous support to -run code in parallel rather than serially. This is especially handy when +run code concurrently rather than serially. This is especially handy when dealing with external APIs or data stores. If you want to call a part of Django that is still synchronous, like the ORM,