Applied Black's 2024 stable style.

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

docs/howto/csrf.txt

@@ -208,8 +208,7 @@ will require a CSRF token to be inserted you should use the
 
   @cache_page(60 * 15)
   @csrf_protect
-  def my_view(request):
-      ...
+  def my_view(request): ...
 
 If you are using class-based views, you can refer to :ref:`Decorating
 class-based views<decorating-class-based-views>`.

docs/howto/custom-file-storage.txt

@@ -14,8 +14,7 @@ You'll need to follow these steps:
         from django.core.files.storage import Storage
 
 
-        class MyStorage(Storage):
-            ...
+        class MyStorage(Storage): ...
 
 #. Django must be able to instantiate your storage system without any arguments.
    This means that any settings should be taken from ``django.conf.settings``::

docs/howto/custom-lookups.txt

@@ -53,8 +53,7 @@ Lookup registration can also be done using a decorator pattern::
 
 
     @Field.register_lookup
-    class NotEqualLookup(Lookup):
-        ...
+    class NotEqualLookup(Lookup): ...
 
 We can now use ``foo__ne`` for any field ``foo``. You will need to ensure that
 this registration happens before you try to create any querysets using it. You

docs/howto/custom-management-commands.txt

@@ -146,8 +146,7 @@ decorator on your :meth:`~BaseCommand.handle` method::
         ...
 
         @no_translations
-        def handle(self, *args, **options):
-            ...
+        def handle(self, *args, **options): ...
 
 Since translation deactivation requires access to configured settings, the
 decorator can't be used for commands that work without configured settings.

docs/howto/custom-model-fields.txt

@@ -338,24 +338,20 @@ Changing a custom field's base class
 You can't change the base class of a custom field because Django won't detect
 the change and make a migration for it. For example, if you start with::
 
-    class CustomCharField(models.CharField):
-        ...
+    class CustomCharField(models.CharField): ...
 
 and then decide that you want to use ``TextField`` instead, you can't change
 the subclass like this::
 
-    class CustomCharField(models.TextField):
-        ...
+    class CustomCharField(models.TextField): ...
 
 Instead, you must create a new custom field class and update your models to
 reference it::
 
-    class CustomCharField(models.CharField):
-        ...
+    class CustomCharField(models.CharField): ...
 
 
-    class CustomTextField(models.TextField):
-        ...
+    class CustomTextField(models.TextField): ...
 
 As discussed in :ref:`removing fields <migrations-removing-model-fields>`, you
 must retain the original ``CustomCharField`` class as long as you have

docs/howto/custom-template-tags.txt

@@ -561,8 +561,7 @@ template loader, we'd register the tag like this::
 
     # Here, register is a django.template.Library instance, as before
     @register.inclusion_tag("results.html")
-    def show_results(poll):
-        ...
+    def show_results(poll): ...
 
 Alternatively it is possible to register the inclusion tag using a
 :class:`django.template.Template` instance::
@@ -917,13 +916,11 @@ The ``tag()`` method takes two arguments:
 As with filter registration, it is also possible to use this as a decorator::
 
     @register.tag(name="current_time")
-    def do_current_time(parser, token):
-        ...
+    def do_current_time(parser, token): ...
 
 
     @register.tag
-    def shout(parser, token):
-        ...
+    def shout(parser, token): ...
 
 If you leave off the ``name`` argument, as in the second example above, Django
 will use the function's name as the tag name.

docs/howto/error-reporting.txt

@@ -177,8 +177,7 @@ filtered out of error reports in a production environment (that is, where
     do not provide any argument to the ``sensitive_variables`` decorator::
 
         @sensitive_variables()
-        def my_function():
-            ...
+        def my_function(): ...
 
     .. admonition:: When using multiple decorators
 
@@ -191,8 +190,7 @@ filtered out of error reports in a production environment (that is, where
             @sensitive_variables("user", "pw", "cc")
             @some_decorator
             @another_decorator
-            def process_info(user):
-                ...
+            def process_info(user): ...
 
     .. versionchanged:: 5.0
 
@@ -229,8 +227,7 @@ filtered out of error reports in a production environment (that is, where
     do not provide any argument to the ``sensitive_post_parameters`` decorator::
 
         @sensitive_post_parameters()
-        def my_view(request):
-            ...
+        def my_view(request): ...
 
     All POST parameters are systematically filtered out of error reports for
     certain :mod:`django.contrib.auth.views` views (``login``,