Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Fixed broken links, round 3. refs #19516

  • Loading branch information...
commit b3a8c9dab87be6bc4b8096d292abe0b35c700bdd 1 parent e2ec7b4
Tim Graham authored December 25, 2012

Showing 34 changed files with 127 additions and 118 deletions. Show diff stats Hide diff stats

  1. 1  docs/conf.py
  2. 20  docs/howto/error-reporting.txt
  3. 6  docs/intro/tutorial02.txt
  4. 7  docs/intro/tutorial04.txt
  5. 5  docs/ref/contrib/comments/models.txt
  6. 6  docs/ref/contrib/comments/moderation.txt
  7. 14  docs/ref/contrib/contenttypes.txt
  8. 10  docs/ref/forms/api.txt
  9. 2  docs/ref/forms/fields.txt
  10. 10  docs/ref/forms/widgets.txt
  11. 5  docs/ref/models/fields.txt
  12. 2  docs/ref/models/instances.txt
  13. 14  docs/ref/models/querysets.txt
  14. 28  docs/ref/signals.txt
  15. 2  docs/ref/templates/builtins.txt
  16. 4  docs/ref/utils.txt
  17. 11  docs/releases/1.0-porting-guide.txt
  18. 2  docs/releases/1.1.txt
  19. 2  docs/releases/1.3-alpha-1.txt
  20. 4  docs/releases/1.4-alpha-1.txt
  21. 4  docs/releases/1.4-beta-1.txt
  22. 10  docs/releases/1.4.txt
  23. 15  docs/releases/1.5-alpha-1.txt
  24. 15  docs/releases/1.5-beta-1.txt
  25. 15  docs/releases/1.5.txt
  26. 4  docs/topics/auth.txt
  27. 4  docs/topics/db/queries.txt
  28. 5  docs/topics/i18n/timezones.txt
  29. 2  docs/topics/i18n/translation.txt
  30. 4  docs/topics/python3.txt
  31. 6  docs/topics/security.txt
  32. 2  docs/topics/serialization.txt
  33. 2  docs/topics/signals.txt
  34. 2  docs/topics/testing/index.txt
1  docs/conf.py
@@ -110,6 +110,7 @@ def django_release():
110 110
     'python': ('http://docs.python.org/2.7', None),
111 111
     'sphinx': ('http://sphinx.pocoo.org/', None),
112 112
     'six': ('http://packages.python.org/six/', None),
  113
+    'simplejson': ('http://simplejson.readthedocs.org/en/latest/', None),
113 114
 }
114 115
 
115 116
 # Python's docs don't change every week.
20  docs/howto/error-reporting.txt
@@ -123,7 +123,7 @@ Error reports are really helpful for debugging errors, so it is generally
123 123
 useful to record as much relevant information about those errors as possible.
124 124
 For example, by default Django records the `full traceback`_ for the
125 125
 exception raised, each `traceback frame`_'s local variables, and the
126  
-:class:`HttpRequest`'s :ref:`attributes<httprequest-attributes>`.
  126
+:class:`~django.http.HttpRequest`'s :ref:`attributes<httprequest-attributes>`.
127 127
 
128 128
 However, sometimes certain types of information may be too sensitive and thus
129 129
 may not be appropriate to be kept track of, for example a user's password or
@@ -165,11 +165,11 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
165 165
 
166 166
 .. function:: sensitive_post_parameters(*parameters)
167 167
 
168  
-    If one of your views receives an :class:`HttpRequest` object with
169  
-    :attr:`POST parameters<HttpRequest.POST>` susceptible to contain sensitive
170  
-    information, you may prevent the values of those parameters from being
171  
-    included in the error reports using the ``sensitive_post_parameters``
172  
-    decorator::
  168
+    If one of your views receives an :class:`~django.http.HttpRequest` object
  169
+    with :attr:`POST parameters<django.http.HttpRequest.POST>` susceptible to
  170
+    contain sensitive information, you may prevent the values of those
  171
+    parameters from being included in the error reports using the
  172
+    ``sensitive_post_parameters`` decorator::
173 173
 
174 174
         from django.views.decorators.debug import sensitive_post_parameters
175 175
 
@@ -198,10 +198,10 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
198 198
     .. versionchanged:: 1.4
199 199
 
200 200
     Since version 1.4, all POST parameters are systematically filtered out of
201  
-    error reports for certain :mod:`contrib.views.auth` views (``login``,
202  
-    ``password_reset_confirm``, ``password_change``, and ``add_view`` and
203  
-    ``user_change_password`` in the ``auth`` admin) to prevent the leaking of
204  
-    sensitive information such as user passwords.
  201
+    error reports for certain :mod:`django.contrib.auth.views` views (
  202
+    ``login``, ``password_reset_confirm``, ``password_change``, and
  203
+    ``add_view`` and ``user_change_password`` in the ``auth`` admin) to prevent
  204
