Fixed many more ReST indentation errors, somehow accidentally missed from [16955]

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37

6 files changed, 284 insertions, 284 deletions

diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
index e5298ef2cb..1c1ef776bb 100644
--- a/docs/topics/http/file-uploads.txt
+++ b/docs/topics/http/file-uploads.txt
@@ -133,51 +133,51 @@ Changing upload handler behavior
 
 Three settings control Django's file upload behavior:
 
-    :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE`
-        The maximum size, in bytes, for files that will be uploaded into memory.
-        Files larger than :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE` will be
-        streamed to disk.
+:setting:`FILE_UPLOAD_MAX_MEMORY_SIZE`
+    The maximum size, in bytes, for files that will be uploaded into memory.
+    Files larger than :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE` will be
+    streamed to disk.
 
-        Defaults to 2.5 megabytes.
+    Defaults to 2.5 megabytes.
 
-    :setting:`FILE_UPLOAD_TEMP_DIR`
-        The directory where uploaded files larger than
-        :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE` will be stored.
+:setting:`FILE_UPLOAD_TEMP_DIR`
+    The directory where uploaded files larger than
+    :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE` will be stored.
 
-        Defaults to your system's standard temporary directory (i.e. ``/tmp`` on
-        most Unix-like systems).
+    Defaults to your system's standard temporary directory (i.e. ``/tmp`` on
+    most Unix-like systems).
 
-    :setting:`FILE_UPLOAD_PERMISSIONS`
-        The numeric mode (i.e. ``0644``) to set newly uploaded files to. For
-        more information about what these modes mean, see the documentation for
-        :func:`os.chmod`.
+:setting:`FILE_UPLOAD_PERMISSIONS`
+    The numeric mode (i.e. ``0644``) to set newly uploaded files to. For
+    more information about what these modes mean, see the documentation for
+    :func:`os.chmod`.
 
-        If this isn't given or is ``None``, you'll get operating-system
-        dependent behavior. On most platforms, temporary files will have a mode
-        of ``0600``, and files saved from memory will be saved using the
-        system's standard umask.
+    If this isn't given or is ``None``, you'll get operating-system
+    dependent behavior. On most platforms, temporary files will have a mode
+    of ``0600``, and files saved from memory will be saved using the
+    system's standard umask.
 
-        .. warning::
+    .. warning::
 
-            If you're not familiar with file modes, please note that the leading
-            ``0`` is very important: it indicates an octal number, which is the
-            way that modes must be specified. If you try to use ``644``, you'll
-            get totally incorrect behavior.
+        If you're not familiar with file modes, please note that the leading
+        ``0`` is very important: it indicates an octal number, which is the
+        way that modes must be specified. If you try to use ``644``, you'll
+        get totally incorrect behavior.
 
-            **Always prefix the mode with a 0.**
+        **Always prefix the mode with a 0.**
 
-    :setting:`FILE_UPLOAD_HANDLERS`
-        The actual handlers for uploaded files. Changing this setting allows
-        complete customization -- even replacement -- of Django's upload
-        process. See `upload handlers`_, below, for details.
+:setting:`FILE_UPLOAD_HANDLERS`
+    The actual handlers for uploaded files. Changing this setting allows
+    complete customization -- even replacement -- of Django's upload
+    process. See `upload handlers`_, below, for details.
 
-        Defaults to::
+    Defaults to::
 
-            ("django.core.files.uploadhandler.MemoryFileUploadHandler",
-             "django.core.files.uploadhandler.TemporaryFileUploadHandler",)
+        ("django.core.files.uploadhandler.MemoryFileUploadHandler",
+         "django.core.files.uploadhandler.TemporaryFileUploadHandler",)
 
-        Which means "try to upload to memory first, then fall back to temporary
-        files."
+    Which means "try to upload to memory first, then fall back to temporary
+    files."
 
 ``UploadedFile`` objects
 ========================
@@ -312,32 +312,32 @@ Required methods
 
 Custom file upload handlers **must** define the following methods:
 
-    ``FileUploadHandler.receive_data_chunk(self, raw_data, start)``
-        Receives a "chunk" of data from the file upload.
+``FileUploadHandler.receive_data_chunk(self, raw_data, start)``
+    Receives a "chunk" of data from the file upload.
 
-        ``raw_data`` is a byte string containing the uploaded data.
+    ``raw_data`` is a byte string containing the uploaded data.
 
-        ``start`` is the position in the file where this ``raw_data`` chunk
-        begins.
+    ``start`` is the position in the file where this ``raw_data`` chunk
+    begins.
 
-        The data you return will get fed into the subsequent upload handlers'
-        ``receive_data_chunk`` methods. In this way, one handler can be a
-        "filter" for other handlers.
+    The data you return will get fed into the subsequent upload handlers'
+    ``receive_data_chunk`` methods. In this way, one handler can be a
+    "filter" for other handlers.
 
-        Return ``None`` from ``receive_data_chunk`` to sort-circuit remaining
-        upload handlers from getting this chunk.. This is useful if you're
-        storing the uploaded data yourself and don't want future handlers to
-        store a copy of the data.
+    Return ``None`` from ``receive_data_chunk`` to sort-circuit remaining
+    upload handlers from getting this chunk.. This is useful if you're
+    storing the uploaded data yourself and don't want future handlers to
+    store a copy of the data.
 
-        If you raise a ``StopUpload`` or a ``SkipFile`` exception, the upload
-        will abort or the file will be completely skipped.
+    If you raise a ``StopUpload`` or a ``SkipFile`` exception, the upload
+    will abort or the file will be completely skipped.
 
-    ``FileUploadHandler.file_complete(self, file_size)``
-        Called when a file has finished uploading.
+``FileUploadHandler.file_complete(self, file_size)``
+    Called when a file has finished uploading.
 
-        The handler should return an ``UploadedFile`` object that will be stored
-        in ``request.FILES``. Handlers may also return ``None`` to indicate that
-        the ``UploadedFile`` object should come from subsequent upload handlers.
+    The handler should return an ``UploadedFile`` object that will be stored
+    in ``request.FILES``. Handlers may also return ``None`` to indicate that
+    the ``UploadedFile`` object should come from subsequent upload handlers.
 
 Optional methods
 ~~~~~~~~~~~~~~~~
@@ -345,56 +345,56 @@ Optional methods
 Custom upload handlers may also define any of the following optional methods or
 attributes:
 
-    ``FileUploadHandler.chunk_size``
-        Size, in bytes, of the "chunks" Django should store into memory and feed
-        into the handler. That is, this attribute controls the size of chunks
-        fed into ``FileUploadHandler.receive_data_chunk``.
+``FileUploadHandler.chunk_size``
+    Size, in bytes, of the "chunks" Django should store into memory and feed
+    into the handler. That is, this attribute controls the size of chunks
+    fed into ``FileUploadHandler.receive_data_chunk``.
 
-        For maximum performance the chunk sizes should be divisible by ``4`` and
-        should not exceed 2 GB (2\ :sup:`31` bytes) in size. When there are
-        multiple chunk sizes provided by multiple handlers, Django will use the
-        smallest chunk size defined by any handler.
+    For maximum performance the chunk sizes should be divisible by ``4`` and
+    should not exceed 2 GB (2\ :sup:`31` bytes) in size. When there are
+    multiple chunk sizes provided by multiple handlers, Django will use the
+    smallest chunk size defined by any handler.
 
-        The default is 64*2\ :sup:`10` bytes, or 64 KB.
+    The default is 64*2\ :sup:`10` bytes, or 64 KB.
 
-    ``FileUploadHandler.new_file(self, field_name, file_name, content_type, content_length, charset)``
-        Callback signaling that a new file upload is starting. This is called
-        before any data has been fed to any upload handlers.
+``FileUploadHandler.new_file(self, field_name, file_name, content_type, content_length, charset)``
+    Callback signaling that a new file upload is starting. This is called
+    before any data has been fed to any upload handlers.
 
-        ``field_name`` is a string name of the file ``<input>`` field.
+    ``field_name`` is a string name of the file ``<input>`` field.
 
-        ``file_name`` is the unicode filename that was provided by the browser.
+    ``file_name`` is the unicode filename that was provided by the browser.
 
-        ``content_type`` is the MIME type provided by the browser -- E.g.
-        ``'image/jpeg'``.
+    ``content_type`` is the MIME type provided by the browser -- E.g.
+    ``'image/jpeg'``.
 
-        ``content_length`` is the length of the image given by the browser.
-        Sometimes this won't be provided and will be ``None``.
+    ``content_length`` is the length of the image given by the browser.
+    Sometimes this won't be provided and will be ``None``.
 
-        ``charset`` is the character set (i.e. ``utf8``) given by the browser.
-        Like ``content_length``, this sometimes won't be provided.
+    ``charset`` is the character set (i.e. ``utf8``) given by the browser.
+    Like ``content_length``, this sometimes won't be provided.
 
-        This method may raise a ``StopFutureHandlers`` exception to prevent
-        future handlers from handling this file.
+    This method may raise a ``StopFutureHandlers`` exception to prevent
+    future handlers from handling this file.
 
-    ``FileUploadHandler.upload_complete(self)``
-        Callback signaling that the entire upload (all files) has completed.
+``FileUploadHandler.upload_complete(self)``
+    Callback signaling that the entire upload (all files) has completed.
 
-    ``FileUploadHandler.handle_raw_input(self, input_data, META, content_length, boundary, encoding)``
-        Allows the handler to completely override the parsing of the raw
-        HTTP input.
+``FileUploadHandler.handle_raw_input(self, input_data, META, content_length, boundary, encoding)``
+    Allows the handler to completely override the parsing of the raw
+    HTTP input.
 
-        ``input_data`` is a file-like object that supports ``read()``-ing.
+    ``input_data`` is a file-like object that supports ``read()``-ing.
 
-        ``META`` is the same object as ``request.META``.
+    ``META`` is the same object as ``request.META``.
 
-        ``content_length`` is the length of the data in ``input_data``. Don't
-        read more than ``content_length`` bytes from ``input_data``.
+    ``content_length`` is the length of the data in ``input_data``. Don't
+    read more than ``content_length`` bytes from ``input_data``.
 
-        ``boundary`` is the MIME boundary for this request.
+    ``boundary`` is the MIME boundary for this request.
 
-        ``encoding`` is the encoding of the request.
+    ``encoding`` is the encoding of the request.
 
-        Return ``None`` if you want upload handling to continue, or a tuple of
-        ``(POST, FILES)`` if you want to return the new data structures suitable
-        for the request directly.
+    Return ``None`` if you want upload handling to continue, or a tuple of
+    ``(POST, FILES)`` if you want to return the new data structures suitable
+    for the request directly.
diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index 01a5bd4cd3..a768a3bbd8 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -195,11 +195,11 @@ essentially placeholders for the ``process_*`` methods. If you do need some
 global state you may use ``__init__`` to set up. However, keep in mind a couple
 of caveats:
 
-    * Django initializes your middleware without any arguments, so you can't
-      define ``__init__`` as requiring any arguments.
+* Django initializes your middleware without any arguments, so you can't
+  define ``__init__`` as requiring any arguments.
 
-    * Unlike the ``process_*`` methods which get called once per request,
-      ``__init__`` gets called only *once*, when the Web server starts up.
+* Unlike the ``process_*`` methods which get called once per request,
+  ``__init__`` gets called only *once*, when the Web server starts up.
 
 Marking middleware as unused
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -212,15 +212,15 @@ piece of middleware from the middleware process.
 Guidelines
 ----------
 
-    * Middleware classes don't have to subclass anything.
+* Middleware classes don't have to subclass anything.
 
-    * The middleware class can live anywhere on your Python path. All Django
-      cares about is that the :setting:`MIDDLEWARE_CLASSES` setting includes
-      the path to it.
+* The middleware class can live anywhere on your Python path. All Django
+  cares about is that the :setting:`MIDDLEWARE_CLASSES` setting includes
+  the path to it.
 
-    * Feel free to look at :doc:`Django's available middleware
-      </ref/middleware>` for examples.
+* Feel free to look at :doc:`Django's available middleware
+  </ref/middleware>` for examples.
 
-    * If you write a middleware component that you think would be useful to
-      other people, contribute to the community! :doc:`Let us know
-      </internals/contributing/index>`, and we'll consider adding it to Django.
+* If you write a middleware component that you think would be useful to
+  other people, contribute to the community! :doc:`Let us know
+  </internals/contributing/index>`, and we'll consider adding it to Django.
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 494b37cb94..a2849ae6eb 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -18,10 +18,10 @@ Sessions are implemented via a piece of :doc:`middleware </ref/middleware>`.
 
 To enable session functionality, do the following:
 
-    * Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
-      it contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
-      The default ``settings.py`` created by ``django-admin.py startproject``
-      has ``SessionMiddleware`` activated.
+* Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
+  it contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
+  The default ``settings.py`` created by ``django-admin.py startproject``
+  has ``SessionMiddleware`` activated.
 
 If you don't want to use sessions, you might as well remove the
 ``SessionMiddleware`` line from :setting:`MIDDLEWARE_CLASSES` and
@@ -65,17 +65,17 @@ sure you've configured your cache; see the :doc:`cache documentation
 Once your cache is configured, you've got two choices for how to store data in
 the cache:
 
