Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

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
  • Loading branch information...
commit d1e5c55258d624058a93c8cacdb1f25ae7857554 1 parent 5109ac3
Luke Plant authored October 14, 2011

Showing 129 changed files with 5,861 additions and 5,893 deletions. Show diff stats Hide diff stats

  1. 20  docs/faq/admin.txt
  2. 18  docs/faq/contributing.txt
  3. 10  docs/faq/install.txt
  4. 58  docs/faq/usage.txt
  5. 44  docs/howto/apache-auth.txt
  6. 10  docs/howto/custom-file-storage.txt
  7. 120  docs/howto/custom-model-fields.txt
  8. 404  docs/howto/custom-template-tags.txt
  9. 6  docs/howto/deployment/fastcgi.txt
  10. 34  docs/howto/deployment/modpython.txt
  11. 18  docs/howto/deployment/modwsgi.txt
  12. 84  docs/howto/error-reporting.txt
  13. 32  docs/howto/i18n.txt
  14. 12  docs/howto/jython.txt
  15. 12  docs/howto/legacy-databases.txt
  16. 44  docs/howto/outputting-csv.txt
  17. 62  docs/howto/outputting-pdf.txt
  18. 62  docs/howto/static-files.txt
  19. 284  docs/index.txt
  20. 154  docs/internals/contributing/bugs-and-features.txt
  21. 124  docs/internals/contributing/committing-code.txt
  22. 48  docs/internals/contributing/index.txt
  23. 44  docs/internals/contributing/translations.txt
  24. 238  docs/internals/contributing/triaging-tickets.txt
  25. 70  docs/internals/contributing/writing-code/branch-policy.txt
  26. 208  docs/internals/contributing/writing-code/coding-style.txt
  27. 92  docs/internals/contributing/writing-code/submitting-patches.txt
  28. 54  docs/internals/contributing/writing-code/unit-tests.txt
  29. 260  docs/internals/contributing/writing-documentation.txt
  30. 346  docs/internals/deprecation.txt
  31. 104  docs/internals/release-process.txt
  32. 18  docs/intro/install.txt
  33. 12  docs/intro/overview.txt
  34. 128  docs/intro/tutorial01.txt
  35. 76  docs/intro/tutorial02.txt
  36. 60  docs/intro/tutorial03.txt
  37. 174  docs/intro/tutorial04.txt
  38. 158  docs/intro/whatsnext.txt
  39. 168  docs/misc/api-stability.txt
  40. 4  docs/misc/design-philosophies.txt
  41. 260  docs/ref/class-based-views.txt
  42. 8  docs/ref/contrib/admin/actions.txt
  43. 44  docs/ref/contrib/admin/admindocs.txt
  44. 12  docs/ref/contrib/comments/custom.txt
  45. 80  docs/ref/contrib/comments/index.txt
  46. 84  docs/ref/contrib/comments/signals.txt
  47. 40  docs/ref/contrib/comments/upgrade.txt
  48. 76  docs/ref/contrib/contenttypes.txt
  49. 66  docs/ref/contrib/csrf.txt
  50. 52  docs/ref/contrib/databrowse.txt
  51. 40  docs/ref/contrib/flatpages.txt
  52. 84  docs/ref/contrib/formtools/form-preview.txt
  53. 70  docs/ref/contrib/formtools/form-wizard.txt
  54. 72  docs/ref/contrib/humanize.txt
  55. 8  docs/ref/contrib/markup.txt
  56. 28  docs/ref/contrib/messages.txt
  57. 22  docs/ref/contrib/redirects.txt
  58. 80  docs/ref/contrib/sitemaps.txt
  59. 28  docs/ref/contrib/sites.txt
  60. 20  docs/ref/contrib/staticfiles.txt
  61. 164  docs/ref/contrib/syndication.txt
  62. 30  docs/ref/contrib/webdesign.txt
  63. 110  docs/ref/databases.txt
  64. 162  docs/ref/django-admin.txt
  65. 18  docs/ref/exceptions.txt
  66. 54  docs/ref/forms/api.txt
  67. 459  docs/ref/forms/fields.txt
  68. 132  docs/ref/forms/validation.txt
  69. 131  docs/ref/forms/widgets.txt
  70. 988  docs/ref/generic-views.txt
  71. 64  docs/ref/middleware.txt
  72. 66  docs/ref/models/fields.txt
  73. 82  docs/ref/models/instances.txt
  74. 30  docs/ref/models/options.txt
  75. 30  docs/ref/models/relations.txt
  76. 78  docs/ref/request-response.txt
  77. 54  docs/ref/settings.txt
  78. 85  docs/ref/signals.txt
  79. 12  docs/ref/template-response.txt
  80. 216  docs/ref/templates/api.txt
  81. 282  docs/ref/templates/builtins.txt
  82. 96  docs/ref/unicode.txt
  83. 24  docs/ref/utils.txt
  84. 80  docs/releases/0.95.txt
  85. 82  docs/releases/0.96.txt
  86. 30  docs/releases/1.0-porting-guide.txt
  87. 6  docs/releases/1.1-alpha-1.txt
  88. 60  docs/releases/1.1-beta-1.txt
  89. 6  docs/releases/1.1-rc-1.txt
  90. 12  docs/releases/1.1.4.txt
  91. 54  docs/releases/1.1.txt
  92. 94  docs/releases/1.2-alpha-1.txt
  93. 6  docs/releases/1.2-beta-1.txt
  94. 6  docs/releases/1.2-rc-1.txt
  95. 12  docs/releases/1.2.5.txt
  96. 128  docs/releases/1.2.txt
  97. 36  docs/releases/1.3-alpha-1.txt
  98. 42  docs/releases/1.3-beta-1.txt
  99. 72  docs/releases/1.3.txt
  100. 170  docs/topics/cache.txt
  101. 32  docs/topics/class-based-views.txt
  102. 32  docs/topics/conditional-view-processing.txt
  103. 40  docs/topics/db/managers.txt
  104. 296  docs/topics/db/models.txt
  105. 22  docs/topics/db/optimization.txt
  106. 74  docs/topics/db/queries.txt
  107. 36  docs/topics/db/transactions.txt
  108. 166  docs/topics/email.txt
  109. 68  docs/topics/forms/index.txt
  110. 124  docs/topics/forms/modelforms.txt
  111. 36  docs/topics/generic-views-migration.txt
  112. 32  docs/topics/generic-views.txt
  113. 176  docs/topics/http/file-uploads.txt
  114. 26  docs/topics/http/middleware.txt
  115. 80  docs/topics/http/sessions.txt
  116. 50  docs/topics/http/shortcuts.txt
  117. 176  docs/topics/http/urls.txt
  118. 60  docs/topics/http/views.txt
  119. 166  docs/topics/i18n/deployment.txt
  120. 36  docs/topics/i18n/index.txt
  121. 112  docs/topics/i18n/internationalization.txt
  122. 46  docs/topics/i18n/localization.txt
  123. 20  docs/topics/install.txt
  124. 141  docs/topics/logging.txt
  125. 18  docs/topics/serialization.txt
  126. 20  docs/topics/settings.txt
  127. 28  docs/topics/signals.txt
  128. 12  docs/topics/signing.txt
  129. 318  docs/topics/testing.txt
20  docs/faq/admin.txt
@@ -8,16 +8,16 @@ The login cookie isn't being set correctly, because the domain of the cookie
8 8
 sent out by Django doesn't match the domain in your browser. Try these two
9 9
 things:
10 10
 
11  
-    * Set the :setting:`SESSION_COOKIE_DOMAIN` setting in your admin config
12  
-      file to match your domain. For example, if you're going to
13  
-      "http://www.example.com/admin/" in your browser, in
14  
-      "myproject.settings" you should set ``SESSION_COOKIE_DOMAIN = 'www.example.com'``.
15  
-
16  
-    * Some browsers (Firefox?) don't like to accept cookies from domains that
17  
-      don't have dots in them. If you're running the admin site on "localhost"
18  
-      or another domain that doesn't have a dot in it, try going to
19  
-      "localhost.localdomain" or "127.0.0.1". And set
20  
-      :setting:`SESSION_COOKIE_DOMAIN` accordingly.
  11
+* Set the :setting:`SESSION_COOKIE_DOMAIN` setting in your admin config
  12
+  file to match your domain. For example, if you're going to
  13
+  "http://www.example.com/admin/" in your browser, in
  14
+  "myproject.settings" you should set ``SESSION_COOKIE_DOMAIN = 'www.example.com'``.
  15
+
  16
+* Some browsers (Firefox?) don't like to accept cookies from domains that
  17
+  don't have dots in them. If you're running the admin site on "localhost"
  18
+  or another domain that doesn't have a dot in it, try going to
  19
+  "localhost.localdomain" or "127.0.0.1". And set
  20
+  :setting:`SESSION_COOKIE_DOMAIN` accordingly.
21 21
 
22 22
 I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error.
23 23
 -----------------------------------------------------------------------------------------------------------------------------------------------------------
18  docs/faq/contributing.txt
@@ -26,17 +26,17 @@ The best way to make sure tickets do not get hung up on the way to checkin is
26 26
 to make it dead easy, even for someone who may not be intimately familiar with
27 27
 that area of the code, to understand the problem and verify the fix:
28 28
 
29  
-    * Are there clear instructions on how to reproduce the bug? If this
30  
-      touches a dependency (such as PIL), a contrib module, or a specific
31  
-      database, are those instructions clear enough even for someone not
32  
-      familiar with it?
  29
+* Are there clear instructions on how to reproduce the bug? If this
  30
+  touches a dependency (such as PIL), a contrib module, or a specific
  31
+  database, are those instructions clear enough even for someone not
  32
+  familiar with it?
33 33
 
34  
-    * If there are several patches attached to the ticket, is it clear what
35  
-      each one does, which ones can be ignored and which matter?
  34
+* If there are several patches attached to the ticket, is it clear what
  35
+  each one does, which ones can be ignored and which matter?
36 36
 
37  
-    * Does the patch include a unit test? If not, is there a very clear
38  
-      explanation why not? A test expresses succinctly what the problem is,
39  
-      and shows that the patch actually fixes it.
  37
+* Does the patch include a unit test? If not, is there a very clear
  38
+  explanation why not? A test expresses succinctly what the problem is,
  39
+  and shows that the patch actually fixes it.
40 40
 
41 41
 If your patch stands no chance of inclusion in Django, we won't ignore it --
42 42
 we'll just close the ticket. So if your ticket is still open, it doesn't mean
10  docs/faq/install.txt
@@ -4,11 +4,11 @@ FAQ: Installation
4 4
 How do I get started?
5 5
 ---------------------
6 6
 
7  
-    #. `Download the code`_.
8  
-    #. Install Django (read the :doc:`installation guide </intro/install>`).
9  
-    #. Walk through the :doc:`tutorial </intro/tutorial01>`.
10  
-    #. Check out the rest of the :doc:`documentation </index>`, and `ask questions`_ if you
11  
-       run into trouble.
  7
+#. `Download the code`_.
  8
+#. Install Django (read the :doc:`installation guide </intro/install>`).
  9
+#. Walk through the :doc:`tutorial </intro/tutorial01>`.
  10
+#. Check out the rest of the :doc:`documentation </index>`, and `ask questions`_ if you
  11
+   run into trouble.
12 12
 
13 13
 .. _`Download the code`: http://www.djangoproject.com/download/
14 14
 .. _ask questions: http://www.djangoproject.com/community/
58  docs/faq/usage.txt
@@ -6,21 +6,21 @@ Why do I get an error about importing DJANGO_SETTINGS_MODULE?
6 6
 
7 7
 Make sure that:
8 8
 
9  
-    * The environment variable DJANGO_SETTINGS_MODULE is set to a
10  
-      fully-qualified Python module (i.e. "mysite.settings").
  9
+* The environment variable DJANGO_SETTINGS_MODULE is set to a
  10
+  fully-qualified Python module (i.e. "mysite.settings").
11 11
 
12  
-    * Said module is on ``sys.path`` (``import mysite.settings`` should work).
  12
+* Said module is on ``sys.path`` (``import mysite.settings`` should work).
13 13
 
14  
-    * The module doesn't contain syntax errors (of course).
  14
+* The module doesn't contain syntax errors (of course).
15 15
 
16  
-    * If you're using mod_python but *not* using Django's request handler,
17  
-      you'll need to work around a mod_python bug related to the use of
18  
-      ``SetEnv``; before you import anything from Django you'll need to do
19  
-      the following::
  16
+* If you're using mod_python but *not* using Django's request handler,
  17
+  you'll need to work around a mod_python bug related to the use of
  18
+  ``SetEnv``; before you import anything from Django you'll need to do
  19
+  the following::
20 20
 
21  
-            os.environ.update(req.subprocess_env)
  21
+        os.environ.update(req.subprocess_env)
22 22
 
23  
-      (where ``req`` is the mod_python request object).
  23
+  (where ``req`` is the mod_python request object).
24 24
 
25 25
 I can't stand your template language. Do I have to use it?
26 26
 ----------------------------------------------------------
@@ -46,25 +46,25 @@ How do I use image and file fields?
46 46
 Using a :class:`~django.db.models.FileField` or an
47 47
 :class:`~django.db.models.ImageField` in a model takes a few steps:
48 48
 
49  
-    #. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as
50  
-       the full path to a directory where you'd like Django to store uploaded
51  
-       files. (For performance, these files are not stored in the database.)
52  
-       Define :setting:`MEDIA_URL` as the base public URL of that directory.
53  
-       Make sure that this directory is writable by the Web server's user
54  
-       account.
55  
-
56  
-    #. Add the :class:`~django.db.models.FileField` or
57  
-       :class:`~django.db.models.ImageField` to your model, making sure to
58  
-       define the :attr:`~django.db.models.FileField.upload_to` option to tell
59  
-       Django to which subdirectory of :setting:`MEDIA_ROOT` it should upload
60  
-       files.
61  
-
62  
-    #. All that will be stored in your database is a path to the file
63  
-       (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
64  
-       convenience :attr:`~django.core.files.File.url` attribute provided by
65  
-       Django. For example, if your :class:`~django.db.models.ImageField` is
66  
-       called ``mug_shot``, you can get the absolute path to your image in a
67  
-       template with ``{{ object.mug_shot.url }}``.
  49
+#. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as
  50
+   the full path to a directory where you'd like Django to store uploaded
  51
+   files. (For performance, these files are not stored in the database.)
  52
+   Define :setting:`MEDIA_URL` as the base public URL of that directory.
  53
+   Make sure that this directory is writable by the Web server's user
  54
+   account.
  55
+
  56
+#. Add the :class:`~django.db.models.FileField` or
  57
+   :class:`~django.db.models.ImageField` to your model, making sure to
  58
+   define the :attr:`~django.db.models.FileField.upload_to` option to tell
  59
+   Django to which subdirectory of :setting:`MEDIA_ROOT` it should upload
  60
+   files.
  61
+
  62
+#. All that will be stored in your database is a path to the file
  63
+   (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
  64
+   convenience :attr:`~django.core.files.File.url` attribute provided by
  65
+   Django. For example, if your :class:`~django.db.models.ImageField` is
  66
+   called ``mug_shot``, you can get the absolute path to your image in a
  67
+   template with ``{{ object.mug_shot.url }}``.
68 68
 
69 69
 How do I make a variable available to all my templates?
70 70
 -------------------------------------------------------
44  docs/howto/apache-auth.txt
@@ -14,12 +14,12 @@ dealing with Apache, you can configuring Apache to authenticate against Django's
14 14
 :doc:`authentication system </topics/auth>` directly. For example, you
15 15
 could:
16 16
 
17  
-    * Serve static/media files directly from Apache only to authenticated users.
  17
+* Serve static/media files directly from Apache only to authenticated users.
18 18
 
19  
-    * Authenticate access to a Subversion_ repository against Django users with
20  
-      a certain permission.
  19
+* Authenticate access to a Subversion_ repository against Django users with
  20
+  a certain permission.
21 21
 
22  
-    * Allow certain users to connect to a WebDAV share created with mod_dav_.
  22
+* Allow certain users to connect to a WebDAV share created with mod_dav_.
23 23
 
24 24
 .. _Subversion: http://subversion.tigris.org/
25 25
 .. _mod_dav: http://httpd.apache.org/docs/2.0/mod/mod_dav.html
@@ -93,29 +93,29 @@ By default, the authentication handler will limit access to the ``/example/``
93 93
 location to users marked as staff members.  You can use a set of
94 94
 ``PythonOption`` directives to modify this behavior:
95 95
 
96  
-    ================================  =========================================
97  
-    ``PythonOption``                  Explanation
98  
-    ================================  =========================================
99  
-    ``DjangoRequireStaffStatus``      If set to ``on`` only "staff" users (i.e.
100  
-                                      those with the ``is_staff`` flag set)
101  
-                                      will be allowed.
  96
+================================  =========================================
  97
+``PythonOption``                  Explanation
  98
+================================  =========================================
  99
+``DjangoRequireStaffStatus``      If set to ``on`` only "staff" users (i.e.
  100
+                                  those with the ``is_staff`` flag set)
  101
+                                  will be allowed.
102 102
 
103  
-                                      Defaults to ``on``.
  103
+                                  Defaults to ``on``.
104 104
 
105  
-    ``DjangoRequireSuperuserStatus``  If set to ``on`` only superusers (i.e.
106  
-                                      those with the ``is_superuser`` flag set)
107  
-                                      will be allowed.
  105
+``DjangoRequireSuperuserStatus``  If set to ``on`` only superusers (i.e.
  106
+                                  those with the ``is_superuser`` flag set)
  107
+                                  will be allowed.
108 108
 
109  
-                                      Defaults to ``off``.
  109
+                                  Defaults to ``off``.
110 110
 
111  
-    ``DjangoPermissionName``          The name of a permission to require for
112  
-                                      access. See :ref:`custom permissions
113  
-                                      <custom-permissions>` for more
114  
-                                      information.
  111
+``DjangoPermissionName``          The name of a permission to require for
  112
+                                  access. See :ref:`custom permissions
  113
+                                  <custom-permissions>` for more
  114
+                                  information.
115 115
 
116  
-                                      By default no specific permission will be
117  
-                                      required.
118  
-    ================================  =========================================
  116
+                                  By default no specific permission will be
  117
+                                  required.
  118
+================================  =========================================
119 119
 
120 120
 Note that sometimes ``SetEnv`` doesn't play well in this mod_python
121 121
 configuration, for reasons unknown. If you're having problems getting
10  docs/howto/custom-file-storage.txt
@@ -37,11 +37,11 @@ You'll need to follow these steps:
37 37
 Your custom storage system may override any of the storage methods explained in
38 38
 :doc:`/ref/files/storage`, but you **must** implement the following methods:
39 39
 
40  
-    * :meth:`Storage.delete`
41  
-    * :meth:`Storage.exists`
42  
-    * :meth:`Storage.listdir`
43  
-    * :meth:`Storage.size`
44  
-    * :meth:`Storage.url`
  40
+* :meth:`Storage.delete`
  41
+* :meth:`Storage.exists`
  42
+* :meth:`Storage.listdir`
  43
+* :meth:`Storage.size`
  44
+* :meth:`Storage.url`
45 45
 
46 46
 You'll also usually want to use hooks specifically designed for custom storage
47 47
 objects. These are:
120  docs/howto/custom-model-fields.txt
@@ -133,14 +133,14 @@ example). If this sounds a bit tricky, don't worry -- it will become clearer in
133 133
 the examples below. Just remember that you will often end up creating two
134 134
 classes when you want a custom field:
135 135
 
136  
-    * The first class is the Python object that your users will manipulate.
137  
-      They will assign it to the model attribute, they will read from it for
138  
-      displaying purposes, things like that. This is the ``Hand`` class in our
139  
-      example.
  136
+* The first class is the Python object that your users will manipulate.
  137
+  They will assign it to the model attribute, they will read from it for
  138
+  displaying purposes, things like that. This is the ``Hand`` class in our
  139
+  example.
140 140
 
141  
-    * The second class is the ``Field`` subclass. This is the class that knows
142  
-      how to convert your first class back and forth between its permanent
143  
-      storage form and the Python form.
  141
+* The second class is the ``Field`` subclass. This is the class that knows
  142
+  how to convert your first class back and forth between its permanent
  143
+  storage form and the Python form.
144 144
 
145 145
 Writing a field subclass
146 146
 ========================
@@ -198,33 +198,33 @@ card values plus their suits; 104 characters in total.
198 198
 The :meth:`~django.db.models.Field.__init__` method takes the following
199 199
 parameters:
200 200
 
201  
-    * :attr:`~django.db.models.Field.verbose_name`
202  
-    * :attr:`~django.db.models.Field.name`
203  
-    * :attr:`~django.db.models.Field.primary_key`
204  
-    * :attr:`~django.db.models.Field.max_length`
205  
-    * :attr:`~django.db.models.Field.unique`
206  
-    * :attr:`~django.db.models.Field.blank`
207  
-    * :attr:`~django.db.models.Field.null`
208  
-    * :attr:`~django.db.models.Field.db_index`
209  
-    * :attr:`~django.db.models.Field.rel`: Used for related fields (like
210  
-      :class:`ForeignKey`). For advanced use only.
211  
-    * :attr:`~django.db.models.Field.default`
212  
-    * :attr:`~django.db.models.Field.editable`
213  
-    * :attr:`~django.db.models.Field.serialize`: If ``False``, the field will
214  
-      not be serialized when the model is passed to Django's :doc:`serializers
215  
-      </topics/serialization>`. Defaults to ``True``.
216  
-    * :attr:`~django.db.models.Field.unique_for_date`
217  
-    * :attr:`~django.db.models.Field.unique_for_month`
218  
-    * :attr:`~django.db.models.Field.unique_for_year`
219  
-    * :attr:`~django.db.models.Field.choices`
220  
-    * :attr:`~django.db.models.Field.help_text`
221  
-    * :attr:`~django.db.models.Field.db_column`
222  
-    * :attr:`~django.db.models.Field.db_tablespace`: Currently only used with
223  
-      the Oracle backend and only for index creation. You can usually ignore
224  
-      this option.
225  
-    * :attr:`~django.db.models.Field.auto_created`: True if the field was
226  
-      automatically created, as for the `OneToOneField` used by model
227  
-      inheritance. For advanced use only.
  201
+* :attr:`~django.db.models.Field.verbose_name`
  202
+* :attr:`~django.db.models.Field.name`
  203
+* :attr:`~django.db.models.Field.primary_key`
  204
+* :attr:`~django.db.models.Field.max_length`
  205
+* :attr:`~django.db.models.Field.unique`
  206
+* :attr:`~django.db.models.Field.blank`
  207
+* :attr:`~django.db.models.Field.null`
  208
+* :attr:`~django.db.models.Field.db_index`
  209
+* :attr:`~django.db.models.Field.rel`: Used for related fields (like
  210
+  :class:`ForeignKey`). For advanced use only.
  211
+* :attr:`~django.db.models.Field.default`
  212
+* :attr:`~django.db.models.Field.editable`
  213
+* :attr:`~django.db.models.Field.serialize`: If ``False``, the field will
  214
+  not be serialized when the model is passed to Django's :doc:`serializers
  215
+  </topics/serialization>`. Defaults to ``True``.
  216
+* :attr:`~django.db.models.Field.unique_for_date`
  217
+* :attr:`~django.db.models.Field.unique_for_month`
  218
+* :attr:`~django.db.models.Field.unique_for_year`
  219
+* :attr:`~django.db.models.Field.choices`
  220
+* :attr:`~django.db.models.Field.help_text`
  221
+* :attr:`~django.db.models.Field.db_column`
  222
+* :attr:`~django.db.models.Field.db_tablespace`: Currently only used with
  223
+  the Oracle backend and only for index creation. You can usually ignore
  224
+  this option.
  225
+* :attr:`~django.db.models.Field.auto_created`: True if the field was
  226
+  automatically created, as for the `OneToOneField` used by model
  227
+  inheritance. For advanced use only.
228 228
 
229 229
 All of the options without an explanation in the above list have the same
230 230
 meaning they do for normal Django fields. See the :doc:`field documentation
@@ -415,11 +415,11 @@ that are more complex than strings, dates, integers or floats, then you'll need
415 415
 to override this method. As a general rule, the method should deal gracefully
416 416
 with any of the following arguments:
417 417
 
418  
-    * An instance of the correct type (e.g., ``Hand`` in our ongoing example).
  418
+* An instance of the correct type (e.g., ``Hand`` in our ongoing example).
419 419
 
420  
-    * A string (e.g., from a deserializer).
  420
+* A string (e.g., from a deserializer).
421 421
 
422  
-    * Whatever the database returns for the column type you're using.
  422
+* Whatever the database returns for the column type you're using.
423 423
 
424 424
 In our ``HandField`` class, we're storing the data as a VARCHAR field in the
425 425
 database, so we need to be able to process strings and ``Hand`` instances in
@@ -695,19 +695,19 @@ complex conversions between your Python types and your database and
695 695
 serialization formats. Here are a couple of tips to make things go more
696 696
 smoothly:
697 697
 
698  
-    1. Look at the existing Django fields (in
699  
-       :file:`django/db/models/fields/__init__.py`) for inspiration. Try to find
700  
-       a field that's similar to what you want and extend it a little bit,
701  
-       instead of creating an entirely new field from scratch.
  698
+1. Look at the existing Django fields (in
  699
+   :file:`django/db/models/fields/__init__.py`) for inspiration. Try to find
  700
+   a field that's similar to what you want and extend it a little bit,
  701
+   instead of creating an entirely new field from scratch.
702 702
 
703  
-    2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're
704  
-       wrapping up as a field. There are a lot of places where the default
705  
-       behavior of the field code is to call
706  
-       :func:`~django.utils.encoding.force_unicode` on the value. (In our
707  
-       examples in this document, ``value`` would be a ``Hand`` instance, not a
708  
-       ``HandField``). So if your :meth:`__unicode__` method automatically
709  
-       converts to the string form of your Python object, you can save yourself
710  
-       a lot of work.
  703
+2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're
  704
+   wrapping up as a field. There are a lot of places where the default
  705
+   behavior of the field code is to call
  706
+   :func:`~django.utils.encoding.force_unicode` on the value. (In our
  707
+   examples in this document, ``value`` would be a ``Hand`` instance, not a
  708
+   ``HandField``). So if your :meth:`__unicode__` method automatically
  709
+   converts to the string form of your Python object, you can save yourself
  710
+   a lot of work.
711 711
 
712 712
 
713 713
 Writing a ``FileField`` subclass
@@ -735,14 +735,14 @@ A few suggestions
735 735
 In addition to the above details, there are a few guidelines which can greatly
736 736
 improve the efficiency and readability of the field's code.
737 737
 
738  
-    1. The source for Django's own ``ImageField`` (in
739  
-       ``django/db/models/fields/files.py``) is a great example of how to
740  
-       subclass ``FileField`` to support a particular type of file, as it
741  
-       incorporates all of the techniques described above.
742  
-
743  
-    2. Cache file attributes wherever possible. Since files may be stored in
744  
-       remote storage systems, retrieving them may cost extra time, or even
745  
-       money, that isn't always necessary. Once a file is retrieved to obtain
746  
-       some data about its content, cache as much of that data as possible to
747  
-       reduce the number of times the file must be retrieved on subsequent
748  
-       calls for that information.
  738