+    the leaking of sensitive information such as user passwords.
205 205
 
206 206
 .. _custom-error-reports:
207 207
 
6  docs/intro/tutorial02.txt
@@ -398,9 +398,9 @@ That adds a "Filter" sidebar that lets people filter the change list by the
398 398
    :alt: Polls change list page, updated
399 399
 
400 400
 The type of filter displayed depends on the type of field you're filtering on.
401  
-Because ``pub_date`` is a :class:`~django.db.models.fields.DateTimeField`,
402  
-Django knows to give appropriate filter options: "Any date," "Today," "Past 7
403  
-days," "This month," "This year."
  401
+Because ``pub_date`` is a :class:`~django.db.models.DateTimeField`, Django
  402
+knows to give appropriate filter options: "Any date," "Today," "Past 7 days,"
  403
+"This month," "This year."
404 404
 
405 405
 This is shaping up well. Let's add some search capability::
406 406
 
7  docs/intro/tutorial04.txt
@@ -98,9 +98,10 @@ This code includes a few things we haven't covered yet in this tutorial:
98 98
   <django.http.HttpRequest.POST>` in our code, to ensure that data is only
99 99
   altered via a POST call.
100 100
 
101  
-* ``request.POST['choice']`` will raise :exc:`KeyError` if ``choice`` wasn't
102  
-  provided in POST data. The above code checks for :exc:`KeyError` and
103  
-  redisplays the poll form with an error message if ``choice`` isn't given.
  101
+* ``request.POST['choice']`` will raise :exc:`~exceptions.KeyError` if
  102
+  ``choice`` wasn't provided in POST data. The above code checks for
  103
+  :exc:`~exceptions.KeyError` and redisplays the poll form with an error
  104
+  message if ``choice`` isn't given.
104 105
 
105 106
 * After incrementing the choice count, the code returns an
106 107
   :class:`~django.http.HttpResponseRedirect` rather than a normal
5  docs/ref/contrib/comments/models.txt
@@ -11,12 +11,12 @@ The built-in comment models
11 11
 
12 12
     .. attribute:: content_object
13 13
 
14  
-        A :class:`~django.contrib.contettypes.generic.GenericForeignKey`
  14
+        A :class:`~django.contrib.contenttypes.generic.GenericForeignKey`
15 15
         attribute pointing to the object the comment is attached to. You can use
16 16
         this to get at the related object (i.e. ``my_comment.content_object``).
17 17
 
18 18
         Since this field is a
19  
-        :class:`~django.contrib.contettypes.generic.GenericForeignKey`, it's
  19
+        :class:`~django.contrib.contenttypes.generic.GenericForeignKey`, it's
20 20
         actually syntactic sugar on top of two underlying attributes, described
21 21
         below.
22 22
 
@@ -77,4 +77,3 @@ The built-in comment models
77 77
 
78 78
         ``True`` if the comment was removed. Used to keep track of removed
79 79
         comments instead of just deleting them.
80  
-
6  docs/ref/contrib/comments/moderation.txt
@@ -81,8 +81,8 @@ Built-in moderation options
81 81
     .. attribute:: auto_close_field
82 82
 
83 83
         If this is set to the name of a
84  
-        :class:`~django.db.models.fields.DateField` or
85  
-        :class:`~django.db.models.fields.DateTimeField` on the model for which
  84
+        :class:`~django.db.models.DateField` or
  85
+        :class:`~django.db.models.DateTimeField` on the model for which
86 86
         comments are being moderated, new comments for objects of that model
87 87
         will be disallowed (immediately deleted) when a certain number of days
88 88
         have passed after the date specified in that field. Must be
@@ -117,7 +117,7 @@ Built-in moderation options
117 117
     .. attribute:: enable_field
118 118
 
119 119
         If this is set to the name of a
120  
-        :class:`~django.db.models.fields.BooleanField` on the model
  120
+        :class:`~django.db.models.BooleanField` on the model
121 121
         for which comments are being moderated, new comments on
122 122
         objects of that model will be disallowed (immediately deleted)
123 123
         whenever the value of that field is ``False`` on the object
14  docs/ref/contrib/contenttypes.txt
@@ -234,13 +234,15 @@ lookup::
234 234
 
235 235
 .. versionadded:: 1.5
236 236
 
237  
-Prior to Django 1.5 :meth:`~ContentTypeManager.get_for_model()` and
238  
-:meth:`~ContentTypeManager.get_for_models()` always returned the
239  
-:class:`~django.contrib.contenttypes.models.ContentType` associated with the
240  
-concrete model of the specified one(s). That means there was no way to retreive
241  
-the :class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
  237
+Prior to Django 1.5,
  238
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model` and
  239
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_models`
  240
+always returned the :class:`~django.contrib.contenttypes.models.ContentType`
  241
+associated with the concrete model of the specified one(s). That means there
  242
+was no way to retreive the
  243
+:class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
242 244
 using those methods. As of Django 1.5 you can now pass a boolean flag –
243  
-respectively ``for_concrete_model`` and ``for_concrete_models`` – to specify
  245
+``for_concrete_model`` and ``for_concrete_models`` respectively – to specify
244 246
 wether or not you want to retreive the
245 247
 :class:`~django.contrib.contenttypes.models.ContentType` for the concrete or
246 248
 direct model.
10  docs/ref/forms/api.txt
@@ -150,11 +150,11 @@ it's not necessary to include every field in your form. For example::
150 150
 These values are only displayed for unbound forms, and they're not used as
151 151
 fallback values if a particular value isn't provided.
152 152
 
153  
-Note that if a :class:`~django.forms.fields.Field` defines
154  
-:attr:`~Form.initial` *and* you include ``initial`` when instantiating the
155  
-``Form``, then the latter ``initial`` will have precedence. In this example,
156  
-``initial`` is provided both at the field level and at the form instance level,
157  
-and the latter gets precedence::
  153
+Note that if a :class:`~django.forms.Field` defines :attr:`~Form.initial` *and*
  154
+you include ``initial`` when instantiating the ``Form``, then the latter
  155
+``initial`` will have precedence. In this example, ``initial`` is provided both
  156
+at the field level and at the form instance level, and the latter gets
  157
+precedence::
158 158
 
159 159
     >>> class CommentForm(forms.Form):
160 160
     ...     name = forms.CharField(initial='class')
2  docs/ref/forms/fields.txt
@@ -885,7 +885,7 @@ Slightly complex built-in ``Field`` classes
885 885
     .. attribute:: MultiValueField.widget
886 886
 
887 887
         Must be a subclass of :class:`django.forms.MultiWidget`.
888  
-        Default value is :class:`~django.forms.widgets.TextInput`, which
  888
+        Default value is :class:`~django.forms.TextInput`, which
889 889
         probably is not very useful in this case.
890 890
 
891 891
     .. method:: compress(data_list)
10  docs/ref/forms/widgets.txt
@@ -49,8 +49,8 @@ Setting arguments for widgets
49 49
 
50 50
 Many widgets have optional extra arguments; they can be set when defining the
51 51
 widget on the field. In the following example, the
52  
-:attr:`~SelectDateWidget.years` attribute is set for a
53  
-:class:`~django.forms.extras.widgets.SelectDateWidget`::
  52
+:attr:`~django.forms.extras.widgets.SelectDateWidget.years` attribute is set
  53
+for a :class:`~django.forms.extras.widgets.SelectDateWidget`::
54 54
 
55 55
     from django.forms.fields import DateField, ChoiceField, MultipleChoiceField
56 56
     from django.forms.widgets import RadioSelect, CheckboxSelectMultiple
@@ -222,7 +222,7 @@ foundation for custom widgets.
222 222
 .. class:: MultiWidget(widgets, attrs=None)
223 223
 
224 224
     A widget that is composed of multiple widgets.
225  
-    :class:`~django.forms.widgets.MultiWidget` works hand in hand with the
  225
+    :class:`~django.forms.MultiWidget` works hand in hand with the
226 226
     :class:`~django.forms.MultiValueField`.
227 227
 
228 228
     :class:`MultiWidget` has one required argument:
@@ -246,8 +246,8 @@ foundation for custom widgets.
246 246
         the combined value of the form field into the values for each widget.
247 247
 
248 248
         An example of this is how :class:`SplitDateTimeWidget` turns a
249  
-        :class:`datetime` value into a list with date and time split into two
250  
-        separate values::
  249
+        :class:`~datetime.datetime` value into a list with date and time split
  250
+        into two separate values::
251 251
 
252 252
             class SplitDateTimeWidget(MultiWidget):
253 253
 
5  docs/ref/models/fields.txt
@@ -547,8 +547,7 @@ Also has one optional argument:
547 547
     Optional. A storage object, which handles the storage and retrieval of your
548 548
     files. See :doc:`/topics/files` for details on how to provide this object.
549 549
 
550  
-The default form widget for this field is a
551  
-:class:`~django.forms.widgets.FileInput`.
  550
+The default form widget for this field is a :class:`~django.forms.FileInput`.
552 551
 
553 552
 Using a :class:`FileField` or an :class:`ImageField` (see below) in a model
554 553
 takes a few steps:
@@ -590,7 +589,7 @@ topic guide.
590 589
     saved.
591 590
 
592 591
 The uploaded file's relative URL can be obtained using the
593  
-:attr:`~django.db.models.fields.FileField.url` attribute. Internally,
  592
+:attr:`~django.db.models.FileField.url` attribute. Internally,
594 593
 this calls the :meth:`~django.core.files.storage.Storage.url` method of the
595 594
 underlying :class:`~django.core.files.storage.Storage` class.
596 595
 
2  docs/ref/models/instances.txt
@@ -659,7 +659,7 @@ For every :class:`~django.db.models.DateField` and
659 659
 <django.db.models.Field.null>`, the object will have ``get_next_by_FOO()`` and
