From 5e00bd1f7717149573df9607b848297a520881d3 Mon Sep 17 00:00:00 2001 From: Jon Dufresne Date: Mon, 23 Dec 2019 05:47:13 -0800 Subject: [PATCH] Removed unnecessary code-block directives in various docs. --- docs/intro/overview.txt | 4 +--- docs/ref/contrib/staticfiles.txt | 4 +--- docs/ref/files/uploads.txt | 4 +--- docs/topics/db/aggregation.txt | 9 +++------ docs/topics/forms/modelforms.txt | 20 +++++--------------- docs/topics/logging.txt | 24 ++++++------------------ 6 files changed, 17 insertions(+), 48 deletions(-) diff --git a/docs/intro/overview.txt b/docs/intro/overview.txt index a1d82137ad..fa61e4ec57 100644 --- a/docs/intro/overview.txt +++ b/docs/intro/overview.txt @@ -66,9 +66,7 @@ Enjoy the free API With that, you've got a free, and rich, :doc:`Python API ` to access your data. The API is created on the fly, no code generation -necessary: - -.. code-block:: python +necessary:: # Import the models we created from our "news" app >>> from news.models import Article, Reporter diff --git a/docs/ref/contrib/staticfiles.txt b/docs/ref/contrib/staticfiles.txt index 591cba6385..eefd1e3039 100644 --- a/docs/ref/contrib/staticfiles.txt +++ b/docs/ref/contrib/staticfiles.txt @@ -135,9 +135,7 @@ a more persistent way than providing the ``--ignore`` command option at each ``collectstatic`` invocation. Provide a custom :class:`~django.apps.AppConfig` class, override the ``ignore_patterns`` attribute of this class and replace ``'django.contrib.staticfiles'`` with that class path in your -:setting:`INSTALLED_APPS` setting: - -.. code-block:: python +:setting:`INSTALLED_APPS` setting:: from django.contrib.staticfiles.apps import StaticFilesConfig diff --git a/docs/ref/files/uploads.txt b/docs/ref/files/uploads.txt index 4b58d2a4e2..cd6cc0df5f 100644 --- a/docs/ref/files/uploads.txt +++ b/docs/ref/files/uploads.txt @@ -73,9 +73,7 @@ Here are some useful attributes of ``UploadedFile``: .. note:: Like regular Python files, you can read the file line-by-line by iterating - over the uploaded file: - - .. code-block:: python + over the uploaded file:: for line in uploadedfile: do_something_with(line) diff --git a/docs/topics/db/aggregation.txt b/docs/topics/db/aggregation.txt index c3c7f18afd..cc6310052a 100644 --- a/docs/topics/db/aggregation.txt +++ b/docs/topics/db/aggregation.txt @@ -43,9 +43,8 @@ used to track the inventory for a series of online bookstores: Cheat sheet =========== -In a hurry? Here's how to do common aggregate queries, assuming the models above: - -.. code-block:: python +In a hurry? Here's how to do common aggregate queries, assuming the models +above:: # Total number of books. >>> Book.objects.count() @@ -160,9 +159,7 @@ specified values. The syntax for these annotations is identical to that used for the :meth:`~.QuerySet.aggregate` clause. Each argument to ``annotate()`` describes an aggregate that is to be calculated. For example, to annotate books with the -number of authors: - -.. code-block:: python +number of authors:: # Build an annotated queryset >>> from django.db.models import Count diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt index d077b4c195..c3e6e5c99e 100644 --- a/docs/topics/forms/modelforms.txt +++ b/docs/topics/forms/modelforms.txt @@ -320,9 +320,7 @@ Every ``ModelForm`` also has a ``save()`` method. This method creates and saves a database object from the data bound to the form. A subclass of ``ModelForm`` can accept an existing model instance as the keyword argument ``instance``; if this is supplied, ``save()`` will update that instance. If it's not supplied, -``save()`` will create a new instance of the specified model: - -.. code-block:: python +``save()`` will create a new instance of the specified model:: >>> from myapp.models import Article >>> from myapp.forms import ArticleForm @@ -375,9 +373,7 @@ exists in the database. To work around this problem, every time you save a form using ``commit=False``, Django adds a ``save_m2m()`` method to your ``ModelForm`` subclass. After you've manually saved the instance produced by the form, you can invoke -``save_m2m()`` to save the many-to-many form data. For example: - -.. code-block:: python +``save_m2m()`` to save the many-to-many form data. For example:: # Create a form instance with POST data. >>> f = AuthorForm(request.POST) @@ -396,9 +392,7 @@ you've manually saved the instance produced by the form, you can invoke Calling ``save_m2m()`` is only required if you use ``save(commit=False)``. When you use a ``save()`` on a form, all data -- including many-to-many data -- -is saved without the need for any additional method calls. For example: - -.. code-block:: python +is saved without the need for any additional method calls. For example:: # Create a form instance with POST data. >>> a = Author() @@ -900,9 +894,7 @@ Saving objects in the formset ----------------------------- As with a ``ModelForm``, you can save the data as a model object. This is done -with the formset's ``save()`` method: - -.. code-block:: python +with the formset's ``save()`` method:: # Create a formset instance with POST data. >>> formset = AuthorFormSet(request.POST) @@ -920,9 +912,7 @@ excluded), these fields will not be set by the ``save()`` method. You can find more information about this restriction, which also holds for regular ``ModelForms``, in `Selecting the fields to use`_. -Pass ``commit=False`` to return the unsaved model instances: - -.. code-block:: python +Pass ``commit=False`` to return the unsaved model instances:: # don't save to the database >>> instances = formset.save(commit=False) diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt index 789fa794d5..b8b3162fe5 100644 --- a/docs/topics/logging.txt +++ b/docs/topics/logging.txt @@ -559,9 +559,7 @@ to a ``SuspiciousOperation`` will not be logged to the ``django.request`` logger, but only to the ``django.security`` logger. To silence a particular type of ``SuspiciousOperation``, you can override that -specific logger following this example: - -.. code-block:: python +specific logger following this example:: 'handlers': { 'null': { @@ -613,9 +611,7 @@ Python logging module. containing the full content of the debug Web page that would have been produced if :setting:`DEBUG` were ``True``. To set this value in your configuration, include it in the handler definition for - ``django.utils.log.AdminEmailHandler``, like this: - - .. code-block:: python + ``django.utils.log.AdminEmailHandler``, like this:: 'handlers': { 'mail_admins': { @@ -637,9 +633,7 @@ Python logging module. By setting the ``email_backend`` argument of ``AdminEmailHandler``, the :ref:`email backend ` that is being used by the - handler can be overridden, like this: - - .. code-block:: python + handler can be overridden, like this:: 'handlers': { 'mail_admins': { @@ -655,9 +649,7 @@ Python logging module. The ``reporter_class`` argument of ``AdminEmailHandler`` allows providing an ``django.views.debug.ExceptionReporter`` subclass to customize the traceback text sent in the email body. You provide a string import path to - the class you wish to use, like this: - - .. code-block:: python + the class you wish to use, like this:: 'handlers': { 'mail_admins': { @@ -706,9 +698,7 @@ logging module. return False return True - and then add it to your logging config: - - .. code-block:: python + and then add it to your logging config:: 'filters': { 'skip_unreadable_posts': { @@ -730,9 +720,7 @@ logging module. This filter is used as follows in the default :setting:`LOGGING` configuration to ensure that the :class:`AdminEmailHandler` only sends - error emails to admins when :setting:`DEBUG` is ``False``: - - .. code-block:: python + error emails to admins when :setting:`DEBUG` is ``False``:: 'filters': { 'require_debug_false': {