Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Fixed broken links, round 3. refs #19516

  • Loading branch information...
commit b3a8c9dab87be6bc4b8096d292abe0b35c700bdd 1 parent e2ec7b4
Tim Graham timgraham authored
Showing with 127 additions and 118 deletions.
  1. +1 −0  docs/conf.py
  2. +10 −10 docs/howto/error-reporting.txt
  3. +3 −3 docs/intro/tutorial02.txt
  4. +4 −3 docs/intro/tutorial04.txt
  5. +2 −3 docs/ref/contrib/comments/models.txt
  6. +3 −3 docs/ref/contrib/comments/moderation.txt
  7. +8 −6 docs/ref/contrib/contenttypes.txt
  8. +5 −5 docs/ref/forms/api.txt
  9. +1 −1  docs/ref/forms/fields.txt
  10. +5 −5 docs/ref/forms/widgets.txt
  11. +2 −3 docs/ref/models/fields.txt
  12. +1 −1  docs/ref/models/instances.txt
  13. +7 −7 docs/ref/models/querysets.txt
  14. +15 −13 docs/ref/signals.txt
  15. +1 −1  docs/ref/templates/builtins.txt
  16. +2 −2 docs/ref/utils.txt
  17. +6 −5 docs/releases/1.0-porting-guide.txt
  18. +1 −1  docs/releases/1.1.txt
  19. +1 −1  docs/releases/1.3-alpha-1.txt
  20. +2 −2 docs/releases/1.4-alpha-1.txt
  21. +2 −2 docs/releases/1.4-beta-1.txt
  22. +5 −5 docs/releases/1.4.txt
  23. +8 −7 docs/releases/1.5-alpha-1.txt
  24. +8 −7 docs/releases/1.5-beta-1.txt
  25. +8 −7 docs/releases/1.5.txt
  26. +2 −2 docs/topics/auth.txt
  27. +2 −2 docs/topics/db/queries.txt
  28. +3 −2 docs/topics/i18n/timezones.txt
  29. +1 −1  docs/topics/i18n/translation.txt
  30. +2 −2 docs/topics/python3.txt
  31. +3 −3 docs/topics/security.txt
  32. +1 −1  docs/topics/serialization.txt
  33. +1 −1  docs/topics/signals.txt
  34. +1 −1  docs/topics/testing/index.txt