660 660
 ``get_previous_by_FOO()`` methods, where ``FOO`` is the name of the field. This
661 661
 returns the next and previous object with respect to the date field, raising
662  
-a :exc:`~django.db.DoesNotExist` exception when appropriate.
  662
+a :exc:`~django.core.exceptions.DoesNotExist` exception when appropriate.
663 663
 
664 664
 Both methods accept optional keyword arguments, which should be in the format
665 665
 described in :ref:`Field lookups <field-lookups>`.
14  docs/ref/models/querysets.txt
@@ -1112,9 +1112,9 @@ one, doing so will result in an error.
1112 1112
 
1113 1113
 .. note::
1114 1114
 
1115  
-    When calling :meth:`~Model.save()` for instances with deferred fields,
1116  
-    only the loaded fields will be saved. See :meth:`~Model.save()` for more
1117  
-    details.
  1115
+    When calling :meth:`~django.db.models.Model.save()` for instances with
  1116
+    deferred fields, only the loaded fields will be saved. See
  1117
+    :meth:`~django.db.models.Model.save()` for more details.
1118 1118
 
1119 1119
 
1120 1120
 only
@@ -1164,9 +1164,9 @@ using :meth:`select_related` is an error as well.
1164 1164
 
1165 1165
 .. note::
1166 1166
 