-    * Set :setting:`SESSION_ENGINE` to
-      ``"django.contrib.sessions.backends.cache"`` for a simple caching session
-      store. Session data will be stored directly your cache. However, session
-      data may not be persistent: cached data can be evicted if the cache fills
-      up or if the cache server is restarted.
+* Set :setting:`SESSION_ENGINE` to
+  ``"django.contrib.sessions.backends.cache"`` for a simple caching session
+  store. Session data will be stored directly your cache. However, session
+  data may not be persistent: cached data can be evicted if the cache fills
+  up or if the cache server is restarted.
 
-    * For persistent, cached data, set :setting:`SESSION_ENGINE` to
-      ``"django.contrib.sessions.backends.cached_db"``. This uses a
-      write-through cache -- every write to the cache will also be written to
-      the database. Session reads only use the database if the data is not
-      already in the cache.
+* For persistent, cached data, set :setting:`SESSION_ENGINE` to
+  ``"django.contrib.sessions.backends.cached_db"``. This uses a
+  write-through cache -- every write to the cache will also be written to
+  the database. Session reads only use the database if the data is not
+  already in the cache.
 
 Both session stores are quite fast, but the simple cache is faster because it
 disregards persistence. In most cases, the ``cached_db`` backend will be fast
@@ -210,19 +210,19 @@ You can edit it multiple times.
       Sets the expiration time for the session. You can pass a number of
       different values:
 
-            * If ``value`` is an integer, the session will expire after that
-              many seconds of inactivity. For example, calling
-              ``request.session.set_expiry(300)`` would make the session expire
-              in 5 minutes.
+      * If ``value`` is an integer, the session will expire after that
+        many seconds of inactivity. For example, calling
+        ``request.session.set_expiry(300)`` would make the session expire
+        in 5 minutes.
 
-            * If ``value`` is a ``datetime`` or ``timedelta`` object, the
-              session will expire at that specific date/time.
+      * If ``value`` is a ``datetime`` or ``timedelta`` object, the
+        session will expire at that specific date/time.
 
-            * If ``value`` is ``0``, the user's session cookie will expire
-              when the user's Web browser is closed.
+      * If ``value`` is ``0``, the user's session cookie will expire
+        when the user's Web browser is closed.
 
-            * If ``value`` is ``None``, the session reverts to using the global
-              session expiry policy.
+      * If ``value`` is ``None``, the session reverts to using the global
+        session expiry policy.
 
       Reading a session is not considered activity for expiration
       purposes. Session expiration is computed from the last time the
@@ -248,14 +248,14 @@ You can edit it multiple times.
 Session object guidelines
 -------------------------
 
-    * Use normal Python strings as dictionary keys on ``request.session``. This
-      is more of a convention than a hard-and-fast rule.
+* Use normal Python strings as dictionary keys on ``request.session``. This
+  is more of a convention than a hard-and-fast rule.
 
