Applied Black's 2024 stable style.

https://github.com/psf/black/releases/tag/24.1.0

11 files changed, 46 insertions, 86 deletions

diff --git a/docs/topics/async.txt b/docs/topics/async.txt
index 6c9d35b533..87550ff46d 100644
--- a/docs/topics/async.txt
+++ b/docs/topics/async.txt
@@ -111,13 +111,11 @@ For example::
 
 
     @never_cache
-    def my_sync_view(request):
-        ...
+    def my_sync_view(request): ...
 
 
     @never_cache
-    async def my_async_view(request):
-        ...
+    async def my_async_view(request): ...
 
 Queries & the ORM
 -----------------
@@ -294,16 +292,14 @@ as either a direct wrapper or a decorator::
     from asgiref.sync import async_to_sync
 
 
-    async def get_data():
-        ...
+    async def get_data(): ...
 
 
     sync_get_data = async_to_sync(get_data)
 
 
     @async_to_sync
-    async def get_other_data():
-        ...
+    async def get_other_data(): ...
 
 The async function is run in the event loop for the current thread, if one is
 present. If there is no current event loop, a new event loop is spun up
@@ -334,8 +330,7 @@ as either a direct wrapper or a decorator::
 
 
     @sync_to_async
-    def sync_function():
-        ...
+    def sync_function(): ...
 
 Threadlocals and contextvars values are preserved across the boundary in both
 directions.
diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt
index 75d33b5e7e..de2bc51cda 100644
--- a/docs/topics/auth/default.txt
+++ b/docs/topics/auth/default.txt
@@ -553,8 +553,7 @@ The ``login_required`` decorator
 
 
         @login_required
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     :func:`~django.contrib.auth.decorators.login_required` does the following:
 
@@ -575,8 +574,7 @@ The ``login_required`` decorator
 
 
         @login_required(redirect_field_name="my_redirect_field")
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     Note that if you provide a value to ``redirect_field_name``, you will most
     likely need to customize your login template as well, since the template
@@ -590,8 +588,7 @@ The ``login_required`` decorator
 
 
         @login_required(login_url="/accounts/login/")
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     Note that if you don't specify the ``login_url`` parameter, you'll need to
     ensure that the :setting:`settings.LOGIN_URL <LOGIN_URL>` and your login
@@ -688,8 +685,7 @@ email in the desired domain and if not, redirects to the login page::
 
 
         @user_passes_test(email_check)
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     :func:`~django.contrib.auth.decorators.user_passes_test` takes a required
     argument: a callable that takes a
@@ -716,8 +712,7 @@ email in the desired domain and if not, redirects to the login page::
     For example::
 
         @user_passes_test(email_check, login_url="/login/")
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
 .. currentmodule:: django.contrib.auth.mixins
 
@@ -761,8 +756,7 @@ email in the desired domain and if not, redirects to the login page::
                     return self.request.user.username.startswith("django")
 
 
-            class MyView(TestMixin1, TestMixin2, View):
-                ...
+            class MyView(TestMixin1, TestMixin2, View): ...
 
         If ``TestMixin1`` would call ``super()`` and take that result into
         account, ``TestMixin1`` wouldn't work standalone anymore.
@@ -782,8 +776,7 @@ The ``permission_required`` decorator
 
 
         @permission_required("polls.add_choice")
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     Just like the :meth:`~django.contrib.auth.models.User.has_perm` method,
     permission names take the form ``"<app label>.<permission codename>"``
@@ -800,8 +793,7 @@ The ``permission_required`` decorator
 
 
         @permission_required("polls.add_choice", login_url="/loginpage/")
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     As in the :func:`~django.contrib.auth.decorators.login_required` decorator,
     ``login_url`` defaults to :setting:`settings.LOGIN_URL <LOGIN_URL>`.
@@ -820,8 +812,7 @@ The ``permission_required`` decorator
 
         @login_required
         @permission_required("polls.add_choice", raise_exception=True)
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     This also avoids a redirect loop when :class:`.LoginView`'s
     ``redirect_authenticated_user=True`` and the logged-in user doesn't have
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index 880f606aae..6625b6946c 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -668,8 +668,7 @@ decorator that will automatically cache the view's response for you::
 
 
     @cache_page(60 * 15)
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 ``cache_page`` takes a single argument: the cache timeout, in seconds. In the
 above example, the result of the ``my_view()`` view will be cached for 15