1167  
-    When calling :meth:`~Model.save()` for instances with deferred fields,
1168  
-    only the loaded fields will be saved. See :meth:`~Model.save()` for more
1169  
-    details.
  1167
+    When calling :meth:`~django.db.models.Model.save()` for instances with
  1168
+    deferred fields, only the loaded fields will be saved. See
  1169
+    :meth:`~django.db.models.Model.save()` for more details.
1170 1170
 
1171 1171
 using
1172 1172
 ~~~~~
@@ -1248,7 +1248,7 @@ the format described in `Field lookups`_.
1248 1248
 
1249 1249
 ``get()`` raises :exc:`~django.core.exceptions.MultipleObjectsReturned` if more
1250 1250
 than one object was found. The
1251  
-:exc:`~django.core.excpetions.MultipleObjectsReturned` exception is an
  1251
+:exc:`~django.core.exceptions.MultipleObjectsReturned` exception is an
1252 1252
 attribute of the model class.
1253 1253
 
1254 1254
 ``get()`` raises a :exc:`~django.core.exceptions.DoesNotExist` exception if an
28  docs/ref/signals.txt
@@ -212,24 +212,24 @@ m2m_changed
212 212
 .. data:: django.db.models.signals.m2m_changed
213 213
    :module:
214 214
 
215  
-Sent when a :class:`ManyToManyField` is changed on a model instance.
216  
-Strictly speaking, this is not a model signal since it is sent by the
217  
-:class:`ManyToManyField`, but since it complements the
  215
+Sent when a :class:`~django.db.models.ManyToManyField` is changed on a model
  216
+instance. Strictly speaking, this is not a model signal since it is sent by the
  217
+:class:`~django.db.models.ManyToManyField`, but since it complements the
218 218
 :data:`pre_save`/:data:`post_save` and :data:`pre_delete`/:data:`post_delete`
219 219
 when it comes to tracking changes to models, it is included here.
220 220
 
221 221
 Arguments sent with this signal:
222 222
 
223 223
 ``sender``
224  
-    The intermediate model class describing the :class:`ManyToManyField`.
225  
-    This class is automatically created when a many-to-many field is
226  
-    defined; you can access it using the ``through`` attribute on the
227  
-    many-to-many field.
  224
+    The intermediate model class describing the
  225
+    :class:`~django.db.models.ManyToManyField`. This class is automatically
  226
+    created when a many-to-many field is defined; you can access it using the
  227
+    ``through`` attribute on the many-to-many field.
228 228
 
229 229
 ``instance``
230 230
     The instance whose many-to-many relation is updated. This can be an
231  
-    instance of the ``sender``, or of the class the :class:`ManyToManyField`
232  
-    is related to.
  231
+    instance of the ``sender``, or of the class the
  232
+    :class:`~django.db.models.ManyToManyField` is related to.
233 233
 
234 234
 ``action``
235 235
     A string indicating the type of update that is done on the relation.
@@ -303,8 +303,9 @@ Argument        Value
303 303
 
304 304
 ``action``      ``"pre_add"`` (followed by a separate signal with ``"post_add"``)
305 305
 
306  
-``reverse``     ``False`` (``Pizza`` contains the :class:`ManyToManyField`,
307  
-                so this call modifies the forward relation)
  306
+``reverse``     ``False`` (``Pizza`` contains the
  307
+                :class:`~django.db.models.ManyToManyField`, so this call
  308
+                modifies the forward relation)
308 309
 
