[3.0.x] Removed unnecessary code-block directives in various docs.

Backport of 5e00bd1f7717149573df9607b848297a520881d3 from master

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 </topics/db/queries>`
 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 6fb6f55a0b..8ec84f8a68 100644
--- a/docs/ref/contrib/staticfiles.txt
+++ b/docs/ref/contrib/staticfiles.txt
@@ -139,9 +139,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 0aa23e8a27..2b9d61778c 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 ea7f9f2df7..5c3dd19aa7 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -318,9 +318,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
@@ -373,9 +371,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)
@@ -394,9 +390,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()
@@ -898,9 +892,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)
@@ -918,9 +910,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 <topic-email-backends>` 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': {