Removed unnecessary code-block directives in various docs.

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

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
 

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)

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

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)

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': {