309 310
 ``model``       ``Topping`` (the class of the objects added to the
310 311
                 ``Pizza``)
@@ -329,8 +330,9 @@ Argument        Value
329 330
 
330 331
 ``action``      ``"pre_remove"`` (followed by a separate signal with ``"post_remove"``)
331 332
 
332  
-``reverse``     ``True`` (``Pizza`` contains the :class:`ManyToManyField`,
333  
-                so this call modifies the reverse relation)
  333
+``reverse``     ``True`` (``Pizza`` contains the
  334
+                :class:`~django.db.models.ManyToManyField`, so this call
  335
+                modifies the reverse relation)
334 336
 
335 337
 ``model``       ``Pizza`` (the class of the objects removed from the
336 338
                 ``Topping``)
2  docs/ref/templates/builtins.txt
@@ -864,7 +864,7 @@ an attribute "description," you could use::
864 864
     {% regroup cities by country.description as country_list %}
865 865
 
866 866
 Or, if ``country`` is a field with ``choices``, it will have a
867  
-:meth:`^django.db.models.Model.get_FOO_display` method available as an
  867
+:meth:`~django.db.models.Model.get_FOO_display` method available as an
868 868
 attribute, allowing  you to group on the display string rather than the
869 869
 ``choices`` key::
870 870
 
4  docs/ref/utils.txt
@@ -145,8 +145,8 @@ results. Instead do::
145 145
 
146 146
 The functions defined in this module share the following properties:
147 147
 
148  
-- They raise :exc:`ValueError` if their input is well formatted but isn't a
149  
-  valid date or time.
  148
+- They raise :exc:`~exceptions.ValueError` if their input is well formatted but
  149
+  isn't a valid date or time.
150 150
 - They return ``None`` if it isn't well formatted at all.
151 151
 - They accept up to picosecond resolution in input, but they truncate it to
152 152
   microseconds, since that's what Python supports.
11  docs/releases/1.0-porting-guide.txt
@@ -439,9 +439,10 @@ Settings
439 439
 Better exceptions
440 440
 ~~~~~~~~~~~~~~~~~
441 441
 
442  
-The old :exc:`EnvironmentError` has split into an :exc:`ImportError` when
443  
-Django fails to find the settings module and a :exc:`RuntimeError` when you try
444  
-to reconfigure settings after having already used them
  442
+The old :exc:`~exceptions.EnvironmentError` has split into an
  443
+:exc:`~exceptions.ImportError` when Django fails to find the settings module
  444
+and a :exc:`~exceptions.RuntimeError` when you try to reconfigure settings
  445
+after having already used them.
445 446
 
446 447
 :setting:`LOGIN_URL` has moved
447 448
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -476,8 +477,8 @@ Smaller model changes
476 477
 Different exception from ``get()``
477 478
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
478 479
 
479  
-Managers now return a :exc:`MultipleObjectsReturned` exception
480  
-instead of :exc:`AssertionError`:
  480
+Managers now return a :exc:`~django.core.exceptions.MultipleObjectsReturned`
  481
+exception instead of :exc:`~exceptions.AssertionError`:
481 482
 
482 483
 Old (0.96)::
483 484
 
2  docs/releases/1.1.txt
@@ -132,7 +132,7 @@ public methods.
132 132
 Fixed the ``join`` filter's escaping behavior
133 133
 ---------------------------------------------
134 134
 
135  
-The :ttag:`join` filter no longer escapes the literal value that is
  135
+The :tfilter:`join` filter no longer escapes the literal value that is
136 136
 passed in for the connector.
137 137
 
138 138
 This is backwards incompatible for the special situation of the literal string
2  docs/releases/1.3-alpha-1.txt
@@ -156,7 +156,7 @@ requests. These include:
156 156
   requests in tests.
157 157
 
158 158
 * A new test assertion --
159  
-  :meth:`~django.test.client.Client.assertNumQueries` -- making it
  159
+  :meth:`~django.test.TestCase.assertNumQueries` -- making it
160 160
   easier to test the database activity associated with a view.
161 161
 
162 162
 
4  docs/releases/1.4-alpha-1.txt
@@ -357,8 +357,8 @@ Extended IPv6 support
357 357
 
358 358
 The previously added support for IPv6 addresses when using the runserver
359 359
 management command in Django 1.3 has now been further extended by adding
360  
-a :class:`~django.db.models.fields.GenericIPAddressField` model field,
361  
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
  360
+a :class:`~django.db.models.GenericIPAddressField` model field,
  361
+a :class:`~django.forms.GenericIPAddressField` form field and
362 362
 the validators :data:`~django.core.validators.validate_ipv46_address` and
363 363
 :data:`~django.core.validators.validate_ipv6_address`
364 364
 
4  docs/releases/1.4-beta-1.txt
@@ -395,8 +395,8 @@ Extended IPv6 support
395 395
 
396 396
 The previously added support for IPv6 addresses when using the runserver