-    * Session dictionary keys that begin with an underscore are reserved for
-      internal use by Django.
+* Session dictionary keys that begin with an underscore are reserved for
+  internal use by Django.
 
-    * Don't override ``request.session`` with a new object, and don't access or
-      set its attributes. Use it like a Python dictionary.
+* Don't override ``request.session`` with a new object, and don't access or
+  set its attributes. Use it like a Python dictionary.
 
 Examples
 --------
@@ -453,11 +453,11 @@ Default: ``django.contrib.sessions.backends.db``
 
 Controls where Django stores session data. Valid values are:
 
-    * ``'django.contrib.sessions.backends.db'``
-    * ``'django.contrib.sessions.backends.file'``
-    * ``'django.contrib.sessions.backends.cache'``
-    * ``'django.contrib.sessions.backends.cached_db'``
-    * ``'django.contrib.sessions.backends.signed_cookies'``
+* ``'django.contrib.sessions.backends.db'``
+* ``'django.contrib.sessions.backends.file'``
+* ``'django.contrib.sessions.backends.cache'``
+* ``'django.contrib.sessions.backends.cached_db'``
+* ``'django.contrib.sessions.backends.signed_cookies'``
 
 See `configuring the session engine`_ for more details.
 
@@ -552,13 +552,13 @@ that is, if any of its dictionary values have been assigned or deleted.
 Technical details
 =================
 
-    * The session dictionary should accept any pickleable Python object. See
-      the :mod:`pickle` module for more information.
+* The session dictionary should accept any pickleable Python object. See
+  the :mod:`pickle` module for more information.
 
-    * Session data is stored in a database table named ``django_session`` .
+* Session data is stored in a database table named ``django_session`` .
 
-    * Django only sends a cookie if it needs to. If you don't set any session
-      data, it won't send a session cookie.
+* Django only sends a cookie if it needs to. If you don't set any session
+  data, it won't send a session cookie.
 
 Session IDs in URLs
 ===================
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 64b7c4a7e7..9c05c6e5e9 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -162,12 +162,12 @@ This example is equivalent to::
 
    The arguments could be:
 