1  docs/conf.py
View
@@ -110,6 +110,7 @@ def django_release():
'python': ('http://docs.python.org/2.7', None),
'sphinx': ('http://sphinx.pocoo.org/', None),
'six': ('http://packages.python.org/six/', None),
+ 'simplejson': ('http://simplejson.readthedocs.org/en/latest/', None),
}
# Python's docs don't change every week.
20 docs/howto/error-reporting.txt
View
@@ -123,7 +123,7 @@ Error reports are really helpful for debugging errors, so it is generally
useful to record as much relevant information about those errors as possible.
For example, by default Django records the `full traceback`_ for the
exception raised, each `traceback frame`_'s local variables, and the
-:class:`HttpRequest`'s :ref:`attributes<httprequest-attributes>`.
+:class:`~django.http.HttpRequest`'s :ref:`attributes<httprequest-attributes>`.
However, sometimes certain types of information may be too sensitive and thus
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``):
.. function:: sensitive_post_parameters(*parameters)
- If one of your views receives an :class:`HttpRequest` object with
- :attr:`POST parameters<HttpRequest.POST>` susceptible to contain sensitive
- information, you may prevent the values of those parameters from being
- included in the error reports using the ``sensitive_post_parameters``
- decorator::
+ If one of your views receives an :class:`~django.http.HttpRequest` object
+ with :attr:`POST parameters<django.http.HttpRequest.POST>` susceptible to
+ contain sensitive information, you may prevent the values of those
+ parameters from being included in the error reports using the
+ ``sensitive_post_parameters`` decorator::
from django.views.decorators.debug import sensitive_post_parameters
@@ -198,10 +198,10 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
.. versionchanged:: 1.4
Since version 1.4, all POST parameters are systematically filtered out of
- error reports for certain :mod:`contrib.views.auth` views (``login``,
- ``password_reset_confirm``, ``password_change``, and ``add_view`` and
- ``user_change_password`` in the ``auth`` admin) to prevent the leaking of
- sensitive information such as user passwords.
+ error reports for certain :mod:`django.contrib.auth.views` views (
+ ``login``, ``password_reset_confirm``, ``password_change``, and
+ ``add_view`` and ``user_change_password`` in the ``auth`` admin) to prevent
+ the leaking of sensitive information such as user passwords.
.. _custom-error-reports:
6 docs/intro/tutorial02.txt
View
@@ -398,9 +398,9 @@ That adds a "Filter" sidebar that lets people filter the change list by the
:alt: Polls change list page, updated
The type of filter displayed depends on the type of field you're filtering on.
-Because ``pub_date`` is a :class:`~django.db.models.fields.DateTimeField`,
-Django knows to give appropriate filter options: "Any date," "Today," "Past 7
-days," "This month," "This year."
+Because ``pub_date`` is a :class:`~django.db.models.DateTimeField`, Django
+knows to give appropriate filter options: "Any date," "Today," "Past 7 days,"
+"This month," "This year."
This is shaping up well. Let's add some search capability::
7 docs/intro/tutorial04.txt
View
@@ -98,9 +98,10 @@ This code includes a few things we haven't covered yet in this tutorial:
<django.http.HttpRequest.POST>` in our code, to ensure that data is only
altered via a POST call.
-* ``request.POST['choice']`` will raise :exc:`KeyError` if ``choice`` wasn't
- provided in POST data. The above code checks for :exc:`KeyError` and
- redisplays the poll form with an error message if ``choice`` isn't given.
+* ``request.POST['choice']`` will raise :exc:`~exceptions.KeyError` if
+ ``choice`` wasn't provided in POST data. The above code checks for
+ :exc:`~exceptions.KeyError` and redisplays the poll form with an error
+ message if ``choice`` isn't given.
* After incrementing the choice count, the code returns an
:class:`~django.http.HttpResponseRedirect` rather than a normal
5 docs/ref/contrib/comments/models.txt
View
@@ -11,12 +11,12 @@ The built-in comment models
.. attribute:: content_object
- A :class:`~django.contrib.contettypes.generic.GenericForeignKey`
+ A :class:`~django.contrib.contenttypes.generic.GenericForeignKey`
attribute pointing to the object the comment is attached to. You can use
this to get at the related object (i.e. ``my_comment.content_object``).
Since this field is a
- :class:`~django.contrib.contettypes.generic.GenericForeignKey`, it's
+ :class:`~django.contrib.contenttypes.generic.GenericForeignKey`, it's
actually syntactic sugar on top of two underlying attributes, described
below.
@@ -77,4 +77,3 @@ The built-in comment models
``True`` if the comment was removed. Used to keep track of removed
comments instead of just deleting them.
-
6 docs/ref/contrib/comments/moderation.txt
View
@@ -81,8 +81,8 @@ Built-in moderation options
.. attribute:: auto_close_field
If this is set to the name of a
- :class:`~django.db.models.fields.DateField` or
- :class:`~django.db.models.fields.DateTimeField` on the model for which
+ :class:`~django.db.models.DateField` or
+ :class:`~django.db.models.DateTimeField` on the model for which
comments are being moderated, new comments for objects of that model
will be disallowed (immediately deleted) when a certain number of days
have passed after the date specified in that field. Must be
@@ -117,7 +117,7 @@ Built-in moderation options
.. attribute:: enable_field
If this is set to the name of a
- :class:`~django.db.models.fields.BooleanField` on the model
+ :class:`~django.db.models.BooleanField` on the model
for which comments are being moderated, new comments on
objects of that model will be disallowed (immediately deleted)
whenever the value of that field is ``False`` on the object
14 docs/ref/contrib/contenttypes.txt
View
@@ -234,13 +234,15 @@ lookup::
.. versionadded:: 1.5
-Prior to Django 1.5 :meth:`~ContentTypeManager.get_for_model()` and
-:meth:`~ContentTypeManager.get_for_models()` always returned the
-:class:`~django.contrib.contenttypes.models.ContentType` associated with the
-concrete model of the specified one(s). That means there was no way to retreive
-the :class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
+Prior to Django 1.5,
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model` and
+:meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_models`
+always returned the :class:`~django.contrib.contenttypes.models.ContentType`
+associated with the concrete model of the specified one(s). That means there
+was no way to retreive the
+:class:`~django.contrib.contenttypes.models.ContentType` of a proxy model
using those methods. As of Django 1.5 you can now pass a boolean flag –
-respectively ``for_concrete_model`` and ``for_concrete_models`` – to specify
+``for_concrete_model`` and ``for_concrete_models`` respectively – to specify
wether or not you want to retreive the
:class:`~django.contrib.contenttypes.models.ContentType` for the concrete or
direct model.
10 docs/ref/forms/api.txt
View
@@ -150,11 +150,11 @@ it's not necessary to include every field in your form. For example::
These values are only displayed for unbound forms, and they're not used as
fallback values if a particular value isn't provided.
-Note that if a :class:`~django.forms.fields.Field` defines
-:attr:`~Form.initial` *and* you include ``initial`` when instantiating the
-``Form``, then the latter ``initial`` will have precedence. In this example,
-``initial`` is provided both at the field level and at the form instance level,
-and the latter gets precedence::
+Note that if a :class:`~django.forms.Field` defines :attr:`~Form.initial` *and*
+you include ``initial`` when instantiating the ``Form``, then the latter
+``initial`` will have precedence. In this example, ``initial`` is provided both
+at the field level and at the form instance level, and the latter gets
+precedence::
>>> class CommentForm(forms.Form):
... name = forms.CharField(initial='class')
2  docs/ref/forms/fields.txt
View
@@ -885,7 +885,7 @@ Slightly complex built-in ``Field`` classes
.. attribute:: MultiValueField.widget
Must be a subclass of :class:`django.forms.MultiWidget`.
- Default value is :class:`~django.forms.widgets.TextInput`, which
+ Default value is :class:`~django.forms.TextInput`, which
probably is not very useful in this case.
.. method:: compress(data_list)
10 docs/ref/forms/widgets.txt
View
@@ -49,8 +49,8 @@ Setting arguments for widgets
Many widgets have optional extra arguments; they can be set when defining the
widget on the field. In the following example, the
-:attr:`~SelectDateWidget.years` attribute is set for a
-:class:`~django.forms.extras.widgets.SelectDateWidget`::
+:attr:`~django.forms.extras.widgets.SelectDateWidget.years` attribute is set
+for a :class:`~django.forms.extras.widgets.SelectDateWidget`::
from django.forms.fields import DateField, ChoiceField, MultipleChoiceField
from django.forms.widgets import RadioSelect, CheckboxSelectMultiple
@@ -222,7 +222,7 @@ foundation for custom widgets.
.. class:: MultiWidget(widgets, attrs=None)
A widget that is composed of multiple widgets.
- :class:`~django.forms.widgets.MultiWidget` works hand in hand with the
+ :class:`~django.forms.MultiWidget` works hand in hand with the
:class:`~django.forms.MultiValueField`.
:class:`MultiWidget` has one required argument:
@@ -246,8 +246,8 @@ foundation for custom widgets.
the combined value of the form field into the values for each widget.
An example of this is how :class:`SplitDateTimeWidget` turns a
- :class:`datetime` value into a list with date and time split into two
- separate values::
+ :class:`~datetime.datetime` value into a list with date and time split
+ into two separate values::
class SplitDateTimeWidget(MultiWidget):
5 docs/ref/models/fields.txt
View
@@ -547,8 +547,7 @@ Also has one optional argument:
Optional. A storage object, which handles the storage and retrieval of your
files. See :doc:`/topics/files` for details on how to provide this object.
-The default form widget for this field is a
-:class:`~django.forms.widgets.FileInput`.
+The default form widget for this field is a :class:`~django.forms.FileInput`.
Using a :class:`FileField` or an :class:`ImageField` (see below) in a model
takes a few steps:
@@ -590,7 +589,7 @@ topic guide.
saved.
The uploaded file's relative URL can be obtained using the
-:attr:`~django.db.models.fields.FileField.url` attribute. Internally,
+:attr:`~django.db.models.FileField.url` attribute. Internally,
this calls the :meth:`~django.core.files.storage.Storage.url` method of the
underlying :class:`~django.core.files.storage.Storage` class.
2  docs/ref/models/instances.txt
View
@@ -659,7 +659,7 @@ For every :class:`~django.db.models.DateField` and
<django.db.models.Field.null>`, the object will have ``get_next_by_FOO()`` and
``get_previous_by_FOO()`` methods, where ``FOO`` is the name of the field. This
returns the next and previous object with respect to the date field, raising
-a :exc:`~django.db.DoesNotExist` exception when appropriate.
+a :exc:`~django.core.exceptions.DoesNotExist` exception when appropriate.
Both methods accept optional keyword arguments, which should be in the format
described in :ref:`Field lookups <field-lookups>`.
14 docs/ref/models/querysets.txt
View
@@ -1112,9 +1112,9 @@ one, doing so will result in an error.
.. note::
- When calling :meth:`~Model.save()` for instances with deferred fields,
- only the loaded fields will be saved. See :meth:`~Model.save()` for more
- details.
+ When calling :meth:`~django.db.models.Model.save()` for instances with
+ deferred fields, only the loaded fields will be saved. See
+ :meth:`~django.db.models.Model.save()` for more details.
only
@@ -1164,9 +1164,9 @@ using :meth:`select_related` is an error as well.
.. note::
- When calling :meth:`~Model.save()` for instances with deferred fields,
- only the loaded fields will be saved. See :meth:`~Model.save()` for more
- details.
+ When calling :meth:`~django.db.models.Model.save()` for instances with
+ deferred fields, only the loaded fields will be saved. See
+ :meth:`~django.db.models.Model.save()` for more details.
using
~~~~~
@@ -1248,7 +1248,7 @@ the format described in `Field lookups`_.
``get()`` raises :exc:`~django.core.exceptions.MultipleObjectsReturned` if more
than one object was found. The
-:exc:`~django.core.excpetions.MultipleObjectsReturned` exception is an
+:exc:`~django.core.exceptions.MultipleObjectsReturned` exception is an
attribute of the model class.
``get()`` raises a :exc:`~django.core.exceptions.DoesNotExist` exception if an
28 docs/ref/signals.txt
View
@@ -212,24 +212,24 @@ m2m_changed
.. data:: django.db.models.signals.m2m_changed
:module:
-Sent when a :class:`ManyToManyField` is changed on a model instance.
-Strictly speaking, this is not a model signal since it is sent by the
-:class:`ManyToManyField`, but since it complements the
+Sent when a :class:`~django.db.models.ManyToManyField` is changed on a model
+instance. Strictly speaking, this is not a model signal since it is sent by the
+:class:`~django.db.models.ManyToManyField`, but since it complements the
:data:`pre_save`/:data:`post_save` and :data:`pre_delete`/:data:`post_delete`
when it comes to tracking changes to models, it is included here.
Arguments sent with this signal:
``sender``
- The intermediate model class describing the :class:`ManyToManyField`.
- This class is automatically created when a many-to-many field is
- defined; you can access it using the ``through`` attribute on the
- many-to-many field.
+ The intermediate model class describing the
+ :class:`~django.db.models.ManyToManyField`. This class is automatically
+ created when a many-to-many field is defined; you can access it using the
+ ``through`` attribute on the many-to-many field.
``instance``
The instance whose many-to-many relation is updated. This can be an
- instance of the ``sender``, or of the class the :class:`ManyToManyField`
- is related to.
+ instance of the ``sender``, or of the class the
+ :class:`~django.db.models.ManyToManyField` is related to.
``action``
A string indicating the type of update that is done on the relation.
@@ -303,8 +303,9 @@ Argument Value
``action`` ``"pre_add"`` (followed by a separate signal with ``"post_add"``)
-``reverse`` ``False`` (``Pizza`` contains the :class:`ManyToManyField`,
- so this call modifies the forward relation)
+``reverse`` ``False`` (``Pizza`` contains the
+ :class:`~django.db.models.ManyToManyField`, so this call
+ modifies the forward relation)
``model`` ``Topping`` (the class of the objects added to the
``Pizza``)
@@ -329,8 +330,9 @@ Argument Value
``action`` ``"pre_remove"`` (followed by a separate signal with ``"post_remove"``)
-``reverse`` ``True`` (``Pizza`` contains the :class:`ManyToManyField`,
- so this call modifies the reverse relation)
+``reverse`` ``True`` (``Pizza`` contains the
+ :class:`~django.db.models.ManyToManyField`, so this call
+ modifies the reverse relation)
``model`` ``Pizza`` (the class of the objects removed from the
``Topping``)
2  docs/ref/templates/builtins.txt
View
@@ -864,7 +864,7 @@ an attribute "description," you could use::
{% regroup cities by country.description as country_list %}
Or, if ``country`` is a field with ``choices``, it will have a
-:meth:`^django.db.models.Model.get_FOO_display` method available as an
+:meth:`~django.db.models.Model.get_FOO_display` method available as an
attribute, allowing you to group on the display string rather than the
``choices`` key::
4 docs/ref/utils.txt
View
@@ -145,8 +145,8 @@ results. Instead do::
The functions defined in this module share the following properties:
-- They raise :exc:`ValueError` if their input is well formatted but isn't a
- valid date or time.
+- They raise :exc:`~exceptions.ValueError` if their input is well formatted but
+ isn't a valid date or time.
- They return ``None`` if it isn't well formatted at all.
- They accept up to picosecond resolution in input, but they truncate it to
microseconds, since that's what Python supports.
11 docs/releases/1.0-porting-guide.txt
View
@@ -439,9 +439,10 @@ Settings
Better exceptions
~~~~~~~~~~~~~~~~~
-The old :exc:`EnvironmentError` has split into an :exc:`ImportError` when
-Django fails to find the settings module and a :exc:`RuntimeError` when you try
-to reconfigure settings after having already used them
+The old :exc:`~exceptions.EnvironmentError` has split into an
+:exc:`~exceptions.ImportError` when Django fails to find the settings module
+and a :exc:`~exceptions.RuntimeError` when you try to reconfigure settings
+after having already used them.
:setting:`LOGIN_URL` has moved
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -476,8 +477,8 @@ Smaller model changes
Different exception from ``get()``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Managers now return a :exc:`MultipleObjectsReturned` exception
-instead of :exc:`AssertionError`:
+Managers now return a :exc:`~django.core.exceptions.MultipleObjectsReturned`
+exception instead of :exc:`~exceptions.AssertionError`:
Old (0.96)::
2  docs/releases/1.1.txt
View
@@ -132,7 +132,7 @@ public methods.
Fixed the ``join`` filter's escaping behavior
---------------------------------------------
-The :ttag:`join` filter no longer escapes the literal value that is
+The :tfilter:`join` filter no longer escapes the literal value that is
passed in for the connector.
This is backwards incompatible for the special situation of the literal string
2  docs/releases/1.3-alpha-1.txt
View
@@ -156,7 +156,7 @@ requests. These include:
requests in tests.
* A new test assertion --
- :meth:`~django.test.client.Client.assertNumQueries` -- making it
+ :meth:`~django.test.TestCase.assertNumQueries` -- making it
easier to test the database activity associated with a view.
4 docs/releases/1.4-alpha-1.txt
View
@@ -357,8 +357,8 @@ Extended IPv6 support
The previously added support for IPv6 addresses when using the runserver
management command in Django 1.3 has now been further extended by adding
-a :class:`~django.db.models.fields.GenericIPAddressField` model field,
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
+a :class:`~django.db.models.GenericIPAddressField` model field,
+a :class:`~django.forms.GenericIPAddressField` form field and
the validators :data:`~django.core.validators.validate_ipv46_address` and
:data:`~django.core.validators.validate_ipv6_address`
4 docs/releases/1.4-beta-1.txt
View
@@ -395,8 +395,8 @@ Extended IPv6 support
The previously added support for IPv6 addresses when using the runserver
management command in Django 1.3 has now been further extended by adding
-a :class:`~django.db.models.fields.GenericIPAddressField` model field,
-a :class:`~django.forms.fields.GenericIPAddressField` form field and
+a :class:`~django.db.models.GenericIPAddressField` model field,
+a :class:`~django.forms.GenericIPAddressField` form field and
the validators :data:`~django.core.validators.validate_ipv46_address` and
:data:`~django.core.validators.validate_ipv6_address`
10 docs/releases/1.4.txt
View
@@ -526,8 +526,8 @@ Extended IPv6 support
~~~~~~~~~~~~~~~~~~~~~
Django 1.4 can now better handle IPv6 addresses with the new
-:class:`~django.db.models.fields.GenericIPAddressField` model field,
-:class:`~django.forms.fields.GenericIPAddressField` form field and
+:class:`~django.db.models.GenericIPAddressField` model field,
+:class:`~django.forms.GenericIPAddressField` form field and
the validators :data:`~django.core.validators.validate_ipv46_address` and
:data:`~django.core.validators.validate_ipv6_address`.
@@ -890,7 +890,7 @@ object, Django raises an exception.
The MySQL backend historically has raised :class:`MySQLdb.OperationalError`
when a query triggered an exception. We've fixed this bug, and we now raise
-:class:`django.db.utils.DatabaseError` instead. If you were testing for
+:exc:`django.db.DatabaseError` instead. If you were testing for
:class:`MySQLdb.OperationalError`, you'll need to update your ``except``
clauses.
@@ -1092,8 +1092,8 @@ wild, because they would confuse browsers too.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's now possible to check whether a template was used within a block of
-code with :meth:`~django.test.test.TestCase.assertTemplateUsed` and
-:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they
+code with :meth:`~django.test.TestCase.assertTemplateUsed` and
+:meth:`~django.test.TestCase.assertTemplateNotUsed`. And they
can be used as a context manager::
with self.assertTemplateUsed('index.html'):
15 docs/releases/1.5-alpha-1.txt
View
@@ -391,12 +391,12 @@ System version of :mod:`simplejson` no longer used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As explained below, Django 1.5 deprecates
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
module. In theory, this change is harmless. Unfortunately, because of
incompatibilities between versions of :mod:`simplejson`, it may trigger errors
in some circumstances.
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
This module was actually:
- A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -546,8 +546,9 @@ Miscellaneous
* :class:`django.forms.ModelMultipleChoiceField` now returns an empty
``QuerySet`` as the empty value instead of an empty list.
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
- instead of :exc:`ValueError` for non-integer inputs.
+* :func:`~django.utils.http.int_to_base36` properly raises a
+ :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
+ non-integer inputs.
* The ``slugify`` template filter is now available as a standard python
function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -584,8 +585,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
the user profile model, should not be used any longer.
-Streaming behavior of :class:`HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Streaming behavior of :class:`~django.http.HttpResponse`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.5 deprecates the ability to stream a response by passing an iterator
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
Since Django 1.5 drops support for Python 2.5, we can now rely on the
:mod:`json` module being available in Python's standard library, so we've
removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
-instead :mod:`django.utils.simplejson`.
+instead of ``django.utils.simplejson``.
Unfortunately, this change might have unwanted side-effects, because of
incompatibilities between versions of :mod:`simplejson` -- see the backwards-
15 docs/releases/1.5-beta-1.txt
View
@@ -416,12 +416,12 @@ System version of :mod:`simplejson` no longer used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:ref:`As explained below <simplejson-deprecation-beta-1>`, Django 1.5 deprecates
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
module. In theory, this change is harmless. Unfortunately, because of
incompatibilities between versions of :mod:`simplejson`, it may trigger errors
in some circumstances.
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
This module was actually:
- A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -585,8 +585,9 @@ Miscellaneous
* :class:`django.forms.ModelMultipleChoiceField` now returns an empty
``QuerySet`` as the empty value instead of an empty list.
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
- instead of :exc:`ValueError` for non-integer inputs.
+* :func:`~django.utils.http.int_to_base36` properly raises a
+ :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
+ non-integer inputs.
* The ``slugify`` template filter is now available as a standard python
function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -636,8 +637,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
the user profile model, should not be used any longer.
-Streaming behavior of :class:`HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Streaming behavior of :class:`~django.http.HttpResponse`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.5 deprecates the ability to stream a response by passing an iterator
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
Since Django 1.5 drops support for Python 2.5, we can now rely on the
:mod:`json` module being available in Python's standard library, so we've
removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
-instead :mod:`django.utils.simplejson`.
+instead of ``django.utils.simplejson``.
Unfortunately, this change might have unwanted side-effects, because of
incompatibilities between versions of :mod:`simplejson` -- see the
15 docs/releases/1.5.txt
View
@@ -429,12 +429,12 @@ System version of :mod:`simplejson` no longer used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:ref:`As explained below <simplejson-deprecation>`, Django 1.5 deprecates
-:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
+``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
module. In theory, this change is harmless. Unfortunately, because of
incompatibilities between versions of :mod:`simplejson`, it may trigger errors
in some circumstances.
-JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
+JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
This module was actually:
- A system version of :mod:`simplejson`, if one was available (ie. ``import
@@ -598,8 +598,9 @@ Miscellaneous
* :class:`django.forms.ModelMultipleChoiceField` now returns an empty
``QuerySet`` as the empty value instead of an empty list.
-* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
- instead of :exc:`ValueError` for non-integer inputs.
+* :func:`~django.utils.http.int_to_base36` properly raises a
+ :exc:`~exceptions.TypeError` instead of :exc:`~exceptions.ValueError` for
+ non-integer inputs.
* The ``slugify`` template filter is now available as a standard python
function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
@@ -668,8 +669,8 @@ the :setting:`AUTH_PROFILE_MODULE` setting, and the
:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
the user profile model, should not be used any longer.
-Streaming behavior of :class:`HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Streaming behavior of :class:`~django.http.HttpResponse`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.5 deprecates the ability to stream a response by passing an iterator
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
Since Django 1.5 drops support for Python 2.5, we can now rely on the
:mod:`json` module being available in Python's standard library, so we've
removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
-instead :mod:`django.utils.simplejson`.
+instead of ``django.utils.simplejson``.
Unfortunately, this change might have unwanted side-effects, because of
incompatibilities between versions of :mod:`simplejson` -- see the
4 docs/topics/auth.txt
View
@@ -284,7 +284,7 @@ Manager functions
.. versionchanged:: 1.4
The ``email`` parameter was made optional. The username
parameter is now checked for emptiness and raises a
- :exc:`ValueError` in case of a negative result.
+ :exc:`~exceptions.ValueError` in case of a negative result.
Creates, saves and returns a :class:`~django.contrib.auth.models.User`.
@@ -558,7 +558,7 @@ Anonymous users
:meth:`~django.contrib.auth.models.User.delete()`,
:meth:`~django.contrib.auth.models.User.set_groups()` and
:meth:`~django.contrib.auth.models.User.set_permissions()` raise
- :exc:`NotImplementedError`.
+ :exc:`~exceptions.NotImplementedError`.
In practice, you probably won't need to use
:class:`~django.contrib.auth.models.AnonymousUser` objects on your own, but
4 docs/topics/db/queries.txt
View
@@ -327,8 +327,8 @@ a primary key of 1, Django will raise ``Entry.DoesNotExist``.
Similarly, Django will complain if more than one item matches the
:meth:`~django.db.models.query.QuerySet.get` query. In this case, it will raise
-``MultipleObjectsReturned``, which again is an attribute of the model class
-itself.
+:exc:`~django.core.exceptions.MultipleObjectsReturned`, which again is an
+attribute of the model class itself.
Other QuerySet methods
5 docs/topics/i18n/timezones.txt
View
@@ -456,8 +456,9 @@ zone support.
Fixtures generated with ``USE_TZ = False``, or before Django 1.4, use the
"naive" format. If your project contains such fixtures, after you enable time
-zone support, you'll see :exc:`RuntimeWarning`\ s when you load them. To get
-rid of the warnings, you must convert your fixtures to the "aware" format.
+zone support, you'll see :exc:`~exceptions.RuntimeWarning`\ s when you load
+them. To get rid of the warnings, you must convert your fixtures to the "aware"
+format.
You can regenerate fixtures with :djadmin:`loaddata` then :djadmin:`dumpdata`.
Or, if they're small enough, you can simply edit them to add the UTC offset
2  docs/topics/i18n/translation.txt
View
@@ -928,7 +928,7 @@ function. Example::
:func:`~django.conf.urls.i18n.i18n_patterns` is only allowed in your root
URLconf. Using it within an included URLconf will throw an
- :exc:`ImproperlyConfigured` exception.
+ :exc:`~django.core.exceptions.ImproperlyConfigured` exception.
.. warning::
4 docs/topics/python3.txt
View
@@ -343,7 +343,7 @@ meaning of ``str`` changed. To test these types, use the following idioms::
isinstance(myvalue, bytes) # replacement for str
Python ≥ 2.6 provides ``bytes`` as an alias for ``str``, so you don't need
-:attr:`six.binary_type`.
+:data:`six.binary_type`.
``long``
~~~~~~~~
@@ -356,7 +356,7 @@ The ``long`` type no longer exists in Python 3. ``1L`` is a syntax error. Use
``xrange``
~~~~~~~~~~
-Import :func:`six.moves.xrange` wherever you use ``xrange``.
+Import ``six.moves.xrange`` wherever you use ``xrange``.
Moved modules
~~~~~~~~~~~~~
6 docs/topics/security.txt
View
@@ -38,7 +38,7 @@ in unauthorized JavaScript execution, depending on how the browser renders
imperfect HTML.
It is also important to be particularly careful when using ``is_safe`` with
-custom template tags, the :ttag:`safe` template tag, :mod:`mark_safe
+custom template tags, the :tfilter:`safe` template tag, :mod:`mark_safe
<django.utils.safestring>`, and when autoescape is turned off.
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
form. The malicious user would have to know the nonce, which is user specific
(using a cookie).
-When deployed with :ref:`HTTPS <security-recommendation-ssl>`,
-``CsrfViewMiddleware`` will check that the HTTP referer header is set to a
+When deployed with :ref:`HTTPS <security-recommendation-ssl>`,
+``CsrfViewMiddleware`` will check that the HTTP referer header is set to a
URL on the same origin (including subdomain and port). Because HTTPS
provides additional security, it is imperative to ensure connections use HTTPS
where it is available by forwarding insecure connection requests and using
2  docs/topics/serialization.txt
View
@@ -193,7 +193,7 @@ This strategy works well for most objects, but it can cause difficulty in some
circumstances.
Consider the case of a list of objects that have a foreign key referencing
-:class:`~django.contrib.conttenttypes.models.ContentType`. If you're going to
+:class:`~django.contrib.contenttypes.models.ContentType`. If you're going to
serialize an object that refers to a content type, then you need to have a way
to refer to that content type to begin with. Since ``ContentType`` objects are
automatically created by Django during the database synchronization process,
2  docs/topics/signals.txt
View
@@ -30,7 +30,7 @@ notifications:
* :data:`django.db.models.signals.m2m_changed`
- Sent when a :class:`ManyToManyField` on a model is changed.
+ Sent when a :class:`~django.db.models.ManyToManyField` on a model is changed.
* :data:`django.core.signals.request_started` &
:data:`django.core.signals.request_finished`
2  docs/topics/testing/index.txt
View
@@ -38,7 +38,7 @@ frameworks are:
* **Unit tests** -- tests that are expressed as methods on a Python class
that subclasses :class:`unittest.TestCase` or Django's customized
- :class:`TestCase`. For example::
+ :class:`~django.test.TestCase`. For example::
import unittest
Please sign in to comment.
Something went wrong with that request. Please try again.