397 397
 management command in Django 1.3 has now been further extended by adding
398  
-a :class:`~django.db.models.fields.GenericIPAddressField` model field,
399  
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
  398
+a :class:`~django.db.models.GenericIPAddressField` model field,
  399
+a :class:`~django.forms.GenericIPAddressField` form field and
400 400
 the validators :data:`~django.core.validators.validate_ipv46_address` and
401 401
 :data:`~django.core.validators.validate_ipv6_address`
402 402
 
10  docs/releases/1.4.txt
@@ -526,8 +526,8 @@ Extended IPv6 support
526 526
 ~~~~~~~~~~~~~~~~~~~~~
527 527
 
528 528
 Django 1.4 can now better handle IPv6 addresses with the new
529  
-:class:`~django.db.models.fields.GenericIPAddressField` model field,
530  
-:class:`~django.forms.fields.GenericIPAddressField` form field and
  529
+:class:`~django.db.models.GenericIPAddressField` model field,
  530
+:class:`~django.forms.GenericIPAddressField` form field and
531 531
 the validators :data:`~django.core.validators.validate_ipv46_address` and
532 532
 :data:`~django.core.validators.validate_ipv6_address`.
533 533
 
@@ -890,7 +890,7 @@ object, Django raises an exception.
890 890
 
891 891
 The MySQL backend historically has raised :class:`MySQLdb.OperationalError`
892 892
 when a query triggered an exception. We've fixed this bug, and we now raise
893  
-:class:`django.db.utils.DatabaseError` instead. If you were testing for
  893
+:exc:`django.db.DatabaseError` instead. If you were testing for
894 894
 :class:`MySQLdb.OperationalError`, you'll need to update your ``except``
895 895
 clauses.
896 896
 
@@ -1092,8 +1092,8 @@ wild, because they would confuse browsers too.
1092 1092
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1093 1093
 
1094 1094
 It's now possible to check whether a template was used within a block of
1095  
-code with :meth:`~django.test.test.TestCase.assertTemplateUsed` and
1096  
-:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they
  1095
+code with :meth:`~django.test.TestCase.assertTemplateUsed` and
  1096
+:meth:`~django.test.TestCase.assertTemplateNotUsed`. And they
1097 1097
 can be used as a context manager::
1098 1098
 
1099 1099
     with self.assertTemplateUsed('index.html'):
15  docs/releases/1.5-alpha-1.txt
@@ -391,12 +391,12 @@ System version of :mod:`simplejson` no longer used
391 391
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
392 392
 
393 393
 As explained below, Django 1.5 deprecates
394  
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
  394
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
395 395
 module. In theory, this change is harmless. Unfortunately, because of
396 396
 incompatibilities between versions of :mod:`simplejson`, it may trigger errors
397 397
 in some circumstances.
398 398
 
399  
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
  399
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
400 400
 This module was actually:
401 401
 
402 402
 - A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -546,8 +546,9 @@ Miscellaneous
546 546
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
547 547
   ``QuerySet`` as the empty value instead of an empty list.
548 548
 
549  
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
550  
-  instead of :exc:`ValueError` for non-integer inputs.
  549
+* :func:`~django.utils.http.int_to_base36` properly raises a
  550
+  :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
  551
+  non-integer inputs.
551 552
 
552 553
 * The ``slugify`` template filter is now available as a standard python
553 554
   function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -584,8 +585,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
584 585
 :meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
585 586
 the user profile model, should not be used any longer.
586 587
 
587  
-Streaming behavior of :class:`HttpResponse`
588  
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  588
+Streaming behavior of :class:`~django.http.HttpResponse`
  589
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
589 590
 
590 591
 Django 1.5 deprecates the ability to stream a response by passing an iterator
591 592
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -600,7 +601,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
600 601
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
601 602
 :mod:`json` module being available in Python's standard library, so we've
602 603
 removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
603  
-instead :mod:`django.utils.simplejson`.
  604
+instead of ``django.utils.simplejson``.
604 605
 
605 606
 Unfortunately, this change might have unwanted side-effects, because of
606 607
 incompatibilities between versions of :mod:`simplejson` -- see the backwards-
15  docs/releases/1.5-beta-1.txt
@@ -416,12 +416,12 @@ System version of :mod:`simplejson` no longer used
416 416
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
417 417
 
418 418
 :ref:`As explained below <simplejson-deprecation-beta-1>`, Django 1.5 deprecates
419  
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
  419
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
420 420
 module. In theory, this change is harmless. Unfortunately, because of
421 421
 incompatibilities between versions of :mod:`simplejson`, it may trigger errors
422 422
 in some circumstances.
423 423
 
424  
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
  424
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
425 425
 This module was actually:
426 426
 
427 427
 - A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -585,8 +585,9 @@ Miscellaneous
585 585
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
586 586
   ``QuerySet`` as the empty value instead of an empty list.
587 587
 
588  
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
589  
-  instead of :exc:`ValueError` for non-integer inputs.
  588