@@ -699,8 +698,7 @@ which directs the decorator to use a specific cache (from your
 want::
 
     @cache_page(60 * 15, cache="special_cache")
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 You can also override the cache prefix on a per-view basis. ``cache_page``
 takes an optional keyword argument, ``key_prefix``,
@@ -708,8 +706,7 @@ which works in the same way as the :setting:`CACHE_MIDDLEWARE_KEY_PREFIX`
 setting for the middleware.  It can be used like this::
 
     @cache_page(60 * 15, key_prefix="site1")
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 The ``key_prefix`` and ``cache`` arguments may be specified together. The
 ``key_prefix`` argument and the :setting:`KEY_PREFIX <CACHES-KEY_PREFIX>`
@@ -1342,8 +1339,7 @@ To do this in Django, use the convenient
 
 
     @vary_on_headers("User-Agent")
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 In this case, a caching mechanism (such as Django's own cache middleware) will
 cache a separate version of the page for each unique user-agent.
@@ -1357,8 +1353,7 @@ anything that was already in there.
 You can pass multiple headers to ``vary_on_headers()``::
 
     @vary_on_headers("User-Agent", "Cookie")
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 This tells downstream caches to vary on *both*, which means each combination of
 user-agent and cookie will get its own cache value. For example, a request with
@@ -1371,13 +1366,11 @@ Because varying on cookie is so common, there's a
 are equivalent::
 
     @vary_on_cookie
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 
     @vary_on_headers("Cookie")
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 The headers you pass to ``vary_on_headers`` are not case sensitive;
 ``"User-Agent"`` is the same thing as ``"user-agent"``.
@@ -1423,8 +1416,7 @@ decorator. Example::
 
 
     @cache_control(private=True)
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 This decorator takes care of sending out the appropriate HTTP header behind the
 scenes.
@@ -1463,8 +1455,7 @@ directive::
 
 
     @cache_control(max_age=3600)
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 (If you *do* use the caching middleware, it already sets the ``max-age`` with
 the value of the :setting:`CACHE_MIDDLEWARE_SECONDS` setting. In that case,
@@ -1494,8 +1485,7 @@ caches. Example::
 
 
     @never_cache
-    def myview(request):
-        ...
+    def myview(request): ...
 
 Order of ``MIDDLEWARE``
 =======================
diff --git a/docs/topics/checks.txt b/docs/topics/checks.txt
index 9a91ceb469..3e3bbe19d6 100644
--- a/docs/topics/checks.txt
+++ b/docs/topics/checks.txt
@@ -113,8 +113,7 @@ You can register "deployment checks" that are only relevant to a production
 settings file like this::
 
     @register(Tags.security, deploy=True)
-    def my_check(app_configs, **kwargs):
-        ...
+    def my_check(app_configs, **kwargs): ...
 
 These checks will only be run if the :option:`check --deploy` option is used.
 
@@ -124,8 +123,7 @@ to ``register``.
 
 The code below is equivalent to the code above::
 
-    def my_check(app_configs, **kwargs):
-        ...
+    def my_check(app_configs, **kwargs): ...
 
 
     register(my_check, Tags.security, deploy=True)
diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt
index 2447697de4..dfd36a64ae 100644
--- a/docs/topics/conditional-view-processing.txt
+++ b/docs/topics/conditional-view-processing.txt
@@ -72,8 +72,7 @@ Suppose you have this pair of models, representing a small blog system::
     from django.db import models
 
 
-    class Blog(models.Model):
-        ...
+    class Blog(models.Model): ...
 
 
     class Entry(models.Model):
@@ -96,8 +95,7 @@ for your front page view::
 
 
     @condition(last_modified_func=latest_entry)
-    def front_page(request, blog_id):
-        ...
+    def front_page(request, blog_id): ...
 
 .. admonition:: Be careful with the order of decorators
 
@@ -131,13 +129,11 @@ We could write the earlier example, which only uses a last-modified function,
 using one of these decorators::
 
     @last_modified(latest_entry)
-    def front_page(request, blog_id):
-        ...
+    def front_page(request, blog_id): ...
 
 ...or::
 
-    def front_page(request, blog_id):
-        ...
+    def front_page(request, blog_id): ...
 
 
     front_page = last_modified(latest_entry)(front_page)
@@ -154,8 +150,7 @@ this would lead to incorrect behavior.
     # Bad code. Don't do this!
     @etag(etag_func)
     @last_modified(last_modified_func)
-    def my_view(request):
-        ...
+    def my_view(request): ...
 
 
     # End of bad code.
diff --git a/docs/topics/db/fixtures.txt b/docs/topics/db/fixtures.txt
index 48c5605ff4..ac5b34dae0 100644
--- a/docs/topics/db/fixtures.txt
+++ b/docs/topics/db/fixtures.txt
@@ -161,8 +161,7 @@ You could also write a decorator to encapsulate this logic::
 
 
     @disable_for_loaddata
-    def my_handler(**kwargs):
-        ...
+    def my_handler(**kwargs): ...
 
 Just be aware that this logic will disable the signals whenever fixtures are
 deserialized, not just during :djadmin:`loaddata`.
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index 9146ecc2f7..63a6bc2d66 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -311,8 +311,7 @@ Pass a function, or any callable, to :func:`on_commit`::
     from django.db import transaction
 
 
-    def send_welcome_email():
-        ...
+    def send_welcome_email(): ...
 
 
     transaction.on_commit(send_welcome_email)
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index 53ce716a4d..e2a37296b7 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -704,8 +704,7 @@ using the previous ``ArticleForm`` class:
 .. code-block:: pycon
 
     >>> class EnhancedArticleForm(ArticleForm):
-    ...     def clean_pub_date(self):
-    ...         ...
+    ...     def clean_pub_date(self): ...
     ...
 
 This creates a form that behaves identically to ``ArticleForm``, except there's
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
index 0e696badc0..911c282157 100644
--- a/docs/topics/http/file-uploads.txt
+++ b/docs/topics/http/file-uploads.txt
@@ -338,7 +338,8 @@ list::
 
         @csrf_protect
         def _upload_file_view(request):
-            ...  # Process request
+            # Process request
+            ...
 
     If you are using a class-based view, you will need to use
     :func:`~django.views.decorators.csrf.csrf_exempt` on its
@@ -359,4 +360,5 @@ list::
 
             @method_decorator(csrf_protect)
             def post(self, request, *args, **kwargs):
-                ...  # Process request
+                # Process request
+                ...
diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt
index a4d973ebb4..6a577dd8ad 100644
--- a/docs/topics/signals.txt
+++ b/docs/topics/signals.txt
@@ -200,8 +200,7 @@ signals sent by some model::
 
 
     @receiver(pre_save, sender=MyModel)
-    def my_handler(sender, **kwargs):
-        ...
+    def my_handler(sender, **kwargs): ...
 
 The ``my_handler`` function will only be called when an instance of ``MyModel``
 is saved.
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index cd05db2cf8..14a58c4c00 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -1361,8 +1361,7 @@ For example::
     class OtherDBTests(TestCase):
         databases = {"other"}
 
-        def test_other_db_query(self):
-            ...
+        def test_other_db_query(self): ...
 
 This test will only allow queries against the ``other`` database. Just like for
 :attr:`SimpleTestCase.databases` and :attr:`TransactionTestCase.databases`, the
@@ -1981,22 +1980,18 @@ you might label fast or slow tests::
 
     class SampleTestCase(TestCase):
         @tag("fast")
-        def test_fast(self):
-            ...
+        def test_fast(self): ...
 
         @tag("slow")
-        def test_slow(self):
-            ...
+        def test_slow(self): ...
 
         @tag("slow", "core")
-        def test_slow_but_core(self):
-            ...
+        def test_slow_but_core(self): ...
 
 You can also tag a test case class::
 
     @tag("slow", "core")
-    class SampleTestCase(TestCase):
-        ...
+    class SampleTestCase(TestCase): ...
 
 Subclasses inherit tags from superclasses, and methods inherit tags from their
 class. Given::
@@ -2004,8 +1999,7 @@ class. Given::
     @tag("foo")
     class SampleTestCaseChild(SampleTestCase):
         @tag("bar")
-        def test(self):
-            ...
+        def test(self): ...
 
 ``SampleTestCaseChild.test`` will be labeled with ``'slow'``, ``'core'``,
 ``'bar'``, and ``'foo'``.
@@ -2105,8 +2099,7 @@ creates.
         class MyTests(TestCase):
             @mock.patch(...)
             @async_to_sync
-            async def test_my_thing(self):
-                ...
+            async def test_my_thing(self): ...
 
 .. _topics-testing-email: