diff options
Diffstat (limited to 'docs')
31 files changed, 94 insertions, 177 deletions
diff --git a/docs/_ext/djangodocs.py b/docs/_ext/djangodocs.py index 7d55cb0333..77e24ff0eb 100644 --- a/docs/_ext/djangodocs.py +++ b/docs/_ext/djangodocs.py @@ -1,6 +1,7 @@ """ Sphinx plugins for Django documentation. """ + import json import os import re diff --git a/docs/howto/csrf.txt b/docs/howto/csrf.txt index 07f2e20a1c..d40f4b4cb4 100644 --- a/docs/howto/csrf.txt +++ b/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>`. diff --git a/docs/howto/custom-file-storage.txt b/docs/howto/custom-file-storage.txt index b7bd22d9c1..3cc96cce84 100644 --- a/docs/howto/custom-file-storage.txt +++ b/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``:: diff --git a/docs/howto/custom-lookups.txt b/docs/howto/custom-lookups.txt index 61ec9295eb..fc8e928890 100644 --- a/docs/howto/custom-lookups.txt +++ b/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 diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt index 8bdfb1e38b..b472f092e9 100644 --- a/docs/howto/custom-management-commands.txt +++ b/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. diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt index 1e7ac4f0ba..b4a1537896 100644 --- a/docs/howto/custom-model-fields.txt +++ b/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 diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt index c7909c8a4b..15bef9b5fb 100644 --- a/docs/howto/custom-template-tags.txt +++ b/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. diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt index 84fe3cb768..b36f884096 100644 --- a/docs/howto/error-reporting.txt +++ b/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``, diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt index 6871d43d7b..49b69bf066 100644 --- a/docs/internals/contributing/writing-code/coding-style.txt +++ b/docs/internals/contributing/writing-code/coding-style.txt @@ -201,8 +201,7 @@ Imports CONSTANT = "foo" - class Example: - ... + class Example: ... * Use convenience imports whenever available. For example, do this :: @@ -239,13 +238,11 @@ View style Do this:: - def my_view(request, foo): - ... + def my_view(request, foo): ... Don't do this:: - def my_view(req, foo): - ... + def my_view(req, foo): ... Model style =========== diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index be031f1f68..72c986cfc7 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/docs/internals/contributing/writing-code/submitting-patches.txt @@ -190,8 +190,7 @@ level: @ignore_warnings(category=RemovedInDjangoXXWarning) - def test_foo(self): - ... + def test_foo(self): ... #) For an entire test case:: @@ -200,8 +199,7 @@ level: @ignore_warnings(category=RemovedInDjangoXXWarning) - class MyDeprecatedTests(unittest.TestCase): - ... + class MyDeprecatedTests(unittest.TestCase): ... You should also add a test for the deprecation warning:: diff --git a/docs/intro/tutorial04.txt b/docs/intro/tutorial04.txt index 13a76188bb..65dc132a94 100644 --- a/docs/intro/tutorial04.txt +++ b/docs/intro/tutorial04.txt @@ -309,7 +309,8 @@ views and use Django's generic views instead. To do so, open the def vote(request, question_id): - ... # same as above, no changes needed. + # same as above, no changes needed. + ... Each generic view needs to know what model it will be acting upon. This is provided using either the ``model`` attribute (in this example, ``model = diff --git a/docs/intro/tutorial07.txt b/docs/intro/tutorial07.txt index 9cdadbe286..8cb5dd5d5a 100644 --- a/docs/intro/tutorial07.txt +++ b/docs/intro/tutorial07.txt @@ -174,8 +174,7 @@ tabular way of displaying inline related objects. To use it, change the .. code-block:: python :caption: ``polls/admin.py`` - class ChoiceInline(admin.TabularInline): - ... + class ChoiceInline(admin.TabularInline): ... With that ``TabularInline`` (instead of ``StackedInline``), the related objects are displayed in a more compact, table-based format: diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt index 23cfa833e0..e85ba9c36a 100644 --- a/docs/ref/contrib/admin/index.txt +++ b/docs/ref/contrib/admin/index.txt @@ -751,8 +751,7 @@ subclass:: like:: @admin.display(ordering="-first_name") - def colored_first_name(self): - ... + def colored_first_name(self): ... The ``ordering`` argument supports query lookups to sort by values on related models. This example includes an "author first name" column in @@ -3128,8 +3127,7 @@ returns a site instance. from django.contrib import admin - class MyAdminSite(admin.AdminSite): - ... + class MyAdminSite(admin.AdminSite): ... .. code-block:: python :caption: ``myproject/apps.py`` @@ -3467,5 +3465,4 @@ The ``staff_member_required`` decorator @staff_member_required - def my_view(request): - ... + def my_view(request): ... diff --git a/docs/ref/contrib/gis/feeds.txt b/docs/ref/contrib/gis/feeds.txt index 9ae9d4f03a..3f17a68574 100644 --- a/docs/ref/contrib/gis/feeds.txt +++ b/docs/ref/contrib/gis/feeds.txt @@ -40,18 +40,14 @@ API Reference item_geometry = ... # Also a function with no arguments - def geometry(self): - ... + def geometry(self): ... - def item_geometry(self): - ... + def item_geometry(self): ... # And as a function with a single argument - def geometry(self, obj): - ... + def geometry(self, obj): ... - def item_geometry(self, item): - ... + def item_geometry(self, item): ... .. method:: geometry(obj) diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index eee1c66d56..9db029cc60 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -422,8 +422,7 @@ A dotted path to the view function to be used when an incoming request is rejected by the :doc:`CSRF protection </ref/csrf>`. The function should have this signature:: - def csrf_failure(request, reason=""): - ... + def csrf_failure(request, reason=""): ... where ``reason`` is a short message (intended for developers or logging, not for end users) indicating the reason the request was rejected. It should return diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt index 8ebb4f5116..3e357cba17 100644 --- a/docs/ref/utils.txt +++ b/docs/ref/utils.txt @@ -469,8 +469,7 @@ https://web.archive.org/web/20110718035220/http://diveintomark.org/archives/2004 class Person(models.Model): @cached_property - def friends(self): - ... + def friends(self): ... Note that as the method is now a property, in Python code it will need to be accessed appropriately:: @@ -552,8 +551,7 @@ https://web.archive.org/web/20110718035220/http://diveintomark.org/archives/2004 # Or more succinctly: @keep_lazy(str) - def fancy_utility_function(s, *args, **kwargs): - ... + def fancy_utility_function(s, *args, **kwargs): ... The ``keep_lazy()`` decorator takes a number of extra arguments (``*args``) specifying the type(s) that the original function can return. A common @@ -578,14 +576,12 @@ https://web.archive.org/web/20110718035220/http://diveintomark.org/archives/2004 # Our previous example was: @keep_lazy(str) - def fancy_utility_function(s, *args, **kwargs): - ... + def fancy_utility_function(s, *args, **kwargs): ... # Which can be rewritten as: @keep_lazy_text - def fancy_utility_function(s, *args, **kwargs): - ... + def fancy_utility_function(s, *args, **kwargs): ... ``django.utils.html`` ===================== diff --git a/docs/releases/1.0-porting-guide.txt b/docs/releases/1.0-porting-guide.txt index f0ed8f4169..145334c238 100644 --- a/docs/releases/1.0-porting-guide.txt +++ b/docs/releases/1.0-porting-guide.txt @@ -144,8 +144,7 @@ example: Old (0.96):: - class Parent(models.Model): - ... + class Parent(models.Model): ... class Child(models.Model): diff --git a/docs/releases/1.10.txt b/docs/releases/1.10.txt index b5213ee207..d98fad2c66 100644 --- a/docs/releases/1.10.txt +++ b/docs/releases/1.10.txt @@ -732,8 +732,7 @@ custom lookup for it. For example:: from django.db.models.lookups import Exact - class MyField(Field): - ... + class MyField(Field): ... class MyFieldExact(Exact): diff --git a/docs/releases/1.2.txt b/docs/releases/1.2.txt index de3ed69a70..526bb1d66e 100644 --- a/docs/releases/1.2.txt +++ b/docs/releases/1.2.txt @@ -455,17 +455,13 @@ database-compatible values. A custom field might look something like:: class CustomModelField(models.Field): ... - def db_type(self): - ... + def db_type(self): ... - def get_db_prep_save(self, value): - ... + def get_db_prep_save(self, value): ... - def get_db_prep_value(self, value): - ... + def get_db_prep_value(self, value): ... - def get_db_prep_lookup(self, lookup_type, value): - ... + def get_db_prep_lookup(self, lookup_type, value): ... In 1.2, these three methods have undergone a change in prototype, and two extra methods have been introduced:: @@ -473,23 +469,17 @@ two extra methods have been introduced:: class CustomModelField(models.Field): ... - def db_type(self, connection): - ... + def db_type(self, connection): ... - def get_prep_value(self, value): - ... + def get_prep_value(self, value): ... - def get_prep_lookup(self, lookup_type, value): - ... + def get_prep_lookup(self, lookup_type, value): ... - def get_db_prep_save(self, value, connection): - ... + def get_db_prep_save(self, value, connection): ... - def get_db_prep_value(self, value, connection, prepared=False): - ... + def get_db_prep_value(self, value, connection, prepared=False): ... - def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False): - ... + def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False): ... These changes are required to support multiple databases -- ``db_type`` and ``get_db_prep_*`` can no longer make any assumptions diff --git a/docs/releases/5.0.txt b/docs/releases/5.0.txt index 746eaae836..6b18bace4f 100644 --- a/docs/releases/5.0.txt +++ b/docs/releases/5.0.txt @@ -521,8 +521,7 @@ For example:: Should become:: - class Char32UUIDField(models.UUIDField): - ... + class Char32UUIDField(models.UUIDField): ... class MyModel(models.Model): 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: |