+* :func:`~django.utils.http.int_to_base36` properly raises a
  589
+  :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
  590
+  non-integer inputs.
590 591
 
591 592
 * The ``slugify`` template filter is now available as a standard python
592 593
   function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -636,8 +637,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
636 637
 :meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
637 638
 the user profile model, should not be used any longer.
638 639
 
639  
-Streaming behavior of :class:`HttpResponse`
640  
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  640
+Streaming behavior of :class:`~django.http.HttpResponse`
  641
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
641 642
 
642 643
 Django 1.5 deprecates the ability to stream a response by passing an iterator
643 644
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -653,7 +654,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
653 654
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
654 655
 :mod:`json` module being available in Python's standard library, so we've
655 656
 removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
656  
-instead :mod:`django.utils.simplejson`.
  657
+instead of ``django.utils.simplejson``.
657 658
 
658 659
 Unfortunately, this change might have unwanted side-effects, because of
659 660
 incompatibilities between versions of :mod:`simplejson` -- see the
15  docs/releases/1.5.txt
@@ -429,12 +429,12 @@ System version of :mod:`simplejson` no longer used
429 429
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
430 430
 
431 431
 :ref:`As explained below <simplejson-deprecation>`, Django 1.5 deprecates
432  
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
  432
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
433 433
 module. In theory, this change is harmless. Unfortunately, because of
434 434
 incompatibilities between versions of :mod:`simplejson`, it may trigger errors
435 435
 in some circumstances.
436 436
 
437  
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
  437
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
438 438
 This module was actually:
439 439
 
440 440
 - A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -598,8 +598,9 @@ Miscellaneous
598 598
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
599 599
   ``QuerySet`` as the empty value instead of an empty list.
600 600
 
601  
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
602  
-  instead of :exc:`ValueError` for non-integer inputs.
  601
+* :func:`~django.utils.http.int_to_base36` properly raises a
  602
+  :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
  603
+  non-integer inputs.
603 604
 
604 605
 * The ``slugify`` template filter is now available as a standard python
605 606
   function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -668,8 +669,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
668 669
 :meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
669 670
 the user profile model, should not be used any longer.
670 671
 
671  
-Streaming behavior of :class:`HttpResponse`
672  
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  672
+Streaming behavior of :class:`~django.http.HttpResponse`
  673
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
673 674
 
674 675
 Django 1.5 deprecates the ability to stream a response by passing an iterator
675 676
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -687,7 +688,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
687 688
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
688 689
 :mod:`json` module being available in Python's standard library, so we've
689 690
 removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
690  
-instead :mod:`django.utils.simplejson`.
  691
+instead of ``django.utils.simplejson``.
691 692
 
692 693
 Unfortunately, this change might have unwanted side-effects, because of
693 694
 incompatibilities between versions of :mod:`simplejson` -- see the
4  docs/topics/auth.txt
@@ -284,7 +284,7 @@ Manager functions
284 284
         .. versionchanged:: 1.4
285 285
            The ``email`` parameter was made optional. The username
286 286
            parameter is now checked for emptiness and raises a
287  
-           :exc:`ValueError` in case of a negative result.
  287
+           :exc:`~exceptions.ValueError` in case of a negative result.
288 288
 
289 289
         Creates, saves and returns a :class:`~django.contrib.auth.models.User`.
290 290
 
@@ -558,7 +558,7 @@ Anonymous users
558 558
       :meth:`~django.contrib.auth.models.User.delete()`,
559 559
       :meth:`~django.contrib.auth.models.User.set_groups()` and
560 560
       :meth:`~django.contrib.auth.models.User.set_permissions()` raise
561  
-      :exc:`NotImplementedError`.
  561
+      :exc:`~exceptions.NotImplementedError`.
562 562
 
563 563
 In practice, you probably won't need to use
564 564
 :class:`~django.contrib.auth.models.AnonymousUser` objects on your own, but
4  docs/topics/db/queries.txt
@@ -327,8 +327,8 @@ a primary key of 1, Django will raise ``Entry.DoesNotExist``.
327 327
 
328 328
 Similarly, Django will complain if more than one item matches the
329 329
 :meth:`~django.db.models.query.QuerySet.get` query. In this case, it will raise
330  
-``MultipleObjectsReturned``, which again is an attribute of the model class
331  
-itself.
  330
+:exc:`~django.core.exceptions.MultipleObjectsReturned`, which again is an
  331
+attribute of the model class itself.
332 332
 
333 333
 
334 334
 Other QuerySet methods
5  docs/topics/i18n/timezones.txt
@@ -456,8 +456,9 @@ zone support.
456 456
 
457 457
 Fixtures generated with ``USE_TZ = False``, or before Django 1.4, use the
458 458
 "naive" format. If your project contains such fixtures, after you enable time