+1. The source for Django's own ``ImageField`` (in
  739
+   ``django/db/models/fields/files.py``) is a great example of how to
  740
+   subclass ``FileField`` to support a particular type of file, as it
  741
+   incorporates all of the techniques described above.
  742
+
  743
+2. Cache file attributes wherever possible. Since files may be stored in
  744
+   remote storage systems, retrieving them may cost extra time, or even
  745
+   money, that isn't always necessary. Once a file is retrieved to obtain
  746
+   some data about its content, cache as much of that data as possible to
  747
+   reduce the number of times the file must be retrieved on subsequent
  748
+   calls for that information.
404  docs/howto/custom-template-tags.txt
@@ -77,9 +77,9 @@ Writing custom template filters
77 77
 
78 78
 Custom filters are just Python functions that take one or two arguments:
79 79
 
80  
-    * The value of the variable (input) -- not necessarily a string.
81  
-    * The value of the argument -- this can have a default value, or be left
82  
-      out altogether.
  80
+* The value of the variable (input) -- not necessarily a string.
  81
+* The value of the argument -- this can have a default value, or be left
  82
+  out altogether.
83 83
 
84 84
 For example, in the filter ``{{ var|foo:"bar" }}``, the filter ``foo`` would be
85 85
 passed the variable ``var`` and the argument ``"bar"``.
@@ -124,9 +124,9 @@ your ``Library`` instance, to make it available to Django's template language:
124 124
 
125 125
 The ``Library.filter()`` method takes two arguments:
126 126
 
127  
-    1. The name of the filter -- a string.
128  
-    2. The compilation function -- a Python function (not the name of the
129  
-       function as a string).
  127
+1. The name of the filter -- a string.
  128
+2. The compilation function -- a Python function (not the name of the
  129
+   function as a string).
130 130
 
131 131
 You can use ``register.filter()`` as a decorator instead:
132 132
 
@@ -173,156 +173,156 @@ When writing a custom filter, give some thought to how the filter will interact
173 173
 with Django's auto-escaping behavior. Note that three types of strings can be
174 174
 passed around inside the template code:
175 175
 
176  
-    * **Raw strings** are the native Python ``str`` or ``unicode`` types. On
177  
-      output, they're escaped if auto-escaping is in effect and presented
178  
-      unchanged, otherwise.
  176
+* **Raw strings** are the native Python ``str`` or ``unicode`` types. On
  177
+  output, they're escaped if auto-escaping is in effect and presented
  178