-       * A model: the model's `get_absolute_url()` function will be called.
+   * A model: the model's `get_absolute_url()` function will be called.
 
-       * A view name, possibly with arguments: `urlresolvers.reverse()` will
-         be used to reverse-resolve the name.
+   * A view name, possibly with arguments: `urlresolvers.reverse()` will
+     be used to reverse-resolve the name.
 
-       * A URL, which will be used as-is for the redirect location.
+   * A URL, which will be used as-is for the redirect location.
 
    By default issues a temporary redirect; pass ``permanent=True`` to issue a
    permanent redirect
@@ -177,34 +177,34 @@ Examples
 
 You can use the :func:`redirect` function in a number of ways.
 
-    1. By passing some object; that object's
-       :meth:`~django.db.models.Model.get_absolute_url` method will be called
-       to figure out the redirect URL::
+1. By passing some object; that object's
+   :meth:`~django.db.models.Model.get_absolute_url` method will be called
+   to figure out the redirect URL::
 
-            def my_view(request):
-                ...
-                object = MyModel.objects.get(...)
-                return redirect(object)
+        def my_view(request):
+            ...
+            object = MyModel.objects.get(...)
+            return redirect(object)
 
-    2. By passing the name of a view and optionally some positional or
-       keyword arguments; the URL will be reverse resolved using the
-       :func:`~django.core.urlresolvers.reverse` method::
+2. By passing the name of a view and optionally some positional or
+   keyword arguments; the URL will be reverse resolved using the
+   :func:`~django.core.urlresolvers.reverse` method::
 
-            def my_view(request):
-                ...
-                return redirect('some-view-name', foo='bar')
+        def my_view(request):
+            ...
+            return redirect('some-view-name', foo='bar')
 
-    3. By passing a hardcoded URL to redirect to::
+3. By passing a hardcoded URL to redirect to::
 
-            def my_view(request):
-                ...
-                return redirect('/some/url/')
+        def my_view(request):
+            ...
+            return redirect('/some/url/')
 
-       This also works with full URLs::
+   This also works with full URLs::
 
-            def my_view(request):
-                ...
-                return redirect('http://example.com/')
+        def my_view(request):
+            ...
+            return redirect('http://example.com/')
 
 By default, :func:`redirect` returns a temporary redirect. All of the above
 forms accept a ``permanent`` argument; if set to ``True`` a permanent redirect
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index 14d8a65e40..9349762312 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -42,27 +42,27 @@ How Django processes a request
 When a user requests a page from your Django-powered site, this is the
 algorithm the system follows to determine which Python code to execute:
 
-    1. Django determines the root URLconf module to use. Ordinarily,
-       this is the value of the :setting:`ROOT_URLCONF` setting, but if the incoming
-       ``HttpRequest`` object has an attribute called ``urlconf`` (set by
-       middleware :ref:`request processing <request-middleware>`), its value
-       will be used in place of the :setting:`ROOT_URLCONF` setting.
+1. Django determines the root URLconf module to use. Ordinarily,
+   this is the value of the :setting:`ROOT_URLCONF` setting, but if the incoming
+   ``HttpRequest`` object has an attribute called ``urlconf`` (set by
+   middleware :ref:`request processing <request-middleware>`), its value
+   will be used in place of the :setting:`ROOT_URLCONF` setting.
 
-    2. Django loads that Python module and looks for the variable
-       ``urlpatterns``. This should be a Python list, in the format returned by
-       the function :func:`django.conf.urls.patterns`.
+2. Django loads that Python module and looks for the variable
+   ``urlpatterns``. This should be a Python list, in the format returned by
+   the function :func:`django.conf.urls.patterns`.
 
-    3. Django runs through each URL pattern, in order, and stops at the first
-       one that matches the requested URL.
+3. Django runs through each URL pattern, in order, and stops at the first
+   one that matches the requested URL.
 
-    4. Once one of the regexes matches, Django imports and calls the given
-       view, which is a simple Python function. The view gets passed an
-       :class:`~django.http.HttpRequest` as its first argument and any values
-       captured in the regex as remaining arguments.
+4. Once one of the regexes matches, Django imports and calls the given
+   view, which is a simple Python function. The view gets passed an
+   :class:`~django.http.HttpRequest` as its first argument and any values
+   captured in the regex as remaining arguments.
 