459  
-zone support, you'll see :exc:`RuntimeWarning`\ s when you load them. To get
460  
-rid of the warnings, you must convert your fixtures to the "aware" format.
  459
+zone support, you'll see :exc:`~exceptions.RuntimeWarning`\ s when you load
  460
+them. To get rid of the warnings, you must convert your fixtures to the "aware"
  461
+format.
461 462
 
462 463
 You can regenerate fixtures with :djadmin:`loaddata` then :djadmin:`dumpdata`.
463 464
 Or, if they're small enough, you can simply edit them to add the UTC offset
2  docs/topics/i18n/translation.txt
@@ -928,7 +928,7 @@ function. Example::
928 928
 
929 929
     :func:`~django.conf.urls.i18n.i18n_patterns` is only allowed in your root
930 930
     URLconf. Using it within an included URLconf will throw an
931  
-    :exc:`ImproperlyConfigured` exception.
  931
+    :exc:`~django.core.exceptions.ImproperlyConfigured` exception.
932 932
 
933 933
 .. warning::
934 934
 
4  docs/topics/python3.txt
@@ -343,7 +343,7 @@ meaning of ``str`` changed. To test these types, use the following idioms::
343 343
     isinstance(myvalue, bytes)                  # replacement for str
344 344
 
345 345
 Python ≥ 2.6 provides ``bytes`` as an alias for ``str``, so you don't need
346  
-:attr:`six.binary_type`.
  346
+:data:`six.binary_type`.
347 347
 
348 348
 ``long``
349 349
 ~~~~~~~~
@@ -356,7 +356,7 @@ The ``long`` type no longer exists in Python 3. ``1L`` is a syntax error. Use
356 356
 ``xrange``
357 357
 ~~~~~~~~~~
358 358
 
359  
-Import :func:`six.moves.xrange` wherever you use ``xrange``.
  359
+Import ``six.moves.xrange`` wherever you use ``xrange``.
360 360
 
361 361
 Moved modules
362 362
 ~~~~~~~~~~~~~
6  docs/topics/security.txt
@@ -38,7 +38,7 @@ in unauthorized JavaScript execution, depending on how the browser renders
38 38
 imperfect HTML.
39 39
 
40 40
 It is also important to be particularly careful when using ``is_safe`` with
41  
-custom template tags, the :ttag:`safe` template tag, :mod:`mark_safe
  41
+custom template tags, the :tfilter:`safe` template tag, :mod:`mark_safe
42 42
 <django.utils.safestring>`, and when autoescape is turned off.
43 43
 
44 44
 In addition, if you are using the template system to output something other
@@ -76,8 +76,8 @@ POST to your Web site and have another logged in user unwittingly submit that
76 76
 form. The malicious user would have to know the nonce, which is user specific
77 77
 (using a cookie).
78 78
 
79  
-When deployed with :ref:`HTTPS <security-recommendation-ssl>`, 
80  
-``CsrfViewMiddleware`` will check that the HTTP referer header is set to a 
  79
+When deployed with :ref:`HTTPS <security-recommendation-ssl>`,
  80
+``CsrfViewMiddleware`` will check that the HTTP referer header is set to a
81 81
 URL on the same origin (including subdomain and port). Because HTTPS
82 82
 provides additional security, it is imperative to ensure connections use HTTPS
83 83
 where it is available by forwarding insecure connection requests and using
2  docs/topics/serialization.txt
@@ -193,7 +193,7 @@ This strategy works well for most objects, but it can cause difficulty in some
193 193
 circumstances.
194 194
 
195 195
 Consider the case of a list of objects that have a foreign key referencing
196  
-:class:`~django.contrib.conttenttypes.models.ContentType`. If you're going to
  196
+:class:`~django.contrib.contenttypes.models.ContentType`. If you're going to
197 197
 serialize an object that refers to a content type, then you need to have a way
198 198
 to refer to that content type to begin with. Since ``ContentType`` objects are
199 199
 automatically created by Django during the database synchronization process,
2  docs/topics/signals.txt
@@ -30,7 +30,7 @@ notifications:
30 30
 
31 31
 * :data:`django.db.models.signals.m2m_changed`
32 32
 
33  
-  Sent when a :class:`ManyToManyField` on a model is changed.
  33
+  Sent when a :class:`~django.db.models.ManyToManyField` on a model is changed.
34 34
 
35 35
 * :data:`django.core.signals.request_started` &
36 36
   :data:`django.core.signals.request_finished`
2  docs/topics/testing/index.txt
@@ -38,7 +38,7 @@ frameworks are:
38 38
 
39 39
 * **Unit tests** -- tests that are expressed as methods on a Python class
40 40
   that subclasses :class:`unittest.TestCase` or Django's customized
41  
-  :class:`TestCase`. For example::
  41
+  :class:`~django.test.TestCase`. For example::
42 42
 
43 43
       import unittest
44 44
 

0 notes on commit b3a8c9d

Please sign in to comment.
Something went wrong with that request. Please try again.