+  unchanged, otherwise.
179 179
 
180  
-    * **Safe strings** are strings that have been marked safe from further
181  
-      escaping at output time. Any necessary escaping has already been done.
182  
-      They're commonly used for output that contains raw HTML that is intended
183  
-      to be interpreted as-is on the client side.
  180
+* **Safe strings** are strings that have been marked safe from further
  181
+  escaping at output time. Any necessary escaping has already been done.
  182
+  They're commonly used for output that contains raw HTML that is intended
  183
+  to be interpreted as-is on the client side.
184 184
 
185  
-      Internally, these strings are of type ``SafeString`` or ``SafeUnicode``.
186  
-      They share a common base class of ``SafeData``, so you can test
187  
-      for them using code like:
  185
+  Internally, these strings are of type ``SafeString`` or ``SafeUnicode``.
  186
+  They share a common base class of ``SafeData``, so you can test
  187
+  for them using code like:
188 188
 
189  
-      .. code-block:: python
  189
+  .. code-block:: python
190 190
 
191  
-          if isinstance(value, SafeData):
192  
-              # Do something with the "safe" string.
193  
-              ...
  191
+      if isinstance(value, SafeData):
  192
+          # Do something with the "safe" string.
  193
+          ...
194 194
 
195  
-    * **Strings marked as "needing escaping"** are *always* escaped on
196  
-      output, regardless of whether they are in an :ttag:`autoescape` block or
197  
-      not. These strings are only escaped once, however, even if auto-escaping
198  
-      applies.
  195
+* **Strings marked as "needing escaping"** are *always* escaped on
  196
+  output, regardless of whether they are in an :ttag:`autoescape` block or
  197
+  not. These strings are only escaped once, however, even if auto-escaping
  198
+  applies.
199 199
 
200  
-      Internally, these strings are of type ``EscapeString`` or
201  
-      ``EscapeUnicode``. Generally you don't have to worry about these; they
202  
-      exist for the implementation of the :tfilter:`escape` filter.
  200
+  Internally, these strings are of type ``EscapeString`` or
  201
+  ``EscapeUnicode``. Generally you don't have to worry about these; they
  202
+  exist for the implementation of the :tfilter:`escape` filter.
203 203
 
204 204
 Template filter code falls into one of two situations:
205 205
 
206  
-    1. Your filter does not introduce any HTML-unsafe characters (``<``, ``>``,
207  
-       ``'``, ``"`` or ``&``) into the result that were not already present. In
208  
-       this case, you can let Django take care of all the auto-escaping
209  
-       handling for you. All you need to do is put the ``is_safe`` attribute on
210  
-       your filter function and set it to ``True``, like so:
211  
-
212  
-       .. code-block:: python
213  
-
214  
-           @register.filter
215  
-           def myfilter(value):
216  
-               return value
217  
-           myfilter.is_safe = True
218  
-
219  
-       This attribute tells Django that if a "safe" string is passed into your
220  
-       filter, the result will still be "safe" and if a non-safe string is
221  
-       passed in, Django will automatically escape it, if necessary.
222  
-
223  
-       You can think of this as meaning "this filter is safe -- it doesn't
224  
-       introduce any possibility of unsafe HTML."
225  
-
226  
-       The reason ``is_safe`` is necessary is because there are plenty of
227  
-       normal string operations that will turn a ``SafeData`` object back into
228  
-       a normal ``str`` or ``unicode`` object and, rather than try to catch
229  
-       them all, which would be very difficult, Django repairs the damage after
230  
-       the filter has completed.
231  
-
232  
-       For example, suppose you have a filter that adds the string ``xx`` to
233  
-       the end of any input. Since this introduces no dangerous HTML characters
234  
-       to the result (aside from any that were already present), you should
235  
-       mark your filter with ``is_safe``:
236  
-
237  
-       .. code-block:: python
238  
-
239  
-           @register.filter
240  
-           def add_xx(value):
241  
-               return '%sxx' % value
242  
-           add_xx.is_safe = True
243  
-
244  
-       When this filter is used in a template where auto-escaping is enabled,
245  
-       Django will escape the output whenever the input is not already marked
246  
-       as "safe".
247  
-
248  
-       By default, ``is_safe`` defaults to ``False``, and you can omit it from
249  
-       any filters where it isn't required.
250  
-
251  
-       Be careful when deciding if your filter really does leave safe strings
252  
-       as safe. If you're *removing* characters, you might inadvertently leave
253  
-       unbalanced HTML tags or entities in the result. For example, removing a
254  
-       ``>`` from the input might turn ``<a>`` into ``<a``, which would need to
255  
-       be escaped on output to avoid causing problems. Similarly, removing a
256  
-       semicolon (``;``) can turn ``&amp;`` into ``&amp``, which is no longer a
257  
-       valid entity and thus needs further escaping. Most cases won't be nearly
258  
-       this tricky, but keep an eye out for any problems like that when
259  
-       reviewing your code.
260  
-
261  
-       Marking a filter ``is_safe`` will coerce the filter's return value to
262  
-       a string.  If your filter should return a boolean or other non-string
263  
-       value, marking it ``is_safe`` will probably have unintended
264  
-       consequences (such as converting a boolean False to the string
265  
-       'False').
266  
-
267  
-    2. Alternatively, your filter code can manually take care of any necessary
268  
-       escaping. This is necessary when you're introducing new HTML markup into
269  
-       the result. You want to mark the output as safe from further
270  
-       escaping so that your HTML markup isn't escaped further, so you'll need
271  
-       to handle the input yourself.
272  
-
273  
-       To mark the output as a safe string, use
274  
-       :func:`django.utils.safestring.mark_safe`.
275  
-
276  
-       Be careful, though. You need to do more than just mark the output as
277  
-       safe. You need to ensure it really *is* safe, and what you do depends on
278  
-       whether auto-escaping is in effect. The idea is to write filters than
279  
-       can operate in templates where auto-escaping is either on or off in
280  
-       order to make things easier for your template authors.
281  
-
282  
-       In order for your filter to know the current auto-escaping state, set
283  
-       the ``needs_autoescape`` attribute to ``True`` on your function. (If you
284  
-       don't specify this attribute, it defaults to ``False``). This attribute
285  
-       tells Django that your filter function wants to be passed an extra
286  
-       keyword argument, called ``autoescape``, that is ``True`` if
287  
-       auto-escaping is in effect and ``False`` otherwise.
288  
-
289  
-       For example, let's write a filter that emphasizes the first character of
290  
-       a string:
291  
-
292  
-       .. code-block:: python
293  
-
294  
-           from django.utils.html import conditional_escape
295  
-           from django.utils.safestring import mark_safe
296  
-
297  
-           def initial_letter_filter(text, autoescape=None):
298  
-               first, other = text[0], text[1:]
299  
-               if autoescape:
300  
-                   esc = conditional_escape
301  
-               else:
302  
-                   esc = lambda x: x
303  
-               result = '<strong>%s</strong>%s' % (esc(first), esc(other))
304  
-               return mark_safe(result)
305  
-           initial_letter_filter.needs_autoescape = True
306  
-
307  
-       The ``needs_autoescape`` attribute on the filter function and the
308  
-       ``autoescape`` keyword argument mean that our function will know whether
309  
-       automatic escaping is in effect when the filter is called. We use
310  
-       ``autoescape`` to decide whether the input data needs to be passed
311  
-       through ``django.utils.html.conditional_escape`` or not. (In the latter
312  
-       case, we just use the identity function as the "escape" function.) The
313  
-       ``conditional_escape()`` function is like ``escape()`` except it only
314  
-       escapes input that is **not** a ``SafeData`` instance. If a ``SafeData``
315  
-       instance is passed to ``conditional_escape()``, the data is returned
316  
-       unchanged.
317  
-
318  
-       Finally, in the above example, we remember to mark the result as safe
319  
-       so that our HTML is inserted directly into the template without further
320  
-       escaping.
321  
-
322  
-       There's no need to worry about the ``is_safe`` attribute in this case
323  
-       (although including it wouldn't hurt anything). Whenever you manually
324  
-       handle the auto-escaping issues and return a safe string, the
325  
-       ``is_safe`` attribute won't change anything either way.
  206
+1. Your filter does not introduce any HTML-unsafe characters (``<``, ``>``,
  207
+   ``'``, ``"`` or ``&``) into the result that were not already present. In
  208
+   this case, you can let Django take care of all the auto-escaping
  209
+   handling for you. All you need to do is put the ``is_safe`` attribute on
  210
+   your filter function and set it to ``True``, like so:
  211
+
  212
+   .. code-block:: python
  213
+
  214
+       @register.filter
  215
+       def myfilter(value):
  216
+           return value
  217
+       myfilter.is_safe = True
  218
+
  219
+   This attribute tells Django that if a "safe" string is passed into your
  220
+   filter, the result will still be "safe" and if a non-safe string is
  221
+   passed in, Django will automatically escape it, if necessary.
  222
+
  223
+   You can think of this as meaning "this filter is safe -- it doesn't
  224
+   introduce any possibility of unsafe HTML."
  225
+
  226
+   The reason ``is_safe`` is necessary is because there are plenty of
  227
+   normal string operations that will turn a ``SafeData`` object back into
  228
+   a normal ``str`` or ``unicode`` object and, rather than try to catch
  229
+   them all, which would be very difficult, Django repairs the damage after
  230
+   the filter has completed.
  231
+
  232
+   For example, suppose you have a filter that adds the string ``xx`` to
  233
+   the end of any input. Since this introduces no dangerous HTML characters
  234
+   to the result (aside from any that were already present), you should
  235
+   mark your filter with ``is_safe``:
  236
+
  237
+   .. code-block:: python
  238
+
  239
+       @register.filter
  240
+       def add_xx(value):
  241
+           return '%sxx' % value
  242
+       add_xx.is_safe = True
  243
+
  244
+   When this filter is used in a template where auto-escaping is enabled,
  245
+   Django will escape the output whenever the input is not already marked
  246
+   as "safe".
  247
+
  248
+   By default, ``is_safe`` defaults to ``False``, and you can omit it from
  249
+   any filters where it isn't required.
  250
+
  251
+   Be careful when deciding if your filter really does leave safe strings
  252
+   as safe. If you're *removing* characters, you might inadvertently leave
  253
+   unbalanced HTML tags or entities in the result. For example, removing a
  254
+   ``>`` from the input might turn ``<a>`` into ``<a``, which would need to
  255
+   be escaped on output to avoid causing problems. Similarly, removing a
  256
+   semicolon (``;``) can turn ``&amp;`` into ``&amp``, which is no longer a
  257
+   valid entity and thus needs further escaping. Most cases won't be nearly
  258
+   this tricky, but keep an eye out for any problems like that when
  259
+   reviewing your code.
  260
+
  261
+   Marking a filter ``is_safe`` will coerce the filter's return value to
  262
+   a string.  If your filter should return a boolean or other non-string
  263
+   value, marking it ``is_safe`` will probably have unintended
  264
+   consequences (such as converting a boolean False to the string
  265
+   'False').
  266
+
  267
+2. Alternatively, your filter code can manually take care of any necessary
  268
+   escaping. This is necessary when you're introducing new HTML markup into
  269
+   the result. You want to mark the output as safe from further
  270
+   escaping so that your HTML markup isn't escaped further, so you'll need
  271
+   to handle the input yourself.
  272
+
  273
+   To mark the output as a safe string, use
  274
+   :func:`django.utils.safestring.mark_safe`.
  275
+
  276
+   Be careful, though. You need to do more than just mark the output as
  277
+   safe. You need to ensure it really *is* safe, and what you do depends on
  278
+   whether auto-escaping is in effect. The idea is to write filters than
  279
+   can operate in templates where auto-escaping is either on or off in
  280
+   order to make things easier for your template authors.
  281
+
  282
+   In order for your filter to know the current auto-escaping state, set
  283
+   the ``needs_autoescape`` attribute to ``True`` on your function. (If you
  284
+   don't specify this attribute, it defaults to ``False``). This attribute
  285
+   tells Django that your filter function wants to be passed an extra
  286
+   keyword argument, called ``autoescape``, that is ``True`` if
  287
+   auto-escaping is in effect and ``False`` otherwise.
  288
+
  289
+   For example, let's write a filter that emphasizes the first character of
  290
+   a string:
  291
+
  292
+   .. code-block:: python
  293
+
  294
+       from django.utils.html import conditional_escape
  295
+       from django.utils.safestring import mark_safe
  296
+
  297
+       def initial_letter_filter(text, autoescape=None):
  298
+           first, other = text[0], text[1:]
  299
+           if autoescape:
  300
+               esc = conditional_escape
  301
+           else:
  302
+               esc = lambda x: x
  303
+           result = '<strong>%s</strong>%s' % (esc(first), esc(other))
  304
+           return mark_safe(result)
  305
+       initial_letter_filter.needs_autoescape = True
  306
+
  307
+   The ``needs_autoescape`` attribute on the filter function and the
  308
+   ``autoescape`` keyword argument mean that our function will know whether
  309
+   automatic escaping is in effect when the filter is called. We use
  310
+   ``autoescape`` to decide whether the input data needs to be passed
  311
+   through ``django.utils.html.conditional_escape`` or not. (In the latter
  312
+   case, we just use the identity function as the "escape" function.) The
  313
+   ``conditional_escape()`` function is like ``escape()`` except it only
  314
+   escapes input that is **not** a ``SafeData`` instance. If a ``SafeData``
  315
+   instance is passed to ``conditional_escape()``, the data is returned
  316
+   unchanged.
  317
+
  318
+   Finally, in the above example, we remember to mark the result as safe
  319
+   so that our HTML is inserted directly into the template without further
  320
+   escaping.
  321
+
  322
+   There's no need to worry about the ``is_safe`` attribute in this case
  323
+   (although including it wouldn't hurt anything). Whenever you manually
  324
+   handle the auto-escaping issues and return a safe string, the
  325
+   ``is_safe`` attribute won't change anything either way.
326 326
 
327 327
 Writing custom template tags
328 328
 ----------------------------
@@ -381,37 +381,37 @@ object:
381 381
 
382 382
 Notes:
383 383
 
384  
-    * ``parser`` is the template parser object. We don't need it in this
385  
-      example.
  384
+* ``parser`` is the template parser object. We don't need it in this
  385
+  example.
386 386
 
387  
-    * ``token.contents`` is a string of the raw contents of the tag. In our
388  
-      example, it's ``'current_time "%Y-%m-%d %I:%M %p"'``.
  387
+* ``token.contents`` is a string of the raw contents of the tag. In our
  388
+  example, it's ``'current_time "%Y-%m-%d %I:%M %p"'``.
389 389
 
390  
-    * The ``token.split_contents()`` method separates the arguments on spaces
391  
-      while keeping quoted strings together. The more straightforward
392  
-      ``token.contents.split()`` wouldn't be as robust, as it would naively
393  
-      split on *all* spaces, including those within quoted strings. It's a good
394  
-      idea to always use ``token.split_contents()``.
  390
+* The ``token.split_contents()`` method separates the arguments on spaces
  391
+  while keeping quoted strings together. The more straightforward
  392
+  ``token.contents.split()`` wouldn't be as robust, as it would naively
  393
+  split on *all* spaces, including those within quoted strings. It's a good
  394
+  idea to always use ``token.split_contents()``.
395 395
 
396  
-    * This function is responsible for raising
397  
-      ``django.template.TemplateSyntaxError``, with helpful messages, for
398  
-      any syntax error.
  396
+* This function is responsible for raising
  397
+  ``django.template.TemplateSyntaxError``, with helpful messages, for
  398
+  any syntax error.
399 399
 
400  
-    * The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
401  
-      Don't hard-code the tag's name in your error messages, because that
402  
-      couples the tag's name to your function. ``token.contents.split()[0]``
403  
-      will ''always'' be the name of your tag -- even when the tag has no
404  
-      arguments.
  400
+* The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
  401
+  Don't hard-code the tag's name in your error messages, because that
  402
+  couples the tag's name to your function. ``token.contents.split()[0]``
  403
+  will ''always'' be the name of your tag -- even when the tag has no
  404
+  arguments.
405 405
 
406  
-    * The function returns a ``CurrentTimeNode`` with everything the node needs
407  
-      to know about this tag. In this case, it just passes the argument --
408  
-      ``"%Y-%m-%d %I:%M %p"``. The leading and trailing quotes from the
409  
-      template tag are removed in ``format_string[1:-1]``.
  406
+* The function returns a ``CurrentTimeNode`` with everything the node needs
  407
+  to know about this tag. In this case, it just passes the argument --
  408
+  ``"%Y-%m-%d %I:%M %p"``. The leading and trailing quotes from the
  409
+  template tag are removed in ``format_string[1:-1]``.
410 410
 
411  
-    * The parsing is very low-level. The Django developers have experimented
412  
-      with writing small frameworks on top of this parsing system, using
413  
-      techniques such as EBNF grammars, but those experiments made the template
414  
-      engine too slow. It's low-level because that's fastest.
  411
+* The parsing is very low-level. The Django developers have experimented
  412
+  with writing small frameworks on top of this parsing system, using
  413
+  techniques such as EBNF grammars, but those experiments made the template
  414
+  engine too slow. It's low-level because that's fastest.
415 415
 
416 416
 Writing the renderer
417 417
 ~~~~~~~~~~~~~~~~~~~~
@@ -433,14 +433,14 @@ Continuing the above example, we need to define ``CurrentTimeNode``:
433 433
 
434 434
 Notes:
435 435
 
436  
-    * ``__init__()`` gets the ``format_string`` from ``do_current_time()``.
437  
-      Always pass any options/parameters/arguments to a ``Node`` via its
438  
-      ``__init__()``.
  436
+* ``__init__()`` gets the ``format_string`` from ``do_current_time()``.
  437
+  Always pass any options/parameters/arguments to a ``Node`` via its
  438
+  ``__init__()``.
439 439
 
440  
-    * The ``render()`` method is where the work actually happens.
  440
+* The ``render()`` method is where the work actually happens.
441 441
 
442  
-    * ``render()`` should never raise ``TemplateSyntaxError`` or any other
443  
-      exception. It should fail silently, just as template filters should.
  442
+* ``render()`` should never raise ``TemplateSyntaxError`` or any other
  443
+  exception. It should fail silently, just as template filters should.
444 444
 
445 445
 Ultimately, this decoupling of compilation and rendering results in an
446 446
 efficient template system, because a template can render multiple contexts
@@ -525,14 +525,14 @@ A naive implementation of ``CycleNode`` might look something like this:
525 525
 But, suppose we have two templates rendering the template snippet from above at
526 526
 the same time:
527 527
 
528  
-    1. Thread 1 performs its first loop iteration, ``CycleNode.render()``
529  
-       returns 'row1'
530  
-    2. Thread 2 performs its first loop iteration, ``CycleNode.render()``
531  
-       returns 'row2'
532  
-    3. Thread 1 performs its second loop iteration, ``CycleNode.render()``
533  
-       returns 'row1'
534  
-    4. Thread 2 performs its second loop iteration, ``CycleNode.render()``
535  
-       returns 'row2'
  528
+1. Thread 1 performs its first loop iteration, ``CycleNode.render()``
  529
+   returns 'row1'
  530
+2. Thread 2 performs its first loop iteration, ``CycleNode.render()``
  531
+   returns 'row2'
  532
+3. Thread 1 performs its second loop iteration, ``CycleNode.render()``
  533
+   returns 'row1'
  534
+4. Thread 2 performs its second loop iteration, ``CycleNode.render()``
  535
+   returns 'row2'
536 536
 
537 537
 The CycleNode is iterating, but it's iterating globally. As far as Thread 1
538 538
 and Thread 2 are concerned, it's always returning the same value. This is
@@ -584,10 +584,10 @@ in "Writing custom template filters" above. Example:
584 584
 
585 585
 The ``tag()`` method takes two arguments:
586 586
 
587  
-    1. The name of the template tag -- a string. If this is left out, the
588  
-       name of the compilation function will be used.
589  
-    2. The compilation function -- a Python function (not the name of the
590  
-       function as a string).
  587
+1. The name of the template tag -- a string. If this is left out, the
  588
+   name of the compilation function will be used.
  589
+2. The compilation function -- a Python function (not the name of the
  590
+   function as a string).
591 591
 
592 592
 As with filter registration, it is also possible to use this as a decorator:
593 593
 
@@ -623,12 +623,12 @@ tag format that date-time:
623 623
 
624 624
 Initially, ``token.split_contents()`` will return three values:
625 625
 
626  
-    1. The tag name ``format_time``.
627  
-    2. The string ``"blog_entry.date_updated"`` (without the surrounding
628  
-       quotes).
629  
-    3. The formatting string ``"%Y-%m-%d %I:%M %p"``. The return value from
630  
-       ``split_contents()`` will include the leading and trailing quotes for
631  
-       string literals like this.
  626
+1. The tag name ``format_time``.
  627
+2. The string ``"blog_entry.date_updated"`` (without the surrounding
  628
+   quotes).
  629
+3. The formatting string ``"%Y-%m-%d %I:%M %p"``. The return value from
  630
+   ``split_contents()`` will include the leading and trailing quotes for
  631
+   string literals like this.
632 632
 
633 633
 Now your tag should begin to look like this:
634 634
 
@@ -706,12 +706,12 @@ The decorator syntax also works:
706 706
 
707 707
 A few things to note about the ``simple_tag`` helper function:
708 708
 
709  
-    * Checking for the required number of arguments, etc., has already been
710  
-      done by the time our function is called, so we don't need to do that.
711  
-    * The quotes around the argument (if any) have already been stripped away,
712  
-      so we just receive a plain string.
713  
-    * If the argument was a template variable, our function is passed the
714  
-      current value of the variable, not the variable itself.
  709
+* Checking for the required number of arguments, etc., has already been
  710
+  done by the time our function is called, so we don't need to do that.
  711
+* The quotes around the argument (if any) have already been stripped away,
  712
+  so we just receive a plain string.
  713
+* If the argument was a template variable, our function is passed the
  714
+  current value of the variable, not the variable itself.
715 715
 
716 716
 .. versionadded:: 1.3
717 717
 
6  docs/howto/deployment/fastcgi.txt
@@ -168,9 +168,9 @@ Once you've got that set up, point Apache at your Django FastCGI instance by
168 168
 editing the ``httpd.conf`` (Apache configuration) file. You'll need to do two
169 169
 things:
170 170
 
171  
-    * Use the ``FastCGIExternalServer`` directive to specify the location of
172  
-      your FastCGI server.
173  
-    * Use ``mod_rewrite`` to point URLs at FastCGI as appropriate.
  171
+* Use the ``FastCGIExternalServer`` directive to specify the location of
  172
+  your FastCGI server.
  173
+* Use ``mod_rewrite`` to point URLs at FastCGI as appropriate.
174 174
 
175 175
 .. _mod_fastcgi: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
176 176
 
34  docs/howto/deployment/modpython.txt
@@ -240,11 +240,11 @@ server you choose.
240 240
 We recommend using a separate Web server -- i.e., one that's not also running
241 241
 Django -- for serving media. Here are some good choices:
242 242
 
243  
-    * lighttpd_
244  
-    * Nginx_
245  
-    * TUX_
246  
-    * A stripped-down version of Apache_
247  
-    * Cherokee_
  243
+* lighttpd_
  244
+* Nginx_
  245
+* TUX_
  246
+* A stripped-down version of Apache_
  247
+* Cherokee_
248 248
 
249 249
 If, however, you have no option but to serve media or static files on the
250 250
 same Apache ``VirtualHost`` as Django, here's how you can turn off mod_python
@@ -299,11 +299,11 @@ Django distribution.
299 299
 We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
300 300
 the admin files, but here are two other approaches:
301 301
 
302  
-    1. Create a symbolic link to the admin static files from within your
303  
-       document root.
  302
+1. Create a symbolic link to the admin static files from within your
  303
+   document root.
304 304
 
305  
-    2. Or, copy the admin static files so that they live within your Apache
306  
-       document root.
  305
+2. Or, copy the admin static files so that they live within your Apache
  306
+   document root.
307 307
 
308 308
 Using "eggs" with mod_python
309 309
 ============================
@@ -362,15 +362,15 @@ If you get a segmentation fault
362 362
 If Apache causes a segmentation fault, there are two probable causes, neither
363 363
 of which has to do with Django itself.
364 364
 
365  
-    1. It may be because your Python code is importing the "pyexpat" module,
366  
-       which may conflict with the version embedded in Apache. For full
367  
-       information, see `Expat Causing Apache Crash`_.
  365
+1. It may be because your Python code is importing the "pyexpat" module,
  366
+   which may conflict with the version embedded in Apache. For full
  367
+   information, see `Expat Causing Apache Crash`_.
368 368
 
369  
-    2. It may be because you're running mod_python and mod_php in the same
370  
-       Apache instance, with MySQL as your database backend. In some cases,
371  
-       this causes a known mod_python issue due to version conflicts in PHP and
372  
-       the Python MySQL backend. There's full information in the
373  
-       `mod_python FAQ entry`_.
  369
+2. It may be because you're running mod_python and mod_php in the same
  370
+   Apache instance, with MySQL as your database backend. In some cases,
  371
+   this causes a known mod_python issue due to version conflicts in PHP and
  372
+   the Python MySQL backend. There's full information in the
  373
+   `mod_python FAQ entry`_.
374 374
 
375 375
 If you continue to have problems setting up mod_python, a good thing to do is
376 376
 get a barebones mod_python site working, without the Django framework. This is
18  docs/howto/deployment/modwsgi.txt
@@ -64,11 +64,11 @@ server you choose.
64 64
 We recommend using a separate Web server -- i.e., one that's not also running
65 65
 Django -- for serving media. Here are some good choices:
66 66
 
67  
-    * lighttpd_
68  
-    * Nginx_
69  
-    * TUX_
70  
-    * A stripped-down version of Apache_
71  
-    * Cherokee_
  67
+* lighttpd_
  68
+* Nginx_
  69
+* TUX_
  70
+* A stripped-down version of Apache_
  71
+* Cherokee_
72 72
 
73 73
 If, however, you have no option but to serve media files on the same Apache
74 74
 ``VirtualHost`` as Django, you can set up Apache to serve some URLs as
@@ -131,11 +131,11 @@ Django distribution.
131 131
 We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
132 132
 the admin files, but here are two other approaches:
133 133
 
134  
-    1. Create a symbolic link to the admin static files from within your
135  
-       document root.
  134
+1. Create a symbolic link to the admin static files from within your
  135
+   document root.
136 136
 
137  
-    2. Or, copy the admin static files so that they live within your Apache
138  
-       document root.
  137
+2. Or, copy the admin static files so that they live within your Apache
  138
+   document root.
139 139
 
140 140
 Details
141 141
 =======
84  docs/howto/error-reporting.txt
@@ -56,12 +56,12 @@ setting.
56 56
 Django can also be configured to email errors about broken links (404 "page
57 57
 not found" errors). Django sends emails about 404 errors when:
58 58
 
59  
-    * :setting:`DEBUG` is ``False``
  59
+* :setting:`DEBUG` is ``False``
60 60
 
61  
-    * :setting:`SEND_BROKEN_LINK_EMAILS` is ``True``
  61
+* :setting:`SEND_BROKEN_LINK_EMAILS` is ``True``
62 62
 
63  
-    * Your :setting:`MIDDLEWARE_CLASSES` setting includes ``CommonMiddleware``
64  
-      (which it does by default).
  63
+* Your :setting:`MIDDLEWARE_CLASSES` setting includes ``CommonMiddleware``
  64
+  (which it does by default).
65 65
 
66 66
 If those conditions are met, Django will email the users listed in the
67 67
 :setting:`MANAGERS` setting whenever your code raises a 404 and the request has
@@ -144,18 +144,16 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
144 144
     If a function (either a view or any regular callback) in your code uses
145 145
     local variables susceptible to contain sensitive information, you may
146 146
     prevent the values of those variables from being included in error reports
147  
-    using the ``sensitive_variables`` decorator:
  147
+    using the ``sensitive_variables`` decorator::
148 148
 
149  
-        .. code-block:: python
  149
+        from django.views.decorators.debug import sensitive_variables
150 150
 
151  
-            from django.views.decorators.debug import sensitive_variables
152  
-
153  
-            @sensitive_variables('user', 'pw', 'cc')
154  
-            def process_info(user):
155  
-                pw = user.pass_word
156  
-                cc = user.credit_card_number
157  
-                name = user.name
158  
-                ...
  151
+        @sensitive_variables('user', 'pw', 'cc')
  152
+        def process_info(user):
  153
+            pw = user.pass_word
  154
+            cc = user.credit_card_number
  155
+            name = user.name
  156
+            ...
159 157
 
160 158
     In the above example, the values for the ``user``, ``pw`` and ``cc``
161 159
     variables will be hidden and replaced with stars (`**********`) in the
@@ -163,13 +161,11 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
163 161
     disclosed.
164 162
 
165 163
     To systematically hide all local variables of a function from error logs,
166  
-    do not provide any argument to the ``sensitive_variables`` decorator:
  164
+    do not provide any argument to the ``sensitive_variables`` decorator::
167 165
 
168  
-        .. code-block:: python
169  
-
170  
-            @sensitive_variables()
171  
-            def my_function():
172  
-                ...
  166
+        @sensitive_variables()
  167
+        def my_function():
  168
+            ...
173 169
 
174 170
 .. function:: sensitive_post_parameters(*parameters)
175 171
 
@@ -177,19 +173,17 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
177 173
     :attr:`POST parameters<HttpRequest.POST>` susceptible to contain sensitive
178 174
     information, you may prevent the values of those parameters from being
179 175
     included in the error reports using the ``sensitive_post_parameters``
180  
-    decorator:
  176
+    decorator::
1