-    5. If no regex matches, or if an exception is raised during any
-       point in this process, Django invokes an appropriate
-       error-handling view. See `Error handling`_ below.
+5. If no regex matches, or if an exception is raised during any
+   point in this process, Django invokes an appropriate
+   error-handling view. See `Error handling`_ below.
 
 Example
 =======
@@ -80,34 +80,34 @@ Here's a sample URLconf::
 
 Notes:
 
-    * To capture a value from the URL, just put parenthesis around it.
+* To capture a value from the URL, just put parenthesis around it.
 
-    * There's no need to add a leading slash, because every URL has that. For
-      example, it's ``^articles``, not ``^/articles``.
+* There's no need to add a leading slash, because every URL has that. For
+  example, it's ``^articles``, not ``^/articles``.
 
-    * The ``'r'`` in front of each regular expression string is optional but
-      recommended. It tells Python that a string is "raw" -- that nothing in
-      the string should be escaped. See `Dive Into Python's explanation`_.
+* The ``'r'`` in front of each regular expression string is optional but
+  recommended. It tells Python that a string is "raw" -- that nothing in
+  the string should be escaped. See `Dive Into Python's explanation`_.
 
 Example requests:
 
-    * A request to ``/articles/2005/03/`` would match the third entry in the
-      list. Django would call the function
-      ``news.views.month_archive(request, '2005', '03')``.
+* A request to ``/articles/2005/03/`` would match the third entry in the
+  list. Django would call the function
+  ``news.views.month_archive(request, '2005', '03')``.
 
-    * ``/articles/2005/3/`` would not match any URL patterns, because the
-      third entry in the list requires two digits for the month.
+* ``/articles/2005/3/`` would not match any URL patterns, because the
+  third entry in the list requires two digits for the month.
 
-    * ``/articles/2003/`` would match the first pattern in the list, not the
-      second one, because the patterns are tested in order, and the first one
-      is the first test to pass. Feel free to exploit the ordering to insert
-      special cases like this.
+* ``/articles/2003/`` would match the first pattern in the list, not the
+  second one, because the patterns are tested in order, and the first one
+  is the first test to pass. Feel free to exploit the ordering to insert
+  special cases like this.
 
-    * ``/articles/2003`` would not match any of these patterns, because each
-      pattern requires that the URL end with a slash.
+* ``/articles/2003`` would not match any of these patterns, because each
+  pattern requires that the URL end with a slash.
 
-    * ``/articles/2003/03/03/`` would match the final pattern. Django would call
-      the function ``news.views.article_detail(request, '2003', '03', '03')``.
+* ``/articles/2003/03/03/`` would match the final pattern. Django would call
+  the function ``news.views.article_detail(request, '2003', '03', '03')``.
 
 .. _Dive Into Python's explanation: http://diveintopython.org/regular_expressions/street_addresses.html#re.matching.2.3
 
@@ -137,12 +137,12 @@ This accomplishes exactly the same thing as the previous example, with one
 subtle difference: The captured values are passed to view functions as keyword
 arguments rather than positional arguments. For example:
 
-    * A request to ``/articles/2005/03/`` would call the function
-      ``news.views.month_archive(request, year='2005', month='03')``, instead
-      of ``news.views.month_archive(request, '2005', '03')``.
+* A request to ``/articles/2005/03/`` would call the function
+  ``news.views.month_archive(request, year='2005', month='03')``, instead
+  of ``news.views.month_archive(request, '2005', '03')``.
 
-    * A request to ``/articles/2003/03/03/`` would call the function
-      ``news.views.article_detail(request, year='2003', month='03', day='03')``.
+* A request to ``/articles/2003/03/03/`` would call the function
+  ``news.views.article_detail(request, year='2003', month='03', day='03')``.
 
 In practice, this means your URLconfs are slightly more explicit and less prone
 to argument-order bugs -- and you can reorder the arguments in your views'
@@ -518,17 +518,17 @@ provide a way to tell these named URLs apart.
 
 A URL namespace comes in two parts, both of which are strings:
 
-    * An **application namespace**. This describes the name of the application
-      that is being deployed. Every instance of a single application will have
-      the same application namespace. For example, Django's admin application
-      has the somewhat predictable application namespace of ``admin``.
+* An **application namespace**. This describes the name of the application
+  that is being deployed. Every instance of a single application will have
+  the same application namespace. For example, Django's admin application
+  has the somewhat predictable application namespace of ``admin``.
 
