diff --git a/docs/conf.py b/docs/conf.py
index 3d88ffedde..5ea5a06eba 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -26,7 +26,7 @@ needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = ["djangodocs"]
+extensions = ["djangodocs", "sphinx.ext.intersphinx"]
# Add any paths that contain templates here, relative to this directory.
# templates_path = []
@@ -92,6 +92,16 @@ pygments_style = 'trac'
# Note: exclude_dirnames is new in Sphinx 0.5
exclude_dirnames = ['.svn']
+# Links to Python's docs should reference the most recent version of the 2.x
+# branch, which is located at this URL.
+intersphinx_mapping = {
+ 'python': ('http://docs.python.org/2.7', None),
+ 'sphinx': ('http://sphinx.pocoo.org/', None),
+}
+
+# Python's docs don't change every week.
+intersphinx_cache_limit = 90 # days
+
# -- Options for HTML output ---------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
diff --git a/docs/faq/install.txt b/docs/faq/install.txt
index f1e865a966..06c7522aca 100644
--- a/docs/faq/install.txt
+++ b/docs/faq/install.txt
@@ -22,10 +22,10 @@ usage.
For a development environment -- if you just want to experiment with Django --
you don't need to have a separate Web server installed; Django comes with its
-own lightweight development server. For a production environment, Django
-follows the WSGI_ spec, which means it can run on a variety of server
-platforms. See :doc:`Deploying Django ` for some
-popular alternatives. Also, the `server arrangements wiki page`_ contains
+own lightweight development server. For a production environment, Django follows
+the WSGI spec, :pep:`3333`, which means it can run on a variety of server
+platforms. See :doc:`Deploying Django ` for some
+popular alternatives. Also, the `server arrangements wiki page`_ contains
details for several deployment strategies.
If you want to use Django with a database, which is probably the case, you'll
@@ -33,7 +33,6 @@ also need a database engine. PostgreSQL_ is recommended, because we're
PostgreSQL fans, and MySQL_, `SQLite 3`_, and Oracle_ are also supported.
.. _Python: http://www.python.org/
-.. _WSGI: http://www.python.org/dev/peps/pep-0333/
.. _server arrangements wiki page: http://code.djangoproject.com/wiki/ServerArrangements
.. _PostgreSQL: http://www.postgresql.org/
.. _MySQL: http://www.mysql.com/
@@ -48,7 +47,7 @@ version of Python from 2.5 through 2.7, inclusive. However, newer versions of
Python are often faster, have more features, and are better supported. If you
use a newer version of Python you will also have access to some APIs that
aren't available under older versions of Python. For example, since Python 2.6,
-you can use the advanced string formatting described in `PEP 3101`_.
+you can use the advanced string formatting described in :pep:`3101`.
Third-party applications for use with Django are, of course, free to set their
own version requirements.
@@ -63,8 +62,6 @@ improvements and optimizations to the Python language since version 2.5, and
will help ease the process of dropping support for older Python versions on
the road to Python 3.
-.. _PEP 3101: http://www.python.org/dev/peps/pep-3101/
-
Can I use Django with Python 2.4?
---------------------------------
diff --git a/docs/glossary.txt b/docs/glossary.txt
index 2761c794f3..9f8eb8d41f 100644
--- a/docs/glossary.txt
+++ b/docs/glossary.txt
@@ -43,19 +43,10 @@ Glossary
property
Also known as "managed attributes", and a feature of Python since
- version 2.2. From `the property documentation`__:
+ version 2.2. This is a neat way to implement attributes whose usage
+ resembles attribute access, but whose implementation uses method calls.
- Properties are a neat way to implement attributes whose usage
- resembles attribute access, but whose implementation uses method
- calls. [...] You
- could only do this by overriding ``__getattr__`` and
- ``__setattr__``; but overriding ``__setattr__`` slows down all
- attribute assignments considerably, and overriding ``__getattr__``
- is always a bit tricky to get right. Properties let you do this
- painlessly, without having to override ``__getattr__`` or
- ``__setattr__``.
-
- __ http://www.python.org/download/releases/2.2/descrintro/#property
+ See :func:`property`.
queryset
An object representing some set of rows to be fetched from the database.
diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt
index 421b1ecf73..170fa91696 100644
--- a/docs/howto/custom-template-tags.txt
+++ b/docs/howto/custom-template-tags.txt
@@ -335,15 +335,13 @@ responsible for returning a ``Node`` instance based on the contents of the tag.
For example, let's write a template tag, ``{% current_time %}``, that displays
the current date/time, formatted according to a parameter given in the tag, in
-`strftime syntax`_. It's a good idea to decide the tag syntax before anything
-else. In our case, let's say the tag should be used like this:
+:func:`~time.strftime` syntax. It's a good idea to decide the tag syntax before
+anything else. In our case, let's say the tag should be used like this:
.. code-block:: html+django
The time is {% current_time "%Y-%m-%d %I:%M %p" %}.
-.. _`strftime syntax`: http://docs.python.org/library/time.html#time.strftime
-
The parser for this function should grab the parameter and create a ``Node``
object::
diff --git a/docs/howto/deployment/modwsgi.txt b/docs/howto/deployment/modwsgi.txt
index de3a5b63aa..d268334e3a 100644
--- a/docs/howto/deployment/modwsgi.txt
+++ b/docs/howto/deployment/modwsgi.txt
@@ -9,10 +9,8 @@ Django into production.
.. _mod_wsgi: http://code.google.com/p/modwsgi/
mod_wsgi is an Apache module which can be used to host any Python application
-which supports the `Python WSGI interface`_, including Django. Django will work
-with any version of Apache which supports mod_wsgi.
-
-.. _python wsgi interface: http://www.python.org/dev/peps/pep-0333/
+which supports the Python WSGI interface described in :pep:`3333`, including
+Django. Django will work with any version of Apache which supports mod_wsgi.
The `official mod_wsgi documentation`_ is fantastic; it's your source for all
the details about how to use mod_wsgi. You'll probably want to start with the
diff --git a/docs/howto/outputting-csv.txt b/docs/howto/outputting-csv.txt
index 46e111d8af..3e3d7d47ff 100644
--- a/docs/howto/outputting-csv.txt
+++ b/docs/howto/outputting-csv.txt
@@ -3,17 +3,15 @@ Outputting CSV with Django
==========================
This document explains how to output CSV (Comma Separated Values) dynamically
-using Django views. To do this, you can either use the `Python CSV library`_ or
-the Django template system.
-
-.. _Python CSV library: http://docs.python.org/library/csv.html
+using Django views. To do this, you can either use the Python CSV library or the
+Django template system.
Using the Python CSV library
============================
-Python comes with a CSV library, ``csv``. The key to using it with Django is
-that the ``csv`` module's CSV-creation capability acts on file-like objects, and
-Django's :class:`~django.http.HttpResponse` objects are file-like objects.
+Python comes with a CSV library, :mod:`csv`. The key to using it with Django is
+that the :mod:`csv` module's CSV-creation capability acts on file-like objects,
+and Django's :class:`~django.http.HttpResponse` objects are file-like objects.
Here's an example::
@@ -34,7 +32,7 @@ Here's an example::
The code and comments should be self-explanatory, but a few things deserve a
mention:
- * The response gets a special MIME type, ``text/csv``. This tells
+ * The response gets a special MIME type, :mimetype:`text/csv`. This tells
browsers that the document is a CSV file, rather than an HTML file. If
you leave this off, browsers will probably interpret the output as HTML,
which will result in ugly, scary gobbledygook in the browser window.
@@ -59,7 +57,7 @@ mention:
Handling Unicode
~~~~~~~~~~~~~~~~
-Python's ``csv`` module does not support Unicode input. Since Django uses
+Python's :mod:`csv` module does not support Unicode input. Since Django uses
Unicode internally this means strings read from sources such as
:class:`~django.http.HttpRequest` are potentially problematic. There are a few
options for handling this:
@@ -70,20 +68,18 @@ options for handling this:
section`_.
* Use the `python-unicodecsv module`_, which aims to be a drop-in
- replacement for ``csv`` that gracefully handles Unicode.
+ replacement for :mod:`csv` that gracefully handles Unicode.
-For more information, see the Python `CSV File Reading and Writing`_
-documentation.
+For more information, see the Python documentation of the :mod:`csv` module.
.. _`csv module's examples section`: http://docs.python.org/library/csv.html#examples
.. _`python-unicodecsv module`: https://github.com/jdunck/python-unicodecsv
-.. _`CSV File Reading and Writing`: http://docs.python.org/library/csv.html
Using the template system
=========================
Alternatively, you can use the :doc:`Django template system `
-to generate CSV. This is lower-level than using the convenient Python ``csv``
+to generate CSV. This is lower-level than using the convenient Python :mod:`csv`
module, but the solution is presented here for completeness.
The idea here is to pass a list of items to your template, and have the
diff --git a/docs/howto/outputting-pdf.txt b/docs/howto/outputting-pdf.txt
index 67950d03f2..bb71fabab6 100644
--- a/docs/howto/outputting-pdf.txt
+++ b/docs/howto/outputting-pdf.txt
@@ -63,10 +63,11 @@ Here's a "Hello World" example::
The code and comments should be self-explanatory, but a few things deserve a
mention:
- * The response gets a special MIME type, ``application/pdf``. This tells
- browsers that the document is a PDF file, rather than an HTML file. If
- you leave this off, browsers will probably interpret the output as HTML,
- which would result in ugly, scary gobbledygook in the browser window.
+ * The response gets a special MIME type, :mimetype:`application/pdf`. This
+ tells browsers that the document is a PDF file, rather than an HTML file.
+ If you leave this off, browsers will probably interpret the output as
+ HTML, which would result in ugly, scary gobbledygook in the browser
+ window.
* The response gets an additional ``Content-Disposition`` header, which
contains the name of the PDF file. This filename is arbitrary: Call it
@@ -97,9 +98,9 @@ Complex PDFs
============
If you're creating a complex PDF document with ReportLab, consider using the
-cStringIO_ library as a temporary holding place for your PDF file. The cStringIO
+:mod:`cStringIO` library as a temporary holding place for your PDF file. This
library provides a file-like object interface that is particularly efficient.
-Here's the above "Hello World" example rewritten to use ``cStringIO``::
+Here's the above "Hello World" example rewritten to use :mod:`cStringIO`::
# Fall back to StringIO in environments where cStringIO is not available
try:
@@ -133,8 +134,6 @@ Here's the above "Hello World" example rewritten to use ``cStringIO``::
response.write(pdf)
return response
-.. _cStringIO: http://docs.python.org/library/stringio.html#module-cStringIO
-
Further resources
=================
diff --git a/docs/internals/contributing/writing-code/branch-policy.txt b/docs/internals/contributing/writing-code/branch-policy.txt
index 8bda15a3d4..ec4db3e532 100644
--- a/docs/internals/contributing/writing-code/branch-policy.txt
+++ b/docs/internals/contributing/writing-code/branch-policy.txt
@@ -146,14 +146,14 @@ Alternatively, you can use a symlink called ``django`` that points to the
location of the branch's ``django`` package. If you want to switch back, just
change the symlink to point to the old code.
-A third option is to use a `path file`_ (``.pth``). First, make sure
-there are no files, directories or symlinks named ``django`` in your
-``site-packages`` directory. Then create a text file named ``django.pth`` and
-save it to your ``site-packages`` directory. That file should contain a path to
-your copy of Django on a single line and optional comments. Here is an example
-that points to multiple branches. Just uncomment the line for the branch you
-want to use ('Trunk' in this example) and make sure all other lines are
-commented::
+A third option is to use a path file (``.pth``). This is a feature of
+the :mod:`site` module. First, make sure there are no files, directories or
+symlinks named ``django`` in your ``site-packages`` directory. Then create a
+text file named ``django.pth`` and save it to your ``site-packages`` directory.
+That file should contain a path to your copy of Django on a single line and
+optional comments. Here is an example that points to multiple branches. Just
+uncomment the line for the branch you want to use ('trunk' in this example) and
+make sure all other lines are commented::
# Trunk is a svn checkout of:
# http://code.djangoproject.com/svn/django/trunk/
@@ -168,5 +168,4 @@ commented::
# On windows a path may look like this:
# C:/path/to/
-.. _path file: http://docs.python.org/library/site.html
.. _django-developers: http://groups.google.com/group/django-developers
diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index 1394c1e6a0..6c3c1b3a25 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -10,7 +10,7 @@ Python style
* Unless otherwise specified, follow :pep:`8`.
You could use a tool like `pep8`_ to check for some problems in this
- area, but remember that PEP 8 is only a guide, so respect the style of
+ area, but remember that :pep:`8` is only a guide, so respect the style of
the surrounding code as a primary goal.
* Use four spaces for indentation.
diff --git a/docs/internals/contributing/writing-documentation.txt b/docs/internals/contributing/writing-documentation.txt
index cf8e6b41a2..2d08dba389 100644
--- a/docs/internals/contributing/writing-documentation.txt
+++ b/docs/internals/contributing/writing-documentation.txt
@@ -43,12 +43,10 @@ __ http://pygments.org
Then, building the HTML is easy; just ``make html`` (or ``make.bat html`` on
Windows) from the ``docs`` directory.
-To get started contributing, you'll want to read the `reStructuredText
-Primer`__. After that, you'll want to read about the `Sphinx-specific markup`__
-that's used to manage metadata, indexing, and cross-references.
-
-__ http://sphinx.pocoo.org/rest.html
-__ http://sphinx.pocoo.org/markup/
+To get started contributing, you'll want to read the :ref:`reStructuredText
+Primer `. After that, you'll want to read about the
+:ref:`Sphinx-specific markup ` that's used to manage
+metadata, indexing, and cross-references.
Commonly used terms
-------------------
@@ -113,6 +111,9 @@ documentation:
greatly helps readers. There's basically no limit to the amount of
useful markup you can add.
+ * Use :mod:`~sphinx.ext.intersphinx` to reference Python's and Sphinx'
+ documentation.
+
Django-specific markup
----------------------
@@ -220,12 +221,9 @@ example:
You can find both in the :doc:`settings reference document
`.
- We use the Sphinx doc_ cross reference element when we want to link to
- another document as a whole and the ref_ element when we want to link to
- an arbitrary location in a document.
-
-.. _doc: http://sphinx.pocoo.org/markup/inline.html#role-doc
-.. _ref: http://sphinx.pocoo.org/markup/inline.html#role-ref
+ We use the Sphinx :rst:role:`doc` cross reference element when we want to
+ link to another document as a whole and the :rst:role:`ref` element when
+ we want to link to an arbitrary location in a document.
* Next, notice how the settings are annotated:
diff --git a/docs/intro/tutorial03.txt b/docs/intro/tutorial03.txt
index 6cae8de763..c607147751 100644
--- a/docs/intro/tutorial03.txt
+++ b/docs/intro/tutorial03.txt
@@ -122,14 +122,13 @@ the URLconf will look for ``myapp/``. In a request to
``http://www.example.com/myapp/?page=3``, the URLconf will look for ``myapp/``.
If you need help with regular expressions, see `Wikipedia's entry`_ and the
-`Python documentation`_. Also, the O'Reilly book "Mastering Regular Expressions"
-by Jeffrey Friedl is fantastic.
+documentation of the :mod:`re` module. Also, the O'Reilly book "Mastering
+Regular Expressions" by Jeffrey Friedl is fantastic.
Finally, a performance note: these regular expressions are compiled the first
time the URLconf module is loaded. They're super fast.
.. _Wikipedia's entry: http://en.wikipedia.org/wiki/Regular_expression
-.. _Python documentation: http://docs.python.org/library/re.html
Write your first view
=====================
diff --git a/docs/misc/design-philosophies.txt b/docs/misc/design-philosophies.txt
index 631097ae2b..e6aea334b0 100644
--- a/docs/misc/design-philosophies.txt
+++ b/docs/misc/design-philosophies.txt
@@ -73,13 +73,11 @@ as possible.
Explicit is better than implicit
--------------------------------
-This, a `core Python principle`_, means Django shouldn't do too much "magic."
-Magic shouldn't happen unless there's a really good reason for it. Magic is
-worth using only if it creates a huge convenience unattainable in other ways,
-and it isn't implemented in a way that confuses developers who are trying to
-learn how to use the feature.
-
-.. _`core Python principle`: http://www.python.org/dev/peps/pep-0020/
+This is a core Python principle listed in :pep:`20`, and it means Django
+shouldn't do too much "magic." Magic shouldn't happen unless there's a really
+good reason for it. Magic is worth using only if it creates a huge convenience
+unattainable in other ways, and it isn't implemented in a way that confuses
+developers who are trying to learn how to use the feature.
.. _consistency:
diff --git a/docs/ref/class-based-views.txt b/docs/ref/class-based-views.txt
index 8f77d5722f..3ccc06cf69 100644
--- a/docs/ref/class-based-views.txt
+++ b/docs/ref/class-based-views.txt
@@ -586,10 +586,8 @@ YearMixin
.. attribute:: year_format
- The strftime_ format to use when parsing the year. By default, this is
- ``'%Y'``.
-
- .. _strftime: http://docs.python.org/library/time.html#time.strftime
+ The :func:`~time.strftime` format to use when parsing the year.
+ By default, this is ``'%Y'``.
.. attribute:: year
@@ -598,7 +596,7 @@ YearMixin
.. method:: get_year_format()
- Returns the strftime_ format to use when parsing the year. Returns
+ Returns the :func:`~time.strftime` format to use when parsing the year. Returns
:attr:`YearMixin.year_format` by default.
.. method:: get_year()
@@ -621,7 +619,7 @@ MonthMixin
.. attribute:: month_format
- The strftime_ format to use when parsing the month. By default, this is
+ The :func:`~time.strftime` format to use when parsing the month. By default, this is
``'%b'``.
.. attribute:: month
@@ -631,7 +629,7 @@ MonthMixin
.. method:: get_month_format()
- Returns the strftime_ format to use when parsing the month. Returns
+ Returns the :func:`~time.strftime` format to use when parsing the month. Returns
:attr:`MonthMixin.month_format` by default.
.. method:: get_month()
@@ -667,7 +665,7 @@ DayMixin
.. attribute:: day_format
- The strftime_ format to use when parsing the day. By default, this is
+ The :func:`~time.strftime` format to use when parsing the day. By default, this is
``'%d'``.
.. attribute:: day
@@ -677,7 +675,7 @@ DayMixin
.. method:: get_day_format()
- Returns the strftime_ format to use when parsing the day. Returns
+ Returns the :func:`~time.strftime` format to use when parsing the day. Returns
:attr:`DayMixin.day_format` by default.
.. method:: get_day()
@@ -712,7 +710,7 @@ WeekMixin
.. attribute:: week_format
- The strftime_ format to use when parsing the week. By default, this is
+ The :func:`~time.strftime` format to use when parsing the week. By default, this is
``'%U'``.
.. attribute:: week
@@ -722,7 +720,7 @@ WeekMixin
.. method:: get_week_format()
- Returns the strftime_ format to use when parsing the week. Returns
+ Returns the :func:`~time.strftime` format to use when parsing the week. Returns
:attr:`WeekMixin.week_format` by default.
.. method:: get_week()
diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
index dcac4377bb..a6839477e4 100644
--- a/docs/ref/contrib/csrf.txt
+++ b/docs/ref/contrib/csrf.txt
@@ -14,12 +14,12 @@ who visits the malicious site in their browser. A related type of attack,
a site with someone else's credentials, is also covered.
The first defense against CSRF attacks is to ensure that GET requests (and other
-'safe' methods, as defined by `9.1.1 Safe Methods, HTTP 1.1, RFC 2616`_) are
-side-effect free. Requests via 'unsafe' methods, such as POST, PUT and DELETE,
-can then be protected by following the steps below.
+'safe' methods, as defined by 9.1.1 Safe Methods, HTTP 1.1,
+:rfc:`2616#section-9.1.1`) are side-effect free. Requests via 'unsafe' methods,
+such as POST, PUT and DELETE, can then be protected by following the steps
+below.
.. _Cross Site Request Forgeries: http://www.squarefree.com/securitytips/web-developers.html#CSRF
-.. _9.1.1 Safe Methods, HTTP 1.1, RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
.. _using-csrf:
@@ -228,9 +228,9 @@ This ensures that only forms that have originated from your Web site can be used
to POST data back.
It deliberately ignores GET requests (and other requests that are defined as
-'safe' by RFC 2616). These requests ought never to have any potentially
+'safe' by :rfc:`2616`). These requests ought never to have any potentially
dangerous side effects , and so a CSRF attack with a GET request ought to be
-harmless. RFC 2616 defines POST, PUT and DELETE as 'unsafe', and all other
+harmless. :rfc:`2616` defines POST, PUT and DELETE as 'unsafe', and all other
methods are assumed to be unsafe, for maximum protection.
Caching
diff --git a/docs/ref/contrib/gis/install.txt b/docs/ref/contrib/gis/install.txt
index b054277426..f15b55499e 100644
--- a/docs/ref/contrib/gis/install.txt
+++ b/docs/ref/contrib/gis/install.txt
@@ -1235,13 +1235,17 @@ may be executed from the SQL Shell as the ``postgres`` user::
postgres# CREATE DATABASE geodjango OWNER geodjango TEMPLATE template_postgis ENCODING 'utf8';
.. rubric:: Footnotes
-.. [#] The datum shifting files are needed for converting data to and from certain projections.
- For example, the PROJ.4 string for the `Google projection (900913) `_
- requires the ``null`` grid file only included in the extra datum shifting files.
- It is easier to install the shifting files now, then to have debug a problem caused by their absence later.
-.. [#] Specifically, GeoDjango provides support for the `OGR `_ library, a component of GDAL.
+.. [#] The datum shifting files are needed for converting data to and from
+ certain projections.
+ For example, the PROJ.4 string for the `Google projection (900913)
+ `_ requires the
+ ``null`` grid file only included in the extra datum shifting files.
+ It is easier to install the shifting files now, then to have debug a
+ problem caused by their absence later.
+.. [#] Specifically, GeoDjango provides support for the `OGR
+ `_ library, a component of GDAL.
.. [#] See `GDAL ticket #2382 `_.
-.. [#] GeoDjango uses the `find_library `_
- routine from ``ctypes.util`` to locate shared libraries.
+.. [#] GeoDjango uses the :func:`~ctypes.util.find_library` routine from
+ :mod:`ctypes.util` to locate shared libraries.
.. [#] The ``psycopg2`` Windows installers are packaged and maintained by
`Jason Erickson `_.
diff --git a/docs/ref/contrib/syndication.txt b/docs/ref/contrib/syndication.txt
index 9a0aa9b149..398f6ca4cb 100644
--- a/docs/ref/contrib/syndication.txt
+++ b/docs/ref/contrib/syndication.txt
@@ -852,8 +852,9 @@ They share this interface:
All parameters, if given, should be Unicode objects, except:
- * ``pubdate`` should be a `Python datetime object`_.
- * ``enclosure`` should be an instance of ``feedgenerator.Enclosure``.
+ * ``pubdate`` should be a Python :class:`~datetime.datetime` object.
+ * ``enclosure`` should be an instance of
+ :class:`django.utils.feedgenerator.Enclosure`.
* ``categories`` should be a sequence of Unicode objects.
:meth:`.SyndicationFeed.write`
@@ -884,7 +885,6 @@ For example, to create an Atom 1.0 feed and print it to standard output::
.. _django/utils/feedgenerator.py: http://code.djangoproject.com/browser/django/trunk/django/utils/feedgenerator.py
-.. _Python datetime object: http://docs.python.org/library/datetime.html#datetime-objects
.. currentmodule:: django.contrib.syndication
@@ -913,9 +913,9 @@ attributes. Thus, you can subclass the appropriate feed generator class
``SyndicationFeed.add_root_elements(self, handler)``
Callback to add elements inside the root feed element
- (``feed``/``channel``). ``handler`` is an `XMLGenerator`_ from Python's
- built-in SAX library; you'll call methods on it to add to the XML
- document in process.
+ (``feed``/``channel``). ``handler`` is an
+ :class:`~xml.sax.saxutils.XMLGenerator` from Python's built-in SAX library;
+ you'll call methods on it to add to the XML document in process.
``SyndicationFeed.item_attributes(self, item)``
Return a ``dict`` of attributes to add to each item (``item``/``entry``)
@@ -945,5 +945,3 @@ For example, you might start implementing an iTunes RSS feed generator like so::
Obviously there's a lot more work to be done for a complete custom feed class,
but the above example should demonstrate the basic idea.
-
-.. _XMLGenerator: http://docs.python.org/dev/library/xml.sax.utils.html#xml.sax.saxutils.XMLGenerator
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index f2f7b2cd96..c07b61c8ef 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -455,7 +455,7 @@ Example usage::
.. django-admin-option:: --ignore
Use the ``--ignore`` or ``-i`` option to ignore files or directories matching
-the given `glob-style pattern`_. Use multiple times to ignore more.
+the given :mod:`glob`-style pattern. Use multiple times to ignore more.
These patterns are used by default: ``'CVS'``, ``'.*'``, ``'*~'``
@@ -463,8 +463,6 @@ Example usage::
django-admin.py makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
-.. _`glob-style pattern`: http://docs.python.org/library/glob.html
-
.. django-admin-option:: --no-default-ignore
Use the ``--no-default-ignore`` option to disable the default values of
diff --git a/docs/ref/exceptions.txt b/docs/ref/exceptions.txt
index a42bdafb7f..9177cc0feb 100644
--- a/docs/ref/exceptions.txt
+++ b/docs/ref/exceptions.txt
@@ -128,10 +128,8 @@ provided in :mod:`django.db`.
.. exception:: IntegrityError
The Django wrappers for database exceptions behave exactly the same as
-the underlying database exceptions. See `PEP 249 - Python Database API
-Specification v2.0`_ for further information.
-
-.. _`PEP 249 - Python Database API Specification v2.0`: http://www.python.org/dev/peps/pep-0249/
+the underlying database exceptions. See :pep:`249`, the Python Database API
+Specification v2.0, for further information.
.. currentmodule:: django.db.transaction
@@ -147,8 +145,6 @@ Transaction Exceptions
Python Exceptions
=================
-Django raises built-in Python exceptions when appropriate as well. See
-the Python `documentation`_ for further information on the built-in
-exceptions.
-
-.. _`documentation`: http://docs.python.org/lib/module-exceptions.html
+Django raises built-in Python exceptions when appropriate as well. See the
+Python documentation for further information on the
+built-in :mod:`exceptions`.
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
index 11228f4320..be1019c16e 100644
--- a/docs/ref/forms/fields.txt
+++ b/docs/ref/forms/fields.txt
@@ -639,13 +639,11 @@ A field containing either an IPv4 or an IPv6 address.
* Validates that the given value is a valid IP address.
* Error message keys: ``required``, ``invalid``
-The IPv6 address normalization follows `RFC4291 section 2.2`_, including using
-the IPv4 format suggested in paragraph 3 of that section, like
+The IPv6 address normalization follows :rfc:`4291#section-2.2` section 2.2,
+including using the IPv4 format suggested in paragraph 3 of that section, like
``::ffff:192.0.2.0``. For example, ``2001:0::0:01`` would be normalized to
-``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All
-characters are converted to lowercase.
-
-.. _RFC4291 section 2.2: http://tools.ietf.org/html/rfc4291#section-2.2
+``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All characters
+are converted to lowercase.
Takes two optional arguments:
diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt
index a787869c2b..325d808454 100644
--- a/docs/ref/generic-views.txt
+++ b/docs/ref/generic-views.txt
@@ -346,11 +346,11 @@ date in the *future* are not displayed unless you set ``allow_future`` to
**Optional arguments:**
- * ``month_format``: A format string that regulates what format the
- ``month`` parameter uses. This should be in the syntax accepted by
- Python's ``time.strftime``. (See the `strftime docs`_.) It's set to
- ``"%b"`` by default, which is a three-letter month abbreviation. To
- change it to use numbers, use ``"%m"``.
+ * ``month_format``: A format string that regulates what format the ``month``
+ parameter uses. This should be in the syntax accepted by Python's
+ :func:`~time.strftime`. It's set to ``"%b"`` by default, which is a
+ three-letter month abbreviation. To change it to use numbers, use
+ ``"%m"``.
* ``template_name``: The full name of a template to use in rendering the
page. This lets you override the default template name (see below).
@@ -415,8 +415,6 @@ In addition to ``extra_context``, the template's context will be:
is ``'object'`` by default. If ``template_object_name`` is ``'foo'``,
this variable's name will be ``foo_list``.
-.. _strftime docs: http://docs.python.org/library/time.html#time.strftime
-
``django.views.generic.date_based.archive_week``
------------------------------------------------
@@ -516,11 +514,11 @@ you set ``allow_future`` to ``True``.
**Optional arguments:**
- * ``month_format``: A format string that regulates what format the
- ``month`` parameter uses. This should be in the syntax accepted by
- Python's ``time.strftime``. (See the `strftime docs`_.) It's set to
- ``"%b"`` by default, which is a three-letter month abbreviation. To
- change it to use numbers, use ``"%m"``.
+ * ``month_format``: A format string that regulates what format the ``month``
+ parameter uses. This should be in the syntax accepted by Python's
+ :func:`~time.strftime`. It's set to ``"%b"`` by default, which is a
+ three-letter month abbreviation. To change it to use numbers, use
+ ``"%m"``.
* ``day_format``: Like ``month_format``, but for the ``day`` parameter.
It defaults to ``"%d"`` (day of the month as a decimal number, 01-31).
@@ -624,11 +622,11 @@ future, the view will throw a 404 error by default, unless you set
**Optional arguments:**
- * ``month_format``: A format string that regulates what format the
- ``month`` parameter uses. This should be in the syntax accepted by
- Python's ``time.strftime``. (See the `strftime docs`_.) It's set to
- ``"%b"`` by default, which is a three-letter month abbreviation. To
- change it to use numbers, use ``"%m"``.
+ * ``month_format``: A format string that regulates what format the ``month``
+ parameter uses. This should be in the syntax accepted by Python's
+ :func:`~time.strftime`. It's set to ``"%b"`` by default, which is a
+ three-letter month abbreviation. To change it to use numbers, use
+ ``"%m"``.
* ``day_format``: Like ``month_format``, but for the ``day`` parameter.
It defaults to ``"%d"`` (day of the month as a decimal number, 01-31).
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 2538157e33..9a40a67439 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -500,9 +500,9 @@ Has one **required** argument:
setting to determine the value of the :attr:`~django.core.files.File.url`
attribute.
- This path may contain `strftime formatting`_, which will be replaced by the
- date/time of the file upload (so that uploaded files don't fill up the given
- directory).
+ This path may contain :func:`~time.strftime` formatting, which will be
+ replaced by the date/time of the file upload (so that uploaded files don't
+ fill up the given directory).
This may also be a callable, such as a function, which will be called to
obtain the upload path, including the filename. This callable must be able
@@ -560,10 +560,10 @@ takes a few steps:
For example, say your :setting:`MEDIA_ROOT` is set to ``'/home/media'``, and
:attr:`~FileField.upload_to` is set to ``'photos/%Y/%m/%d'``. The ``'%Y/%m/%d'``
-part of :attr:`~FileField.upload_to` is `strftime formatting`_; ``'%Y'`` is the
-four-digit year, ``'%m'`` is the two-digit month and ``'%d'`` is the two-digit
-day. If you upload a file on Jan. 15, 2007, it will be saved in the directory
-``/home/media/photos/2007/01/15``.
+part of :attr:`~FileField.upload_to` is :func:`~time.strftime` formatting;
+``'%Y'`` is the four-digit year, ``'%m'`` is the two-digit month and ``'%d'`` is
+the two-digit day. If you upload a file on Jan. 15, 2007, it will be saved in
+the directory ``/home/media/photos/2007/01/15``.
If you wanted to retrieve the uploaded file's on-disk filename, or the file's
size, you could use the :attr:`~django.core.files.File.name` and
@@ -595,8 +595,6 @@ By default, :class:`FileField` instances are
created as ``varchar(100)`` columns in your database. As with other fields, you
can change the maximum length using the :attr:`~CharField.max_length` argument.
-.. _`strftime formatting`: http://docs.python.org/library/time.html#time.strftime
-
FileField and FieldFile
~~~~~~~~~~~~~~~~~~~~~~~
@@ -711,11 +709,8 @@ The admin represents this as an ```` (a single-line input).
:class:`DecimalField` class. Although they both represent real numbers, they
represent those numbers differently. ``FloatField`` uses Python's ``float``
type internally, while ``DecimalField`` uses Python's ``Decimal`` type. For
- information on the difference between the two, see Python's documentation on
- `Decimal fixed point and floating point arithmetic`_.
-
-.. _Decimal fixed point and floating point arithmetic: http://docs.python.org/library/decimal.html
-
+ information on the difference between the two, see Python's documentation
+ for the :mod:`decimal` module.
``ImageField``
--------------
@@ -777,13 +772,11 @@ An IPv4 or IPv6 address, in string format (e.g. ``192.0.2.30`` or
``2a02:42fe::4``). The admin represents this as an ````
(a single-line input).
-The IPv6 address normalization follows `RFC4291 section 2.2`_, including using
-the IPv4 format suggested in paragraph 3 of that section, like
+The IPv6 address normalization follows :rfc:`4291#section-2.2` section 2.2,
+including using the IPv4 format suggested in paragraph 3 of that section, like
``::ffff:192.0.2.0``. For example, ``2001:0::0:01`` would be normalized to
-``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All
-characters are converted to lowercase.
-
-.. _RFC4291 section 2.2: http://tools.ietf.org/html/rfc4291#section-2.2
+``2001::1``, and ``::ffff:0a0a:0a0a`` to ``::ffff:10.10.10.10``. All characters
+are converted to lowercase.
.. attribute:: GenericIPAddressField.protocol
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index d31e887512..2053788b8d 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -454,7 +454,7 @@ in ``get_absolute_url()`` and have all your other code call that one place.
.. note::
The string you return from ``get_absolute_url()`` **must** contain only
- ASCII characters (required by the URI specfication, `RFC 2396`_) and be
+ ASCII characters (required by the URI specfication, :rfc:`2396`) and be
URL-encoded, if necessary.
Code and templates calling ``get_absolute_url()`` should be able to use the
@@ -463,8 +463,6 @@ in ``get_absolute_url()`` and have all your other code call that one place.
are using unicode strings containing characters outside the ASCII range at
all.
-.. _RFC 2396: http://www.ietf.org/rfc/rfc2396.txt
-
The ``permalink`` decorator
~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index c0aa840b61..b2c521e645 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -81,7 +81,7 @@ You can evaluate a ``QuerySet`` in the following ways:
Pickling QuerySets
------------------
-If you pickle_ a ``QuerySet``, this will force all the results to be loaded
+If you :mod:`pickle` a ``QuerySet``, this will force all the results to be loaded
into memory prior to pickling. Pickling is usually used as a precursor to
caching and when the cached queryset is reloaded, you want the results to
already be present and ready for use (reading from the database can take some
@@ -112,8 +112,6 @@ described here.
Django version N+1. Pickles should not be used as part of a long-term
archival strategy.
-.. _pickle: http://docs.python.org/library/pickle.html
-
.. _queryset-api:
QuerySet API
@@ -1210,20 +1208,18 @@ iterator
.. method:: iterator()
-Evaluates the ``QuerySet`` (by performing the query) and returns an `iterator`_
-over the results. A ``QuerySet`` typically caches its results internally so
-that repeated evaluations do not result in additional queries. In contrast,
-``iterator()`` will read results directly, without doing any caching at the
-``QuerySet`` level (internally, the default iterator calls ``iterator()`` and
-caches the return value). For a ``QuerySet`` which returns a large number of
+Evaluates the ``QuerySet`` (by performing the query) and returns an iterator
+(see :pep:`234`) over the results. A ``QuerySet`` typically caches its results
+internally so that repeated evaluations do not result in additional queries. In
+contrast, ``iterator()`` will read results directly, without doing any caching
+at the ``QuerySet`` level (internally, the default iterator calls ``iterator()``
+and caches the return value). For a ``QuerySet`` which returns a large number of
objects that you only need to access once, this can results in better
performance and a significant reduction in memory.
Note that using ``iterator()`` on a ``QuerySet`` which has already been
evaluated will force it to evaluate again, repeating the query.
-.. _iterator: http://www.python.org/dev/peps/pep-0234/
-
latest
~~~~~~
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index effc0e5117..39259c2ac3 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -196,9 +196,7 @@ Methods
Returns the originating host of the request using information from the
``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If
they don't provide a value, the method uses a combination of
- ``SERVER_NAME`` and ``SERVER_PORT`` as detailed in `PEP 333`_.
-
- .. _PEP 333: http://www.python.org/dev/peps/pep-0333/
+ ``SERVER_NAME`` and ``SERVER_PORT`` as detailed in :pep:`3333`.
Example: ``"127.0.0.1:8000"``
@@ -645,7 +643,7 @@ Methods
``expires``, and the auto-calculation of ``max_age`` in such case
was added. The ``httponly`` argument was also added.
- Sets a cookie. The parameters are the same as in the `cookie Morsel`_
+ Sets a cookie. The parameters are the same as in the :class:`Cookie.Morsel`
object in the Python standard library.
* ``max_age`` should be a number of seconds, or ``None`` (default) if
@@ -664,13 +662,12 @@ Methods
JavaScript from having access to the cookie.
HTTPOnly_ is a flag included in a Set-Cookie HTTP response
- header. It is not part of the RFC2109 standard for cookies,
+ header. It is not part of the :rfc:`2109` standard for cookies,
and it isn't honored consistently by all browsers. However,
when it is honored, it can be a useful way to mitigate the
risk of client side script accessing the protected cookie
data.
- .. _`cookie Morsel`: http://docs.python.org/library/cookie.html#Cookie.Morsel
.. _HTTPOnly: http://www.owasp.org/index.php/HTTPOnly
.. method:: HttpResponse.set_signed_cookie(key, value='', salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False)
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 7b3f510c49..12f542e0c5 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -1010,8 +1010,8 @@ FILE_UPLOAD_PERMISSIONS
Default: ``None``
The numeric mode (i.e. ``0644``) to set newly uploaded files to. For
-more information about what these modes mean, see the `documentation for
-os.chmod`_
+more information about what these modes mean, see the documentation for
+:func:`os.chmod`.
If this isn't given or is ``None``, you'll get operating-system
dependent behavior. On most platforms, temporary files will have a mode
@@ -1028,8 +1028,6 @@ system's standard umask.
get totally incorrect behavior.
-.. _documentation for os.chmod: http://docs.python.org/library/os.html#os.chmod
-
.. setting:: FILE_UPLOAD_TEMP_DIR
FILE_UPLOAD_TEMP_DIR
@@ -1586,7 +1584,7 @@ Whether to use HTTPOnly flag on the session cookie. If this is set to
session cookie.
HTTPOnly_ is a flag included in a Set-Cookie HTTP response header. It
-is not part of the RFC2109 standard for cookies, and it isn't honored
+is not part of the :rfc:`2109` standard for cookies, and it isn't honored
consistently by all browsers. However, when it is honored, it can be a
useful way to mitigate the risk of client side script accessing the
protected cookie data.
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index 1b143b7a67..3638ce9078 100644
--- a/docs/ref/templates/builtins.txt
+++ b/docs/ref/templates/builtins.txt
@@ -1254,7 +1254,8 @@ Available format strings:
c ISO 8601 format. (Note: unlike others ``2008-01-02T10:30:00.000123+02:00``,
formatters, such as "Z", "O" or "r", or ``2008-01-02T10:30:00.000123`` if the datetime is naive
the "c" formatter will not add timezone
- offset if value is a `naive datetime`_.)
+ offset if value is a naive datetime
+ (see :class:`datetime.tzinfo`).
d Day of the month, 2 digits with ``'01'`` to ``'31'``
leading zeros.
D Day of the week, textual, 3 letters. ``'Fri'``
@@ -1288,7 +1289,7 @@ Available format strings:
if they're zero and the special-case
strings 'midnight' and 'noon' if
appropriate. Proprietary extension.
- r RFC 2822 formatted date. ``'Thu, 21 Dec 2000 16:01:07 +0200'``
+ r :rfc:`2822` formatted date. ``'Thu, 21 Dec 2000 16:01:07 +0200'``
s Seconds, 2 digits with leading zeros. ``'00'`` to ``'59'``
S English ordinal suffix for day of the ``'st'``, ``'nd'``, ``'rd'`` or ``'th'``
month, 2 characters.
@@ -1346,8 +1347,6 @@ used, without applying any localization.
.. versionchanged:: 1.2
Predefined formats can now be influenced by the current locale.
-.. _naive datetime: http://docs.python.org/library/datetime.html#datetime.tzinfo
-
.. templatefilter:: default
default
@@ -1815,9 +1814,7 @@ Example::
pprint
^^^^^^
-A wrapper around `pprint.pprint`__ -- for debugging, really.
-
-__ http://docs.python.org/library/pprint.html
+A wrapper around :func:`pprint.pprint` -- for debugging, really.
.. templatefilter:: random
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
index 8272e049a8..5356af3563 100644
--- a/docs/ref/unicode.txt
+++ b/docs/ref/unicode.txt
@@ -148,13 +148,12 @@ URI and IRI handling
Web frameworks have to deal with URLs (which are a type of IRI_). One
requirement of URLs is that they are encoded using only ASCII characters.
However, in an international environment, you might need to construct a
-URL from an IRI_ -- very loosely speaking, a URI that can contain Unicode
+URL from an IRI_ -- very loosely speaking, a URI_ that can contain Unicode
characters. Quoting and converting an IRI to URI can be a little tricky, so
Django provides some assistance.
* The function ``django.utils.encoding.iri_to_uri()`` implements the
- conversion from IRI to URI as required by the specification (`RFC
- 3987`_).
+ conversion from IRI to URI as required by the specification (:rfc:`3987`).
* The functions ``django.utils.http.urlquote()`` and
``django.utils.http.urlquote_plus()`` are versions of Python's standard
@@ -203,7 +202,6 @@ double-quoting problems.
.. _URI: http://www.ietf.org/rfc/rfc2396.txt
.. _IRI: http://www.ietf.org/rfc/rfc3987.txt
-.. _RFC 3987: IRI_
Models
======
diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt
index 0849a21c2e..0b2e386268 100644
--- a/docs/ref/utils.txt
+++ b/docs/ref/utils.txt
@@ -21,9 +21,8 @@ managing the ``Vary`` header of responses. It includes functions to patch the
header of response objects directly and decorators that change functions to do
that header-patching themselves.
-For information on the ``Vary`` header, see `RFC 2616 section 14.44`_.
-
-.. _RFC 2616 section 14.44: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
+For information on the ``Vary`` header, see :rfc:`2616#section-14.44` section
+14.44.
Essentially, the ``Vary`` HTTP header defines which headers a cache should take
into account when building its cache key. Requests with the same path but
@@ -179,11 +178,9 @@ results. Instead do::
Convert an Internationalized Resource Identifier (IRI) portion to a URI
portion that is suitable for inclusion in a URL.
- This is the algorithm from section 3.1 of `RFC 3987`_. However, since we
- are assuming input is either UTF-8 or unicode already, we can simplify
- things a little from the full method.
-
- .. _RFC 3987: http://www.ietf.org/rfc/rfc3987.txt
+ This is the algorithm from section 3.1 of :rfc:`3987#section-3.1`. However,
+ since we are assuming input is either UTF-8 or unicode already, we can
+ simplify things a little from the full method.
Returns an ASCII string containing the encoded result.
@@ -397,10 +394,8 @@ Atom1Feed
.. function:: http_date(epoch_seconds=None)
- Formats the time to match the RFC 1123 date format as specified by HTTP
- `RFC 2616`_ section 3.3.1.
-
- .. _RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616.txt
+ Formats the time to match the :rfc:`1123` date format as specified by HTTP
+ :rfc:`2616#section-3.3.1` section 3.3.1.
Accepts a floating point number expressed in seconds since the epoch in
UTC--such as that outputted by ``time.time()``. If set to ``None``,
diff --git a/docs/releases/0.96.txt b/docs/releases/0.96.txt
index 1224360e3f..f88e59c73c 100644
--- a/docs/releases/0.96.txt
+++ b/docs/releases/0.96.txt
@@ -216,8 +216,8 @@ The test framework
------------------
Django now includes a test framework so you can start transmuting fear into
-boredom (with apologies to Kent Beck). You can write tests based on doctest_
-or unittest_ and test your views with a simple test client.
+boredom (with apologies to Kent Beck). You can write tests based on
+:mod:`doctest` or :mod:`unittest` and test your views with a simple test client.
There is also new support for "fixtures" -- initial data, stored in any of the
supported `serialization formats`_, that will be loaded into your database at the
@@ -225,8 +225,6 @@ start of your tests. This makes testing with real data much easier.
See `the testing documentation`_ for the full details.
-.. _doctest: http://docs.python.org/library/doctest.html
-.. _unittest: http://docs.python.org/library/unittest.html
.. _the testing documentation: http://www.djangoproject.com/documentation/0.96/testing/
.. _serialization formats: http://www.djangoproject.com/documentation/0.96/serialization/
diff --git a/docs/releases/1.2.txt b/docs/releases/1.2.txt
index f397a892d6..7d4f93e94b 100644
--- a/docs/releases/1.2.txt
+++ b/docs/releases/1.2.txt
@@ -764,10 +764,8 @@ over the next few release cycles.
Code taking advantage of any of the features below will raise a
``PendingDeprecationWarning`` in Django 1.2. This warning will be
-silent by default, but may be turned on using Python's `warnings
-module`_, or by running Python with a ``-Wd`` or `-Wall` flag.
-
-.. _warnings module: http://docs.python.org/library/warnings.html
+silent by default, but may be turned on using Python's :mod:`warnings`
+module, or by running Python with a ``-Wd`` or `-Wall` flag.
In Django 1.3, these warnings will become a ``DeprecationWarning``,
which is *not* silent. In Django 1.4 support for these features will
diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt
index e134cf1a28..3229cfd505 100644
--- a/docs/releases/1.3-alpha-1.txt
+++ b/docs/releases/1.3-alpha-1.txt
@@ -279,10 +279,8 @@ over the next few release cycles.
Code taking advantage of any of the features below will raise a
``PendingDeprecationWarning`` in Django 1.3. This warning will be
-silent by default, but may be turned on using Python's `warnings
-module`_, or by running Python with a ``-Wd`` or `-Wall` flag.
-
-.. _warnings module: http://docs.python.org/library/warnings.html
+silent by default, but may be turned on using Python's :mod:`warnings`
+module, or by running Python with a ``-Wd`` or `-Wall` flag.
In Django 1.4, these warnings will become a ``DeprecationWarning``,
which is *not* silent. In Django 1.5 support for these features will
diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt
index c2276f8fcf..0130657060 100644
--- a/docs/releases/1.3.txt
+++ b/docs/releases/1.3.txt
@@ -664,10 +664,8 @@ over the next few release cycles.
Code taking advantage of any of the features below will raise a
``PendingDeprecationWarning`` in Django 1.3. This warning will be
-silent by default, but may be turned on using Python's `warnings
-module`_, or by running Python with a ``-Wd`` or `-Wall` flag.
-
-.. _warnings module: http://docs.python.org/library/warnings.html
+silent by default, but may be turned on using Python's :mod:`warnings`
+module, or by running Python with a ``-Wd`` or `-Wall` flag.
In Django 1.4, these warnings will become a ``DeprecationWarning``,
which is *not* silent. In Django 1.5 support for these features will
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index df4e663184..81e1b72d69 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -495,7 +495,7 @@ CSRF protection extended to PUT and DELETE
Previously, Django's :doc:`CSRF protection ` provided
protection against only POST requests. Since use of PUT and DELETE methods in
AJAX applications is becoming more common, we now protect all methods not
-defined as safe by RFC 2616 i.e. we exempt GET, HEAD, OPTIONS and TRACE, and
+defined as safe by :rfc:`2616` i.e. we exempt GET, HEAD, OPTIONS and TRACE, and
enforce protection on everything else.
If you using PUT or DELETE methods in AJAX applications, please see the
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
index d52c3c6669..f4302e9746 100644
--- a/docs/topics/db/models.txt
+++ b/docs/topics/db/models.txt
@@ -676,10 +676,7 @@ For example, this model has a few custom methods::
return '%s %s' % (self.first_name, self.last_name)
full_name = property(_get_full_name)
-The last method in this example is a :term:`property`. `Read more about
-properties`_.
-
-.. _Read more about properties: http://www.python.org/download/releases/2.2/descrintro/#property
+The last method in this example is a :term:`property`.
The :doc:`model instance reference ` has a complete list
of :ref:`methods automatically given to each model `.
diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index 680fa5e99a..1b1e94654f 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -259,14 +259,12 @@ as dirty using ``transaction.set_dirty()`` when using raw SQL calls.
Connections and cursors
-----------------------
-``connection`` and ``cursor`` mostly implement the standard `Python DB-API`_
-(except when it comes to :doc:`transaction handling `).
-If you're not familiar with the Python DB-API, note that the SQL statement in
-``cursor.execute()`` uses placeholders, ``"%s"``, rather than adding parameters
-directly within the SQL. If you use this technique, the underlying database
-library will automatically add quotes and escaping to your parameter(s) as
-necessary. (Also note that Django expects the ``"%s"`` placeholder, *not* the
-``"?"`` placeholder, which is used by the SQLite Python bindings. This is for
-the sake of consistency and sanity.)
-
-.. _Python DB-API: http://www.python.org/dev/peps/pep-0249/
+``connection`` and ``cursor`` mostly implement the standard Python DB-API
+described in :pep:`249` (except when it comes to :doc:`transaction handling
+`). If you're not familiar with the Python DB-API, note
+that the SQL statement in ``cursor.execute()`` uses placeholders, ``"%s"``,
+rather than adding parameters directly within the SQL. If you use this
+technique, the underlying database library will automatically add quotes and
+escaping to your parameter(s) as necessary. (Also note that Django expects the
+``"%s"`` placeholder, *not* the ``"?"`` placeholder, which is used by the SQLite
+Python bindings. This is for the sake of consistency and sanity.)
diff --git a/docs/topics/email.txt b/docs/topics/email.txt
index 5979951ac4..6771b83d01 100644
--- a/docs/topics/email.txt
+++ b/docs/topics/email.txt
@@ -5,16 +5,14 @@ Sending email
.. module:: django.core.mail
:synopsis: Helpers to easily send email.
-Although Python makes sending email relatively easy via the `smtplib
-library`_, Django provides a couple of light wrappers over it. These wrappers
-are provided to make sending email extra quick, to make it easy to test
-email sending during development, and to provide support for platforms that
-can't use SMTP.
+Although Python makes sending email relatively easy via the :mod:`smtplib`
+module, Django provides a couple of light wrappers over it. These wrappers are
+provided to make sending email extra quick, to make it easy to test email
+sending during development, and to provide support for platforms that can't use
+SMTP.
The code lives in the ``django.core.mail`` module.
-.. _smtplib library: http://docs.python.org/library/smtplib.html
-
Quick example
=============
@@ -54,8 +52,9 @@ are required.
member of ``recipient_list`` will see the other recipients in the "To:"
field of the email message.
* ``fail_silently``: A boolean. If it's ``False``, ``send_mail`` will raise
- an ``smtplib.SMTPException``. See the `smtplib docs`_ for a list of
- possible exceptions, all of which are subclasses of ``SMTPException``.
+ an :exc:`smtplib.SMTPException`. See the :mod:`smtplib` docs for a list of
+ possible exceptions, all of which are subclasses of
+ :exc:`~smtplib.SMTPException`.
* ``auth_user``: The optional username to use to authenticate to the SMTP
server. If this isn't provided, Django will use the value of the
:setting:`EMAIL_HOST_USER` setting.
@@ -67,8 +66,6 @@ are required.
See the documentation on :ref:`Email backends `
for more details.
-.. _smtplib docs: http://docs.python.org/library/smtplib.html
-
send_mass_mail()
================
@@ -125,8 +122,9 @@ This method exists for convenience and readability.
.. versionchanged:: 1.3
If ``html_message`` is provided, the resulting email will be a
-multipart/alternative email with ``message`` as the "text/plain"
-content type and ``html_message`` as the "text/html" content type.
+:mimetype:`multipart/alternative` email with ``message`` as the
+:mimetype:`text/plain` content type and ``html_message`` as the
+:mimetype:`text/html` content type.
mail_managers()
===============
@@ -608,9 +606,7 @@ the email body. You then only need to set the :setting:`EMAIL_HOST` and
:setting:`EMAIL_PORT` accordingly, and you are set.
For a more detailed discussion of testing and processing of emails locally,
-see the Python documentation on the `SMTP Server`_.
-
-.. _SMTP Server: http://docs.python.org/library/smtpd.html
+see the Python documentation for the :mod:`smtpd` module.
SMTPConnection
==============
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
index b845772e97..63454f05a4 100644
--- a/docs/topics/http/file-uploads.txt
+++ b/docs/topics/http/file-uploads.txt
@@ -149,8 +149,8 @@ Three settings control Django's file upload behavior:
:setting:`FILE_UPLOAD_PERMISSIONS`
The numeric mode (i.e. ``0644``) to set newly uploaded files to. For
- more information about what these modes mean, see the `documentation for
- os.chmod`_
+ more information about what these modes mean, see the documentation for
+ :func:`os.chmod`.
If this isn't given or is ``None``, you'll get operating-system
dependent behavior. On most platforms, temporary files will have a mode
@@ -179,8 +179,6 @@ Three settings control Django's file upload behavior:
Which means "try to upload to memory first, then fall back to temporary
files."
-.. _documentation for os.chmod: http://docs.python.org/library/os.html#os.chmod
-
``UploadedFile`` objects
========================
@@ -189,16 +187,16 @@ define the following methods/attributes:
.. attribute:: UploadedFile.content_type
- The content-type header uploaded with the file (e.g. ``text/plain`` or
- ``application/pdf``). Like any data supplied by the user, you shouldn't
- trust that the uploaded file is actually this type. You'll still need to
- validate that the file contains the content that the content-type header
- claims -- "trust but verify."
+ The content-type header uploaded with the file (e.g. :mimetype:`text/plain`
+ or :mimetype:`application/pdf`). Like any data supplied by the user, you
+ shouldn't trust that the uploaded file is actually this type. You'll still
+ need to validate that the file contains the content that the content-type
+ header claims -- "trust but verify."
.. attribute:: UploadedFile.charset
- For ``text/*`` content-types, the character set (i.e. ``utf8``) supplied
- by the browser. Again, "trust but verify" is the best policy here.
+ For :mimetype:`text/*` content-types, the character set (i.e. ``utf8``)
+ supplied by the browser. Again, "trust but verify" is the best policy here.
.. attribute:: UploadedFile.temporary_file_path()
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 091b8892be..494b37cb94 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -495,7 +495,7 @@ Whether to use HTTPOnly flag on the session cookie. If this is set to
session cookie.
HTTPOnly_ is a flag included in a Set-Cookie HTTP response header. It
-is not part of the RFC2109 standard for cookies, and it isn't honored
+is not part of the :rfc:`2109` standard for cookies, and it isn't honored
consistently by all browsers. However, when it is honored, it can be a
useful way to mitigate the risk of client side script accessing the
protected cookie data.
@@ -553,15 +553,13 @@ Technical details
=================
* The session dictionary should accept any pickleable Python object. See
- `the pickle module`_ for more information.
+ the :mod:`pickle` module for more information.
* Session data is stored in a database table named ``django_session`` .
* Django only sends a cookie if it needs to. If you don't set any session
data, it won't send a session cookie.
-.. _`the pickle module`: http://docs.python.org/library/pickle.html
-
Session IDs in URLs
===================
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index aa45396ed7..64b7c4a7e7 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -64,7 +64,7 @@ Example
-------
The following example renders the template ``myapp/index.html`` with the
-MIME type ``application/xhtml+xml``::
+MIME type :mimetype:`application/xhtml+xml`::
from django.shortcuts import render
@@ -131,7 +131,7 @@ Example
-------
The following example renders the template ``myapp/index.html`` with the
-MIME type ``application/xhtml+xml``::
+MIME type :mimetype:`application/xhtml+xml`::
from django.shortcuts import render_to_response
diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt
index 02c426a66c..d4603615b0 100644
--- a/docs/topics/http/views.txt
+++ b/docs/topics/http/views.txt
@@ -211,7 +211,7 @@ default, call the view ``django.views.defaults.permission_denied``.
This view loads and renders the template ``403.html`` in your root template
directory, or if this file does not exist, instead serves the text
-"403 Forbidden", as per RFC 2616 (the HTTP 1.1 Specification).
+"403 Forbidden", as per :rfc:`2616` (the HTTP 1.1 Specification).
It is possible to override ``django.views.defaults.permission_denied`` in the
same way you can for the 404 and 500 views by specifying a ``handler403`` in
diff --git a/docs/topics/install.txt b/docs/topics/install.txt
index 2006718596..70b0783957 100644
--- a/docs/topics/install.txt
+++ b/docs/topics/install.txt
@@ -52,19 +52,17 @@ See :doc:`How to use Django with mod_wsgi `
for information on how to configure mod_wsgi once you have it
installed.
-If you can't use mod_wsgi for some reason, fear not: Django supports
-many other deployment options. One is :doc:`uWSGI `;
-it works very well with `nginx`_. Another is :doc:`FastCGI
-`, perfect for using Django with servers
-other than Apache. Additionally, Django follows the WSGI_ spec, which
-allows it to run on a variety of server platforms. See the
-`server-arrangements wiki page`_ for specific installation
-instructions for each platform.
+If you can't use mod_wsgi for some reason, fear not: Django supports many other
+deployment options. One is :doc:`uWSGI `; it works
+very well with `nginx`_. Another is :doc:`FastCGI `,
+perfect for using Django with servers other than Apache. Additionally, Django
+follows the WSGI spec (:pep:`3333`), which allows it to run on a variety of
+server platforms. See the `server-arrangements wiki page`_ for specific
+installation instructions for each platform.
.. _Apache: http://httpd.apache.org/
.. _nginx: http://nginx.net/
.. _mod_wsgi: http://code.google.com/p/modwsgi/
-.. _WSGI: http://www.python.org/dev/peps/pep-0333/
.. _server-arrangements wiki page: http://code.djangoproject.com/wiki/ServerArrangements
.. _database-installation:
diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt
index 9137038214..f23b529d97 100644
--- a/docs/topics/logging.txt
+++ b/docs/topics/logging.txt
@@ -10,12 +10,10 @@ Logging
A quick logging primer
======================
-Django uses Python's builtin logging module to perform system logging.
-The usage of the logging module is discussed in detail in `Python's
-own documentation`_. However, if you've never used Python's logging
-framework (or even if you have), here's a quick primer.
-
-.. _Python's own documentation: http://docs.python.org/library/logging.html
+Django uses Python's builtin :mod:`logging` module to perform system logging.
+The usage of this module is discussed in detail in Python's own documentation.
+However, if you've never used Python's logging framework (or even if you have),
+here's a quick primer.
The cast of players
-------------------
diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt
index 55c1868e13..f4c06e5a53 100644
--- a/docs/topics/testing.txt
+++ b/docs/topics/testing.txt
@@ -36,7 +36,7 @@ two test frameworks that ship in the Python standard library. The two
frameworks are:
* **Unit tests** -- tests that are expressed as methods on a Python class
- that subclasses ``unittest.TestCase`` or Django's customized
+ that subclasses :class:`unittest.TestCase` or Django's customized
:class:`TestCase`. For example::
import unittest
@@ -68,7 +68,7 @@ test framework, as we'll explain in a bit.
Writing unit tests
------------------
-Django's unit tests use a Python standard library module: unittest_. This
+Django's unit tests use a Python standard library module: :mod:`unittest`. This
module defines tests in class-based approach.
.. admonition:: unittest2
@@ -82,7 +82,7 @@ module defines tests in class-based approach.
backported for Python 2.5 compatibility.
To access this library, Django provides the
- ``django.utils.unittest`` module alias. If you are using Python
+ :mod:`django.utils.unittest` module alias. If you are using Python
2.7, or you have installed unittest2 locally, Django will map the
alias to the installed version of the unittest library. Otherwise,
Django will use it's own bundled version of unittest2.
@@ -104,13 +104,13 @@ For a given Django application, the test runner looks for unit tests in two
places:
* The ``models.py`` file. The test runner looks for any subclass of
- ``unittest.TestCase`` in this module.
+ :class:`unittest.TestCase` in this module.
* A file called ``tests.py`` in the application directory -- i.e., the
directory that holds ``models.py``. Again, the test runner looks for any
- subclass of ``unittest.TestCase`` in this module.
+ subclass of :class:`unittest.TestCase` in this module.
-Here is an example ``unittest.TestCase`` subclass::
+Here is an example :class:`unittest.TestCase` subclass::
from django.utils import unittest
from myapp.models import Animal
@@ -124,10 +124,10 @@ Here is an example ``unittest.TestCase`` subclass::
self.assertEqual(self.lion.speak(), 'The lion says "roar"')
self.assertEqual(self.cat.speak(), 'The cat says "meow"')
-When you :ref:`run your tests `, the default behavior of the
-test utility is to find all the test cases (that is, subclasses of
-``unittest.TestCase``) in ``models.py`` and ``tests.py``, automatically build a
-test suite out of those test cases, and run that suite.
+When you :ref:`run your tests `, the default behavior of the test
+utility is to find all the test cases (that is, subclasses of
+:class:`unittest.TestCase`) in ``models.py`` and ``tests.py``, automatically
+build a test suite out of those test cases, and run that suite.
There is a second way to define the test suite for a module: if you define a
function called ``suite()`` in either ``models.py`` or ``tests.py``, the
@@ -136,20 +136,17 @@ module. This follows the `suggested organization`_ for unit tests. See the
Python documentation for more details on how to construct a complex test
suite.
-For more details about ``unittest``, see the `standard library unittest
-documentation`_.
+For more details about :mod:`unittest`, see the Python documentation.
-.. _unittest: http://docs.python.org/library/unittest.html
-.. _standard library unittest documentation: unittest_
.. _suggested organization: http://docs.python.org/library/unittest.html#organizing-tests
Writing doctests
----------------
-Doctests use Python's standard doctest_ module, which searches your docstrings
-for statements that resemble a session of the Python interactive interpreter.
-A full explanation of how doctest works is out of the scope of this document;
-read Python's official documentation for the details.
+Doctests use Python's standard :mod:`doctest` module, which searches your
+docstrings for statements that resemble a session of the Python interactive
+interpreter. A full explanation of how :mod:`doctest` works is out of the scope
+of this document; read Python's official documentation for the details.
.. admonition:: What's a **docstring**?
@@ -221,12 +218,7 @@ database or loading a fixture. (See the section on fixtures, below, for more
on this.) Note that to use this feature, the database user Django is connecting
as must have ``CREATE DATABASE`` rights.
-For more details about how doctest works, see the `standard library
-documentation for doctest`_.
-
-.. _doctest: http://docs.python.org/library/doctest.html
-.. _standard library documentation for doctest: doctest_
-
+For more details about :mod:`doctest`, see the Python documentation.
Which should I use?
-------------------
@@ -239,7 +231,7 @@ For developers new to testing, however, this choice can seem confusing. Here,
then, are a few key differences to help you decide which approach is right for
you:
- * If you've been using Python for a while, ``doctest`` will probably feel
+ * If you've been using Python for a while, :mod:`doctest` will probably feel
more "pythonic". It's designed to make writing tests as easy as possible,
so it requires no overhead of writing classes or methods. You simply put
tests in docstrings. This has the added advantage of serving as
@@ -250,19 +242,19 @@ you:
as it can be unclear exactly why the test failed. Thus, doctests should
generally be avoided and used primarily for documentation examples only.
- * The ``unittest`` framework will probably feel very familiar to developers
- coming from Java. ``unittest`` is inspired by Java's JUnit, so you'll
- feel at home with this method if you've used JUnit or any test framework
- inspired by JUnit.
+ * The :mod:`unittest` framework will probably feel very familiar to
+ developers coming from Java. :mod:`unittest` is inspired by Java's JUnit,
+ so you'll feel at home with this method if you've used JUnit or any test
+ framework inspired by JUnit.
* If you need to write a bunch of tests that share similar code, then
- you'll appreciate the ``unittest`` framework's organization around
+ you'll appreciate the :mod:`unittest` framework's organization around
classes and methods. This makes it easy to abstract common tasks into
common methods. The framework also supports explicit setup and/or cleanup
routines, which give you a high level of control over the environment
in which your test cases are run.
- * If you're writing tests for Django itself, you should use ``unittest``.
+ * If you're writing tests for Django itself, you should use :mod:`unittest`.
.. _running-tests:
@@ -553,7 +545,7 @@ failed::
A full explanation of this error output is beyond the scope of this document,
but it's pretty intuitive. You can consult the documentation of Python's
-``unittest`` library for details.
+:mod:`unittest` library for details.
Note that the return code for the test-runner script is 1 for any number of
failed and erroneous tests. If all the tests pass, the return code is 0. This
@@ -639,7 +631,8 @@ Note a few important things about how the test client works:
The test client is not capable of retrieving Web pages that are not
powered by your Django project. If you need to retrieve other Web pages,
- use a Python standard library module such as urllib_ or urllib2_.
+ use a Python standard library module such as :mod:`urllib` or
+ :mod:`urllib2`.
* To resolve URLs, the test client uses whatever URLconf is pointed-to by
your :setting:`ROOT_URLCONF` setting.
@@ -668,10 +661,6 @@ Note a few important things about how the test client works:
>>> from django.test import Client
>>> csrf_client = Client(enforce_csrf_checks=True)
-
-.. _urllib: http://docs.python.org/library/urllib.html
-.. _urllib2: http://docs.python.org/library/urllib2.html
-
Making requests
~~~~~~~~~~~~~~~
@@ -759,15 +748,15 @@ arguments at time of construction:
name=fred&passwd=secret
- If you provide ``content_type`` (e.g., ``text/xml`` for an XML
+ If you provide ``content_type`` (e.g. :mimetype:`text/xml` for an XML
payload), the contents of ``data`` will be sent as-is in the POST
request, using ``content_type`` in the HTTP ``Content-Type`` header.
If you don't provide a value for ``content_type``, the values in
``data`` will be transmitted with a content type of
- ``multipart/form-data``. In this case, the key-value pairs in ``data``
- will be encoded as a multipart message and used to create the POST data
- payload.
+ :mimetype:`multipart/form-data`. In this case, the key-value pairs in
+ ``data`` will be encoded as a multipart message and used to create the
+ POST data payload.
To submit multiple values for a given key -- for example, to specify
the selections for a ``