mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 14:16:09 +00:00
Code Issues 32 Releases Wiki Activity

Converted links to external topics so they use intersphinx extension markup.

Browse Source 
This allows to make these links more resilent to changes in the target URLs.
Thanks Jannis for the report and Aymeric Augustin for the patch.

Fixes #16586.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16720 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Ramiro Morales
2011-09-04 21:17:30 +00:00
parent 9110257a32
commit 932b1b8d6d
43 changed files with 283 additions and 377 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/topics/db/models.txt
View File

@@ -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 </ref/models/instances>` has a complete list
of :ref:`methods automatically given to each model <model-instance-methods>`.

20
docs/topics/db/sql.txt
View File

@@ -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 </topics/db/transactions>`).
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
</topics/db/transactions>`). 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.)

28
docs/topics/email.txt
View File

@@ -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 <topic-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
==============

20
docs/topics/http/file-uploads.txt
View File

@@ -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()

6
docs/topics/http/sessions.txt
View File

@@ -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
===================

4
docs/topics/http/shortcuts.txt
View File

@@ -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

2
docs/topics/http/views.txt
View File

@@ -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

16
docs/topics/install.txt
View File

@@ -52,19 +52,17 @@ See :doc:`How to use Django with mod_wsgi </howto/deployment/modwsgi>`
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 </howto/deployment/fastcgi>`;
it works very well with `nginx`_. Another is :doc:`FastCGI
</howto/deployment/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 </howto/deployment/fastcgi>`; it works
very well with `nginx`_. Another is :doc:`FastCGI </howto/deployment/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:

10
docs/topics/logging.txt
View File

@@ -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
-------------------

142
docs/topics/testing.txt
View File

@@ -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 <running-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 <running-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 ``<select multiple>`` -- provide the values as a
@@ -955,8 +944,8 @@ Specifically, a ``Response`` object has the following attributes:
.. attribute:: status_code
The HTTP status of the response, as an integer. See RFC2616_ for a full
list of HTTP status codes.
The HTTP status of the response, as an integer. See
:rfc:`2616#section-10` for a full list of HTTP status codes.
.. versionadded:: 1.3
@@ -972,14 +961,12 @@ You can also use dictionary syntax on the response object to query the value
of any settings in the HTTP headers. For example, you could determine the
content type of a response using ``response['Content-Type']``.
.. _RFC2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Exceptions
~~~~~~~~~~
If you point the test client at a view that raises an exception, that exception
will be visible in the test case. You can then use a standard ``try...except``
block or ``unittest.TestCase.assertRaises()`` to test for exceptions.
will be visible in the test case. You can then use a standard ``try ... except``
block or :meth:`~unittest.TestCase.assertRaises` to test for exceptions.
The only exceptions that are not visible to the test client are ``Http404``,
``PermissionDenied`` and ``SystemExit``. Django catches these exceptions
@@ -1002,8 +989,9 @@ can access these properties as part of a test condition.
.. attribute:: Client.cookies
A Python ``SimpleCookie`` object, containing the current values of all the
client cookies. See the `Cookie module documentation`_ for more.
A Python :class:`~Cookie.SimpleCookie` object, containing the current values
of all the client cookies. See the documentation of the :mod:`Cookie` module
for more.
.. attribute:: Client.session
@@ -1019,8 +1007,6 @@ can access these properties as part of a test condition.
session['somekey'] = 'test'
session.save()
.. _Cookie module documentation: http://docs.python.org/library/cookie.html
Example
~~~~~~~
@@ -1100,19 +1086,19 @@ TestCase
.. currentmodule:: django.test
Normal Python unit test classes extend a base class of ``unittest.TestCase``.
Django provides a few extensions of this base class:
Normal Python unit test classes extend a base class of
:class:`unittest.TestCase`. Django provides a few extensions of this base class:
.. class:: TestCase()
This class provides some additional capabilities that can be useful for testing
Web sites.
Converting a normal ``unittest.TestCase`` to a Django ``TestCase`` is easy:
just change the base class of your test from ``unittest.TestCase`` to
``django.test.TestCase``. All of the standard Python unit test functionality
will continue to be available, but it will be augmented with some useful
additions, including:
Converting a normal :class:`unittest.TestCase` to a Django :class:`TestCase` is
easy: just change the base class of your test from :class:`unittest.TestCase` to
:class:`django.test.TestCase`. All of the standard Python unit test
functionality will continue to be available, but it will be augmented with some
useful additions, including:
* Automatic loading of fixtures.
@@ -1409,9 +1395,9 @@ Overriding settings
.. versionadded:: 1.4
For testing purposes it's often useful to change a setting temporarily
and revert to the original value after running the testing code. For
this use case Django provides a standard `Python context manager`_
For testing purposes it's often useful to change a setting temporarily and
revert to the original value after running the testing code. For this use case
Django provides a standard Python context manager (see :pep:`343`)
:meth:`~django.test.TestCase.settings`, which can be used like this::
from django.test import TestCase
@@ -1437,8 +1423,9 @@ in the ``with`` block and reset its value to the previous state afterwards.
.. function:: override_settings
In case you want to override a setting for just one test method or even the
whole TestCase class, Django provides the
:func:`django.test.utils.override_settings` decorator_. It's used like this::
whole :class:`TestCase` class, Django provides the
:func:`~django.test.utils.override_settings` decorator (see :pep:`318`). It's
used like this::
from django.test import TestCase
from django.test.utils import override_settings
@@ -1484,9 +1471,6 @@ decorate the class::
:data:`django.test.signals.setting_changed` signal to connect cleanup
and other state-resetting callbacks to.
.. _`Python context manager`: http://www.python.org/dev/peps/pep-0343/
.. _`decorator`: http://www.python.org/dev/peps/pep-0318/
Emptying the test outbox
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1505,8 +1489,9 @@ Assertions
.. versionchanged:: 1.2
Addded ``msg_prefix`` argument.
As Python's normal ``unittest.TestCase`` class implements assertion methods
such as ``assertTrue`` and ``assertEqual``, Django's custom ``TestCase`` class
As Python's normal :class:`unittest.TestCase` class implements assertion methods
such as :meth:`~unittest.TestCase.assertTrue` and
:meth:`~unittest.TestCase.assertEqual`, Django's custom :class:`TestCase` class
provides a number of custom assertion methods that are useful for testing Web
applications:
@@ -1521,8 +1506,8 @@ your test suite.
Asserts that execution of callable ``callable_obj`` raised the
``expected_exception`` exception and that such exception has an
``expected_message`` representation. Any other outcome is reported as a
failure. Similar to unittest's ``assertRaisesRegexp`` with the difference
that ``expected_message`` isn't a regular expression.
failure. Similar to unittest's :meth:`~unittest.TestCase.assertRaisesRegexp`
with the difference that ``expected_message`` isn't a regular expression.
.. method:: assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
@@ -1706,14 +1691,15 @@ Skipping tests
.. versionadded:: 1.3
The unittest library provides the ``@skipIf`` and ``@skipUnless``
decorators to allow you to skip tests if you know ahead of time that
those tests are going to fail under certain conditions.
The unittest library provides the :func:`@skipIf <unittest.skipIf>` and
:func:`@skipUnless <unittest.skipUnless>` decorators to allow you to skip tests
if you know ahead of time that those tests are going to fail under certain
conditions.
For example, if your test requires a particular optional library in
order to succeed, you could decorate the test case with ``@skipIf``.
Then, the test runner will report that the test wasn't executed and
why, instead of failing the test or omitting the test altogether.
For example, if your test requires a particular optional library in order to
succeed, you could decorate the test case with :func:`@skipIf
<unittest.skipIf>`. Then, the test runner will report that the test wasn't
executed and why, instead of failing the test or omitting the test altogether.
To supplement these test skipping behaviors, Django provides two
additional skip decorators. Instead of testing a generic boolean,
@@ -1757,7 +1743,7 @@ under MySQL with MyISAM tables)::
Using different testing frameworks
==================================
Clearly, ``doctest`` and ``unittest`` are not the only Python testing
Clearly, :mod:`doctest` and :mod:`unittest` are not the only Python testing
frameworks. While Django doesn't provide explicit support for alternative
frameworks, it does provide a way to invoke tests constructed for an
alternative framework as if they were normal Django tests.