-    * An **instance namespace**. This identifies a specific instance of an
-      application. Instance namespaces should be unique across your entire
-      project. However, an instance namespace can be the same as the
-      application namespace. This is used to specify a default instance of an
-      application. For example, the default Django Admin instance has an
-      instance namespace of ``admin``.
+* An **instance namespace**. This identifies a specific instance of an
+  application. Instance namespaces should be unique across your entire
+  project. However, an instance namespace can be the same as the
+  application namespace. This is used to specify a default instance of an
+  application. For example, the default Django Admin instance has an
+  instance namespace of ``admin``.
 
 URL Namespaces can be specified in two ways.
 
@@ -745,31 +745,31 @@ the top-level namespace ``foo``.
 When given a namespaced URL (e.g. ``myapp:index``) to resolve, Django splits
 the fully qualified name into parts, and then tries the following lookup:
 
-    1. First, Django looks for a matching application namespace (in this
-       example, ``myapp``). This will yield a list of instances of that
-       application.
+1. First, Django looks for a matching application namespace (in this
+   example, ``myapp``). This will yield a list of instances of that
+   application.
 
-    2. If there is a *current* application defined, Django finds and returns
-       the URL resolver for that instance. The *current* application can be
-       specified as an attribute on the template context - applications that
-       expect to have multiple deployments should set the ``current_app``
-       attribute on any ``Context`` or ``RequestContext`` that is used to
-       render a template.
+2. If there is a *current* application defined, Django finds and returns
+   the URL resolver for that instance. The *current* application can be
+   specified as an attribute on the template context - applications that
+   expect to have multiple deployments should set the ``current_app``
+   attribute on any ``Context`` or ``RequestContext`` that is used to
+   render a template.
 
-       The current application can also be specified manually as an argument
-       to the :func:`reverse()` function.
+   The current application can also be specified manually as an argument
+   to the :func:`reverse()` function.
 
-    3. If there is no current application. Django looks for a default
-       application instance. The default application instance is the instance
-       that has an instance namespace matching the application namespace (in
-       this example, an instance of the ``myapp`` called ``myapp``).
+3. If there is no current application. Django looks for a default
+   application instance. The default application instance is the instance
+   that has an instance namespace matching the application namespace (in
+   this example, an instance of the ``myapp`` called ``myapp``).
 
-    4. If there is no default application instance, Django will pick the last
-       deployed instance of the application, whatever its instance name may be.
+4. If there is no default application instance, Django will pick the last
+   deployed instance of the application, whatever its instance name may be.
 
-    5. If the provided namespace doesn't match an application namespace in
-       step 1, Django will attempt a direct lookup of the namespace as an
-       instance namespace.
+5. If the provided namespace doesn't match an application namespace in
+   step 1, Django will attempt a direct lookup of the namespace as an
+   instance namespace.
 
 If there are nested namespaces, these steps are repeated for each part of the
 namespace until only the view name is unresolved. The view name will then be
@@ -780,31 +780,31 @@ of ``myapp``: one called ``foo``, and one called ``bar``. ``myapp`` has a main
 index page with a URL named `index`. Using this setup, the following lookups are
 possible:
 
-    * If one of the instances is current - say, if we were rendering a utility page
-      in the instance ``bar`` - ``myapp:index`` will resolve to the index page of
-      the instance ``bar``.
+* If one of the instances is current - say, if we were rendering a utility page
+  in the instance ``bar`` - ``myapp:index`` will resolve to the index page of
+  the instance ``bar``.
 
-    * If there is no current instance - say, if we were rendering a page
-      somewhere else on the site - ``myapp:index`` will resolve to the last
-      registered instance of ``myapp``. Since there is no default instance,
-      the last instance of ``myapp`` that is registered will be used. This could
-      be ``foo`` or ``bar``, depending on the order they are introduced into the
-      urlpatterns of the project.
+* If there is no current instance - say, if we were rendering a page
+  somewhere else on the site - ``myapp:index`` will resolve to the last
+  registered instance of ``myapp``. Since there is no default instance,
+  the last instance of ``myapp`` that is registered will be used. This could
+  be ``foo`` or ``bar``, depending on the order they are introduced into the
+  urlpatterns of the project.
 
-    * ``foo:index`` will always resolve to the index page of the instance ``foo``.
+* ``foo:index`` will always resolve to the index page of the instance ``foo``.
 
 If there was also a default instance - i.e., an instance named `myapp` - the
 following would happen:
 
-    * If one of the instances is current - say, if we were rendering a utility page
-      in the instance ``bar`` - ``myapp:index`` will resolve to the index page of
-      the instance ``bar``.
+* If one of the instances is current - say, if we were rendering a utility page
+  in the instance ``bar`` - ``myapp:index`` will resolve to the index page of
+  the instance ``bar``.
 
-    * If there is no current instance - say, if we were rendering a page somewhere
-      else on the site - ``myapp:index`` will resolve to the index page of the
-      default instance.
+* If there is no current instance - say, if we were rendering a page somewhere
+  else on the site - ``myapp:index`` will resolve to the index page of the
+  default instance.
 
-    * ``foo:index`` will again resolve to the index page of the instance ``foo``.
+* ``foo:index`` will again resolve to the index page of the instance ``foo``.
 
 
 ``django.core.urlresolvers`` utility functions
diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt
index 247669d9ea..a8c85ddf6e 100644
--- a/docs/topics/http/views.txt
+++ b/docs/topics/http/views.txt
@@ -29,22 +29,22 @@ Here's a view that returns the current date and time, as an HTML document:
 
 Let's step through this code one line at a time:
 
-    * First, we import the class :class:`~django.http.HttpResponse` from the
-      :mod:`django.http` module, along with Python's ``datetime`` library.
+* First, we import the class :class:`~django.http.HttpResponse` from the
+  :mod:`django.http` module, along with Python's ``datetime`` library.
 
-    * Next, we define a function called ``current_datetime``. This is the view
-      function. Each view function takes an :class:`~django.http.HttpRequest`
-      object as its first parameter, which is typically named ``request``.
+* Next, we define a function called ``current_datetime``. This is the view
+  function. Each view function takes an :class:`~django.http.HttpRequest`
+  object as its first parameter, which is typically named ``request``.
 
-      Note that the name of the view function doesn't matter; it doesn't have to
-      be named in a certain way in order for Django to recognize it. We're
-      calling it ``current_datetime`` here, because that name clearly indicates
-      what it does.
+  Note that the name of the view function doesn't matter; it doesn't have to
+  be named in a certain way in order for Django to recognize it. We're
+  calling it ``current_datetime`` here, because that name clearly indicates
+  what it does.
 
-    * The view returns an :class:`~django.http.HttpResponse` object that
-      contains the generated response. Each view function is responsible for
-      returning an :class:`~django.http.HttpResponse` object. (There are
-      exceptions, but we'll get to those later.)
+* The view returns an :class:`~django.http.HttpResponse` object that
+  contains the generated response. Each view function is responsible for
+  returning an :class:`~django.http.HttpResponse` object. (There are
+  exceptions, but we'll get to those later.)
 
 .. admonition:: Django's Time Zone
 
@@ -152,20 +152,20 @@ Behind the scenes, Django determines the 404 view by looking for
 
 Four things to note about 404 views:
 
-    * The 404 view is also called if Django doesn't find a match after
-      checking every regular expression in the URLconf.
+* The 404 view is also called if Django doesn't find a match after
+  checking every regular expression in the URLconf.
 
-    * If you don't define your own 404 view — and simply use the default,
-      which is recommended — you still have one obligation: you must create a
-      ``404.html`` template in the root of your template directory.
+* If you don't define your own 404 view — and simply use the default,
+  which is recommended — you still have one obligation: you must create a
+  ``404.html`` template in the root of your template directory.
 
-    * The 404 view is passed a :class:`~django.template.RequestContext` and
-      will have access to variables supplied by your
-      :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g., ``MEDIA_URL``).
+* The 404 view is passed a :class:`~django.template.RequestContext` and
+  will have access to variables supplied by your
+  :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g., ``MEDIA_URL``).
 
-    * If :setting:`DEBUG` is set to ``True`` (in your settings module), then
-      your 404 view will never be used, and your URLconf will be displayed
-      instead, with some debug information.
+* If :setting:`DEBUG` is set to ``True`` (in your settings module), then
+  your 404 view will never be used, and your URLconf will be displayed
+  instead, with some debug information.
 
 The 500 (server error) view
 ----------------------------
@@ -192,13 +192,13 @@ Behind the scenes, Django determines the 500 view by looking for
 
 Two things to note about 500 views:
 
-    * If you don't define your own 500 view — and simply use the default,
-      which is recommended — you still have one obligation: you must create a
-      ``500.html`` template in the root of your template directory.
+* If you don't define your own 500 view — and simply use the default,
+  which is recommended — you still have one obligation: you must create a
+  ``500.html`` template in the root of your template directory.
 
-    * If :setting:`DEBUG` is set to ``True`` (in your settings module), then
-      your 500 view will never be used, and the traceback will be displayed
-      instead, with some debug information.
+* If :setting:`DEBUG` is set to ``True`` (in your settings module), then
+  your 500 view will never be used, and the traceback will be displayed
+  instead, with some debug information.
 
 .. _http_forbidden_view: