sqlalchemy: Merged revisions 3832 to 3917 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/sqlalchemy@3918 bcc190cf-cafb-0310-a4f2-bffc1f526a37

22 files changed, 207 insertions, 107 deletions

diff --git a/docs/admin_css.txt b/docs/admin_css.txt
index ec402f7142..5822e26e45 100644
--- a/docs/admin_css.txt
+++ b/docs/admin_css.txt
@@ -82,7 +82,7 @@ There are also a few styles for styling text.
 .help
     This is a custom class for blocks of inline help text explaining the
     function of form elements. It makes text smaller and gray, and when applied
-    to ``p`` elements withing ``.form-row`` elements (see Form Styles below),
+    to ``p`` elements within ``.form-row`` elements (see Form Styles below),
     it will offset the text to align with the form field. Use this for help
     text, instead of ``small quiet``. It works on other elements, but try to
     put the class on a ``p`` whenever you can.
@@ -170,4 +170,4 @@ Labels
 Form labels should always precede the field, except in the case
 of checkboxes and radio buttons, where the ``input`` should come first. Any
 explanation or help text should follow the ``label`` in a ``p`` with class
-``.help``.
\ No newline at end of file
+``.help``.
diff --git a/docs/apache_auth.txt b/docs/apache_auth.txt
index 72e0841305..b85057924b 100644
--- a/docs/apache_auth.txt
+++ b/docs/apache_auth.txt
@@ -6,7 +6,7 @@ Since keeping multiple authentication databases in sync is a common problem when
 dealing with Apache, you can configuring Apache to authenticate against Django's
 `authentication system`_ directly.  For example, you could:
 
-    * Serve media files directly from Apache only to authenticated users.
+    * Serve static/media files directly from Apache only to authenticated users.
 
     * Authenticate access to a Subversion_ repository against Django users with
       a certain permission.
diff --git a/docs/api_stability.txt b/docs/api_stability.txt
index a9d6904735..18885fbe63 100644
--- a/docs/api_stability.txt
+++ b/docs/api_stability.txt
@@ -82,7 +82,7 @@ that 90% of Django can be considered forwards-compatible at this point.
 That said, these APIs should *not* be considered stable, and are likely to
 change:
 
-   - `Forms and validation`_ will most likely be compeltely rewritten to
+   - `Forms and validation`_ will most likely be completely rewritten to
      deemphasize Manipulators in favor of validation-aware models.
 
    - `Serialization`_ is under heavy development; changes are likely.
@@ -91,7 +91,7 @@ change:
      API changes may be necessary.
 
    - Generic relations will most likely be moved out of core and into the
-     content-types contrib package to avoid core dependacies on optional
+     content-types contrib package to avoid core dependancies on optional
      components.
 
    - The comments framework, which is yet undocumented, will likely get a complete
diff --git a/docs/authentication.txt b/docs/authentication.txt
index 31a894512a..2a61ec82b5 100644
--- a/docs/authentication.txt
+++ b/docs/authentication.txt
@@ -66,8 +66,8 @@ Fields
       long and can contain any character. See the "Passwords" section below.
     * ``is_staff`` -- Boolean. Designates whether this user can access the
       admin site.
-    * ``is_active`` -- Boolean. Designates whether this user can log into the
-      Django admin. Set this to ``False`` instead of deleting accounts.
+    * ``is_active`` -- Boolean. Designates whether this account can be used
+      to log in. Set this flag to ``False`` instead of deleting accounts.
     * ``is_superuser`` -- Boolean. Designates that this user has all permissions
       without explicitly assigning them.
     * ``last_login`` -- A datetime of the user's last login. Is set to the
@@ -99,7 +99,9 @@ custom methods:
       should prefer using ``is_authenticated()`` to this method.
 
     * ``is_authenticated()`` -- Always returns ``True``. This is a way to
-      tell if the user has been authenticated.
+      tell if the user has been authenticated. This does not imply any 
+      permissions, and doesn't check if the user is active - it only indicates
+      that the user has provided a valid username and password.
 
     * ``get_full_name()`` -- Returns the ``first_name`` plus the ``last_name``,
       with a space in between.
@@ -120,13 +122,16 @@ custom methods:
 
     * ``has_perm(perm)`` -- Returns ``True`` if the user has the specified
       permission, where perm is in the format ``"package.codename"``.
+      If the user is inactive, this method will always return ``False``.
 
     * ``has_perms(perm_list)`` -- Returns ``True`` if the user has each of the
       specified permissions, where each perm is in the format
-      ``"package.codename"``.
+      ``"package.codename"``. If the user is inactive, this method will 
+      always return ``False``.
 
     * ``has_module_perms(package_name)`` -- Returns ``True`` if the user has
       any permissions in the given package (the Django app label).
+      If the user is inactive, this method will always return ``False``.
 
     * ``get_and_delete_messages()`` -- Returns a list of ``Message`` objects in
       the user's queue and deletes the messages from the queue.
@@ -283,7 +288,10 @@ password is invalid, ``authenticate()`` returns ``None``. Example::
     from django.contrib.auth import authenticate
     user = authenticate(username='john', password='secret')
     if user is not None:
-        print "You provided a correct username and password!"
+        if user.is_active:
+            print "You provided a correct username and password!"
+        else:
+            print "Your account has been disabled!"
     else:
         print "Your username and password were incorrect."
 
@@ -301,10 +309,13 @@ This example shows how you might use both ``authenticate()`` and ``login()``::
         password = request.POST['password']
         user = authenticate(username=username, password=password)
         if user is not None:
-            login(request, user)
-            # Redirect to a success page.
+            if user.is_active:
+                login(request, user)
+                # Redirect to a success page.
+            else:
+                # Return a 'disabled account' error message
         else:
-            # Return an error message.
+            # Return an 'invalid login' error message.
 
 How to log a user out
 ---------------------
@@ -456,9 +467,9 @@ As a shortcut, you can use the convenient ``user_passes_test`` decorator::
         # ...
     my_view = user_passes_test(lambda u: u.has_perm('polls.can_vote'))(my_view)
 
-We are using this particular test as a relatively simple example, however be
-aware that if you just want to test if a permission is available to a user,
-you can use the ``permission_required()`` decorator described below.
+We're using this particular test as a relatively simple example. However, if
+you just want to test whether a permission is available to a user, you can use
+the ``permission_required()`` decorator, described later in this document.
 
 Here's the same thing, using Python 2.4's decorator syntax::
 
@@ -495,20 +506,30 @@ Example in Python 2.4 syntax::
 The permission_required decorator
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Since checking whether a user has a particular permission available to them is a
-relatively common operation, Django provides a shortcut for that particular
-case: the ``permission_required()`` decorator. Using this decorator, the
-earlier example can be written as::
+**New in Django development version**
+
+It's a relatively common task to check whether a user has a particular
+permission. For that reason, Django provides a shortcut for that case: the
+``permission_required()`` decorator. Using this decorator, the earlier example
+can be written as::
 
     from django.contrib.auth.decorators import permission_required
-     
+
     def my_view(request):
         # ...
-     
     my_view = permission_required('polls.can_vote')(my_view)
 
 Note that ``permission_required()`` also takes an optional ``login_url``
-parameter.
+parameter. Example::
+
+    from django.contrib.auth.decorators import permission_required
+
+    def my_view(request):
+        # ...
+    my_view = permission_required('polls.can_vote', login_url='/loginpage/')(my_view)
+
+As in the ``login_required`` decorator, ``login_url`` defaults to
+``'/accounts/login/'``.
 
 Limiting access to generic views
 --------------------------------
@@ -633,7 +654,7 @@ The currently logged-in user, either a ``User`` instance or an``AnonymousUser``
 instance, is stored in the template variable ``{{ user }}``::
 
     {% if user.is_authenticated %}
-        <p>Welcome, {{ user.username }}. Thanks for logging in.</p>    
+        <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
     {% else %}
         <p>Welcome, new user. Please log in.</p>
     {% endif %}
diff --git a/docs/contributing.txt b/docs/contributing.txt
index 7ecda7425c..6ff0b038a3 100644
--- a/docs/contributing.txt
+++ b/docs/contributing.txt
@@ -259,10 +259,10 @@ The tests cover:
 We appreciate any and all contributions to the test suite!
 
 The Django tests all use the testing infrastructure that ships with Django for
-testing applications. See `Testing Django Applications`_ for an explanation of
+testing applications. See `Testing Django applications`_ for an explanation of
 how to write new tests.
 
-.. _Testing Django Applications: http://www.djangoproject.com/documentation/testing/
+.. _Testing Django applications: http://www.djangoproject.com/documentation/testing/
 
 Running the unit tests
 ----------------------
@@ -273,7 +273,7 @@ To run the tests, ``cd`` to the ``tests/`` directory and type::
 
 Yes, the unit tests need a settings module, but only for database connection
 info -- the ``DATABASE_ENGINE``, ``DATABASE_USER`` and ``DATABASE_PASSWORD``.
-You will also need a ``ROOT_URLCONF`` setting (it's value is ignored; it just
+You will also need a ``ROOT_URLCONF`` setting (its value is ignored; it just
 needs to be present) and a ``SITE_ID`` setting (any integer value will do) in
 order for all the tests to pass.
 
diff --git a/docs/db-api.txt b/docs/db-api.txt
index 0d1f049601..2f0c8b0589 100644
--- a/docs/db-api.txt
+++ b/docs/db-api.txt
@@ -876,15 +876,18 @@ The database API supports the following lookup types:
 exact
 ~~~~~
 
-Exact match.
+Exact match. If the value provided for comparison is ``None``, it will 
+be interpreted as an SQL ``NULL`` (See isnull_ for more details).  
 
-Example::
+Examples::
 
     Entry.objects.get(id__exact=14)
+    Entry.objects.get(id__exact=None)
 
-SQL equivalent::
+SQL equivalents::
 
     SELECT ... WHERE id = 14;
+    SELECT ... WHERE id = NULL;
 
 iexact
 ~~~~~~
@@ -1103,8 +1106,8 @@ such as January 3, July 3, etc.
 isnull
 ~~~~~~
 
-``NULL`` or ``IS NOT NULL`` match. Takes either ``True`` or ``False``, which
-correspond to ``IS NULL`` and ``IS NOT NULL``, respectively.
+Takes either ``True`` or ``False``, which correspond to SQL queries of 
+``IS NULL`` and ``IS NOT NULL``, respectively.
 
 Example::
 
@@ -1114,6 +1117,14 @@ SQL equivalent::
 
     SELECT ... WHERE pub_date IS NULL;
 
+.. admonition:: ``__isnull=True`` vs ``__exact=None``
+
+    There is an important difference between ``__isnull=True`` and 
+    ``__exact=None``. ``__exact=None`` will *always* return an empty result
+    set, because SQL requires that no value is equal to ``NULL``. 
+    ``__isnull`` determines if the field is currently holding the value 
+    of ``NULL`` without performing a comparison.
+
 search
 ~~~~~~
 
diff --git a/docs/django-admin.txt b/docs/django-admin.txt
index ed162f0520..7f9682b443 100644
--- a/docs/django-admin.txt
+++ b/docs/django-admin.txt
@@ -392,10 +392,10 @@ and `2` is verbose output.
 Example usage::
     django-admin.py manage.py --adminmedia=/tmp/new-admin-style/
 
-Tell Django where to find the various stylesheets and Javascript files for the
-admin interface when running the development server. Normally these files are
-served out of the Django source tree, but since some designers change these
-files for their site, this option allows you to test against custom versions.
+Tells Django where to find the various CSS and JavaScript files for the admin
+interface when running the development server. Normally these files are served
+out of the Django source tree, but because some designers customize these files
+for their site, this option allows you to test against custom versions.
 
 Extra niceties
 ==============
diff --git a/docs/faq.txt b/docs/faq.txt
index 204c69244d..eaccc6be43 100644
--- a/docs/faq.txt
+++ b/docs/faq.txt
@@ -227,9 +227,7 @@ When will you release Django 1.0?
 
 Short answer: When we're comfortable with Django's APIs, have added all
 features that we feel are necessary to earn a "1.0" status, and are ready to
-begin maintaining backwards compatibility. This should happen in a couple of
-months or so, although it's entirely possible that it could happen earlier.
-That translates into summer 2006.
+begin maintaining backwards compatibility. 
 
 The merging of Django's `magic-removal branch`_ went a long way toward Django
 1.0.
@@ -313,6 +311,18 @@ PostgreSQL fans, and MySQL_ and `SQLite 3`_ are also supported.
 .. _MySQL: http://www.mysql.com/
 .. _`SQLite 3`: http://www.sqlite.org/
 
+Do I lose anything by using Python 2.3 versus newer Python versions, such as Python 2.5?
+----------------------------------------------------------------------------------------
+
+No. Django itself is guaranteed to work with any version of Python from 2.3
+and higher.
+
+If you use a Python version newer than 2.3, you will, of course, be able to
+take advantage of newer Python features in your own code, along with the speed
+improvements and other optimizations that have been made to the Python language
+itself. But the Django framework itself should work equally well on 2.3 as it
+does on 2.4 or 2.5.
+
 Do I have to use mod_python?
 ----------------------------
 
@@ -487,7 +497,7 @@ specify an object to edit or delete.
 How do I add database-specific options to my CREATE TABLE statements, such as specifying MyISAM as the table type?
 ------------------------------------------------------------------------------------------------------------------
 
-We try to avoid adding special cases in the Django code to accomodate all the
+We try to avoid adding special cases in the Django code to accommodate all the
 database-specific options such as table type, etc. If you'd like to use any of
 these options, create an `SQL initial data file`_ that contains ``ALTER TABLE``
 statements that do what you want to do. The initial data files are executed in
diff --git a/docs/forms.txt b/docs/forms.txt
index 0ffb0bdcb7..4a4ba37289 100644
--- a/docs/forms.txt
+++ b/docs/forms.txt
@@ -211,7 +211,7 @@ Below is the finished view::
     def create_place(request):
         manipulator = Place.AddManipulator()
 
-        if request.POST:
+        if request.method == 'POST':
             # If data was POSTed, we're trying to create a new Place.
             new_data = request.POST.copy()
 
@@ -309,7 +309,7 @@ about editing an existing one? It's shockingly similar to creating a new one::
         # Grab the Place object in question for future use.
         place = manipulator.original_object
 
-        if request.POST:
+        if request.method == 'POST':
             new_data = request.POST.copy()
             errors = manipulator.get_validation_errors(new_data)
             if not errors:
@@ -337,8 +337,8 @@ The only real differences are:
       object being edited.
 
     * We set ``new_data`` based upon ``flatten_data()`` from the manipulator.
-      ``flatten_data()`` takes the data from the original object under 
-      manipulation, and converts it into a data dictionary that can be used 
+      ``flatten_data()`` takes the data from the original object under
+      manipulation, and converts it into a data dictionary that can be used
       to populate form elements with the existing values for the object.
 
     * The above example uses a different template, so create and edit can be
@@ -391,7 +391,7 @@ Here's a simple function that might drive the above form::
 
     def contact_form(request):
         manipulator = ContactManipulator()
-        if request.POST:
+        if request.method == 'POST':
             new_data = request.POST.copy()
             errors = manipulator.get_validation_errors(new_data)
             if not errors:
@@ -404,7 +404,7 @@ Here's a simple function that might drive the above form::
             errors = new_data = {}
         form = forms.FormWrapper(manipulator, new_data, errors)
         return render_to_response('contact_form.html', {'form': form})
-        
+
 ``FileField`` and ``ImageField`` special cases
 ==============================================
 
@@ -481,15 +481,15 @@ the data being validated.
 Also, because consistency in user interfaces is important, we strongly urge you
 to put punctuation at the end of your validation messages.
 
-When Are Validators Called?
+When are validators called?
 ---------------------------
 
 After a form has been submitted, Django first checks to see that all the
 required fields are present and non-empty. For each field that passes that
 test *and if the form submission contained data* for that field, all the
-validators for that field are called in turn. The emphasised portion in the
+validators for that field are called in turn. The emphasized portion in the
 last sentence is important: if a form field is not submitted (because it
-contains no data -- which is normal HTML behaviour), the validators are not
+contains no data -- which is normal HTML behavior), the validators are not
 run against the field.
 
 This feature is particularly important for models using
@@ -497,18 +497,17 @@ This feature is particularly important for models using
 ``forms.CheckBoxField``. If the checkbox is not selected, it will not
 contribute to the form submission.
 
-If you would like your validator to *always* run, regardless of whether the
-field it is attached to contains any data, set the ``always_test`` attribute
-on the validator function. For example::
+If you would like your validator to run *always*, regardless of whether its
+attached field contains any data, set the ``always_test`` attribute on the
+validator function. For example::
 
     def my_custom_validator(field_data, all_data):
         # ...
-
     my_custom_validator.always_test = True
 
 This validator will always be executed for any field it is attached to.
 
-Ready-made Validators
+Ready-made validators
 ---------------------
 
 Writing your own validator is not difficult, but there are some situations
@@ -580,7 +579,7 @@ fails. If no message is passed in, a default message is used.
 ``ValidateIfOtherFieldEquals``
     Takes three parameters: ``other_field``, ``other_value`` and
     ``validator_list``, in that order. If ``other_field`` has a value of
-    ``other_vaue``, then the validators in ``validator_list`` are all run
+    ``other_value``, then the validators in ``validator_list`` are all run
     against the current field.
 
 ``RequiredIfOtherFieldNotGiven``
diff --git a/docs/generic_views.txt b/docs/generic_views.txt
index fdab97de27..99a9b7cf6b 100644
--- a/docs/generic_views.txt
+++ b/docs/generic_views.txt
@@ -184,7 +184,7 @@ a date in the *future* are not included unless you set ``allow_future`` to
       the view's template. See the `RequestContext docs`_.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
@@ -270,7 +270,7 @@ to ``True``.
       this is ``False``.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
@@ -357,7 +357,7 @@ date in the *future* are not displayed unless you set ``allow_future`` to
        determining the variable's name.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
@@ -438,7 +438,7 @@ in the *future* are not displayed unless you set ``allow_future`` to ``True``.
        determining the variable's name.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
@@ -523,7 +523,7 @@ you set ``allow_future`` to ``True``.
        determining the variable's name.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
@@ -633,7 +633,7 @@ future, the view will throw a 404 error by default, unless you set
        to use in the template context. By default, this is ``'object'``.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
     * ``allow_future``: A boolean specifying whether to include "future"
       objects on this page, where "future" means objects in which the field
@@ -707,7 +707,7 @@ A page representing a list of objects.
        determining the variable's name.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
 **Template name:**
 
@@ -819,7 +819,7 @@ A page representing an individual object.
        to use in the template context. By default, this is ``'object'``.
 
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
-      to the value of the ``DEFAULT_MIME_TYPE`` setting.
+      to the value of the ``DEFAULT_CONTENT_TYPE`` setting.
 
 **Template name:**
 
diff --git a/docs/install.txt b/docs/install.txt
index fb1bd73122..ff8e1a8318 100644
--- a/docs/install.txt
+++ b/docs/install.txt
@@ -84,9 +84,12 @@ Installing the official version
 
 Note that the last command will automatically download and install setuptools_
 if you don't already have it installed. This requires a working Internet
+connection and may cause problems on Python 2.5. If you run into problems,
+try using our development version by following the instructions below. The
+development version no longer uses setuptools nor requires an Internet
 connection.
 
-This will install Django in your Python installation's ``site-packages``
+The command will install Django in your Python installation's ``site-packages``
 directory.
 
 .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
@@ -94,19 +97,34 @@ directory.
 Installing the development version
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+If you'd like to be able to update your Django code occasionally with the
+latest bug fixes and improvements, follow these instructions:
+
 1. Make sure you have Subversion_ installed.
-2. ``svn co http://code.djangoproject.com/svn/django/trunk/ django_src``
-3. Symlink ``django_src/django`` so that ``django`` is within your Python
-   ``site-packages`` directory:
+2. Check out the Django code into your Python ``site-packages`` directory.
+   On Linux / Mac OSX / Unix, do this::
 
-   ``ln -s `pwd`/django_src/django /usr/lib/python2.3/site-packages/django``
+       svn co http://code.djangoproject.com/svn/django/trunk/ django_src
+       ln -s `pwd`/django_src/django /usr/lib/python2.3/site-packages/django
 
    (In the above line, change ``python2.3`` to match your current Python version.)
 
-You don't have to run ``python setup.py install``.
+   On Windows, do this::
+
+       svn co http://code.djangoproject.com/svn/django/trunk/django c:\Python24\lib\site-packages\django
+
+4. Copy the file ``django_src/django/bin/django-admin.py`` to somewhere on your
+   system path, such as ``/usr/local/bin`` (Unix) or ``C:\Python24\Scripts``
+   (Windows). This step simply lets you type ``django-admin.py`` from within
+   any directory, rather than having to qualify the command with the full path
+   to the file.
+
+You *don't* have to run ``python setup.py install``, because that command
+takes care of steps 3 and 4 for you.
 
-When you want to update your code, just run the command ``svn update`` from
-within the ``django_src`` directory.
+When you want to update your copy of the Django source code, just run the
+command ``svn update`` from within the ``django`` directory. When you do this,
+Subversion will automatically download any changes.
 
 .. _`download page`: http://www.djangoproject.com/download/
 .. _Subversion: http://subversion.tigris.org/
diff --git a/docs/model-api.txt b/docs/model-api.txt
index c6c4200239..1aa8c811f4 100644
--- a/docs/model-api.txt
+++ b/docs/model-api.txt
@@ -188,7 +188,8 @@ JavaScript shortcuts.
 ~~~~~~~~~~~~~~
 
 A ``CharField`` that checks that the value is a valid e-mail address.
-This doesn't accept ``maxlength``.
+This doesn't accept ``maxlength``; its ``maxlength`` is automatically set to
+75.
 
 ``FileField``
 ~~~~~~~~~~~~~
@@ -545,7 +546,7 @@ The default value for the field.
 
 If ``False``, the field will not be editable in the admin or via form
 processing using the object's ``AddManipulator`` or ``ChangeManipulator``
-classes. Default is  ``True``.
+classes. Default is ``True``.
 
 ``help_text``
 ~~~~~~~~~~~~~
diff --git a/docs/release_notes_0.95.txt b/docs/release_notes_0.95.txt
index e5b89e5a7a..3709cacf5a 100644
--- a/docs/release_notes_0.95.txt
+++ b/docs/release_notes_0.95.txt
@@ -110,7 +110,7 @@ many common questions appear with some regularity, and any particular problem
 may already have been answered.
 
 Finally, for those who prefer the more immediate feedback offered by IRC,
-there's a #django channel or irc.freenode.net that is regularly populated by
+there's a #django channel on irc.freenode.net that is regularly populated by
 Django users and developers from around the world. Friendly people are usually
 available at any hour of the day -- to help, or just to chat.
 
diff --git a/docs/request_response.txt b/docs/request_response.txt
index 1f3b9d5804..006ac6b648 100644
--- a/docs/request_response.txt
+++ b/docs/request_response.txt
@@ -341,9 +341,9 @@ hard-coded strings. If you use this technique, follow these guidelines:
 Methods
 -------
 
-``__init__(content='', mimetype=DEFAULT_MIME_TYPE)``
+``__init__(content='', mimetype=DEFAULT_CONTENT_TYPE)``
     Instantiates an ``HttpResponse`` object with the given page content (a
-    string) and MIME type. The ``DEFAULT_MIME_TYPE`` is ``'text/html'``.
+    string) and MIME type. The ``DEFAULT_CONTENT_TYPE`` is ``'text/html'``.
 
     ``content`` can be an iterator or a string. If it's an iterator, it should
     return strings, and those strings will be joined together to form the
diff --git a/docs/serialization.txt b/docs/serialization.txt
index 694e2d25db..aee1b9a3bb 100644
--- a/docs/serialization.txt
+++ b/docs/serialization.txt
@@ -3,12 +3,12 @@ Serializing Django objects
 ==========================
 
 .. note::
-    
+
     This API is currently under heavy development and may change --
     perhaps drastically -- in the future.
-    
+
     You have been warned.
-    
+
 Django's serialization framework provides a mechanism for "translating" Django
 objects into other formats. Usually these other formats will be text-based and
 used for sending Django objects over a wire, but it's possible for a
@@ -21,7 +21,7 @@ At the highest level, serializing data is a very simple operation::
 
     from django.core import serializers
     data = serializers.serialize("xml", SomeModel.objects.all())
-    
+
 The arguments to the ``serialize`` function are the format to serialize the
 data to (see `Serialization formats`_) and a QuerySet_ to serialize.
 (Actually, the second argument can be any iterator that yields Django objects,
@@ -34,7 +34,7 @@ You can also use a serializer object directly::
     xml_serializer = serializers.get_serializer("xml")
     xml_serializer.serialize(queryset)
     data = xml_serializer.getvalue()
-    
+
 This is useful if you want to serialize data directly to a file-like object
 (which includes a HTTPResponse_)::
 
@@ -50,7 +50,7 @@ Deserializing data is also a fairly simple operation::
 
     for obj in serializers.deserialize("xml", data):
         do_something_with(obj)
-    
+
 As you can see, the ``deserialize`` function takes the same format argument as
 ``serialize``, a string or stream of data, and returns an iterator.
 
@@ -69,7 +69,7 @@ something like::
     for deserialized_object in serializers.deserialize("xml", data):
         if object_should_be_saved(deserialized_object):
             obj.save()
-            
+
 In other words, the usual use is to examine the deserialized objects to make
 sure that they are "appropriate" for saving before doing so.  Of course, if you trust your data source you could just save the object and move on.
 
@@ -89,22 +89,22 @@ Django "ships" with a few included serializers:
                 bundled with Django).
 
     ``python``  Translates to and from "simple" Python objects (lists, dicts,
-                strings, etc.).  Not really all that useful on its own, but 
+                strings, etc.).  Not really all that useful on its own, but
                 used as a base for other serializers.
     ==========  ==============================================================
 
 .. _json: http://json.org/
 .. _simplejson: http://undefined.org/python/#simplejson
 
-Notes For Specific Serialization Formats
+Notes for specific serialization formats
 ----------------------------------------
 
 json
 ~~~~
 
-If you are using UTF-8 (or any other non-ASCII encoding) data with the JSON
+If you're using UTF-8 (or any other non-ASCII encoding) data with the JSON
 serializer, you must pass ``ensure_ascii=False`` as a parameter to the
-``serialize()`` call. Otherwise the output will not be encoded correctly.
+``serialize()`` call. Otherwise, the output won't be encoded correctly.
 
 For example::
 
diff --git a/docs/settings.txt b/docs/settings.txt
index 65113b3c30..0e808c018b 100644
--- a/docs/settings.txt
+++ b/docs/settings.txt
@@ -401,15 +401,6 @@ Subject-line prefix for e-mail messages sent with ``django.core.mail.mail_admins
 or ``django.core.mail.mail_managers``. You'll probably want to include the
 trailing space.
 
-ENABLE_PSYCO
-------------
-
-Default: ``False``
-
-Whether to enable Psyco, which optimizes Python code. Requires Psyco_.
-
-.. _Psyco: http://psyco.sourceforge.net/
-
 IGNORABLE_404_ENDS
 ------------------
 
@@ -599,8 +590,11 @@ See also ``APPEND_SLASH``.
 PROFANITIES_LIST
 ----------------
 
-A list of profanities that will trigger a validation error when the
-``hasNoProfanities`` validator is called.
+A tuple of profanities, as strings, that will trigger a validation error when
+the ``hasNoProfanities`` validator is called.
+
+We don't list the default values here, because that would be profane. To see
+the default values, see the file ``django/conf/global_settings.py``.
 
 ROOT_URLCONF
 ------------
diff --git a/docs/templates.txt b/docs/templates.txt
index c9e76d6c94..b263a64aec 100644
--- a/docs/templates.txt
+++ b/docs/templates.txt
@@ -540,6 +540,11 @@ The arguments can be hard-coded strings, so the following is valid::
         ...
     {% endifequal %}
 
+It is only possible to compare an argument to template variables or strings.
+You cannot check for equality with Python objects such as ``True`` or
+``False``.  If you need to test if something is true or false, use the ``if``
+and ``ifnot`` tags instead.
+
 ifnotequal
 ~~~~~~~~~~
 
@@ -1051,7 +1056,7 @@ Formats a date as the time since that date (i.e. "4 days, 6 hours").
 Takes an optional argument that is a variable containing the date to use as
 the comparison point (without the argument, the comparison point is *now*).
 For example, if ``blog_date`` is a date instance representing midnight on 1
-June 2006, and ``comment_date`` is a date instanace for 08:00 on 1 June 2006,
+June 2006, and ``comment_date`` is a date instance for 08:00 on 1 June 2006,
 then ``{{ comment_date|timesince:blog_date }}`` would return "8 hours".
 
 timeuntil
diff --git a/docs/templates_python.txt b/docs/templates_python.txt
index bc05d769ad..81e7d45133 100644
--- a/docs/templates_python.txt
+++ b/docs/templates_python.txt
@@ -212,6 +212,21 @@ template tags. If an invalid variable is provided to one of these template
 tags, the variable will be interpreted as ``None``. Filters are always
 applied to invalid variables within these template tags.
 
+.. admonition:: For debug purposes only!
+
+    While ``TEMPLATE_STRING_IF_INVALID`` can be a useful debugging tool, 
+    it is a bad idea to turn it on as a 'development default'. 
+    
+    Many templates, including those in the Admin site, rely upon the 
+    silence of the template system when a non-existent variable is 
+    encountered. If you assign a value other than ``''`` to
+    ``TEMPLATE_STRING_IF_INVALID``, you will experience rendering 
+    problems with these templates and sites.
+    
+    Generally, ``TEMPLATE_STRING_IF_INVALID`` should only be enabled 
+    in order to debug a specific template problem, then cleared 
+    once debugging is complete.
+        
 Playing with Context objects
 ----------------------------
 
@@ -296,6 +311,20 @@ optional, third positional argument, ``processors``. In this example, the
             'foo': 'bar',
         }, [ip_address_processor])
 
+Note::
+    If you are using Django's ``render_to_response()`` shortcut to populate a
+    template with the contents of a dictionary, your template will be passed a
+    ``Context`` instance by default (not a ``RequestContext``). If you wish to
+    use a ``RequestContext`` in your template rendering, you need to pass an
+    optional third argument to ``render_to_response()``: a ``RequestContext``
+    instance. Your code might look like this::
+
+        def some_view(request):
+            # ...
+            return render_to_response('my_template'html',
+                                      my_data_dictionary,
+                                      context_instance = RequestContext(request))
+
 Here's what each of the default processors does:
 
 .. _HttpRequest object: http://www.djangoproject.com/documentation/request_response/#httprequest-objects
@@ -366,6 +395,18 @@ If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
 `HttpRequest object`_. Note that this processor is not enabled by default;
 you'll have to activate it.
 
+Writing your own context processors
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A context processor has a very simple interface: It's just a Python function
+that takes one argument, an ``HttpRequest`` object, and returns a dictionary
+that gets added to the template context. Each context processor *must* return
+a dictionary.
+
+Custom context processors can live anywhere in your code base. All Django cares
+about is that your custom context processors are pointed-to by your
+``TEMPLATE_CONTEXT_PROCESSORS`` setting.
+
 Loading templates
 -----------------
 
@@ -805,7 +846,7 @@ Inclusion tags
 
 Another common type of template tag is the type that displays some data by
 rendering *another* template. For example, Django's admin interface uses custom
-template tags to display the buttons along the botton of the "add/change" form
+template tags to display the buttons along the bottom of the "add/change" form
 pages. Those buttons always look the same, but the link targets change depending
 on the object being edited -- so they're a perfect case for using a small
 template that is filled with details from the current object. (In the admin's
diff --git a/docs/testing.txt b/docs/testing.txt
index b1ede3e4cc..19eef9f071 100644
--- a/docs/testing.txt
+++ b/docs/testing.txt
@@ -389,7 +389,7 @@ an alternative framework as if they were normal Django tests.
 
 When you run ``./manage.py test``, Django looks at the ``TEST_RUNNER``
 setting to determine what to do. By default, ``TEST_RUNNER`` points to ``django.test.simple.run_tests``. This method defines the default Django
-testing behaviour. This behaviour involves:
+testing behavior. This behavior involves:
 
 #. Performing global pre-test setup
 #. Creating the test database
@@ -435,7 +435,7 @@ a number of utility methods in the ``django.test.utils`` module.
 ``create_test_db(verbosity=1, autoclobber=False)``
     Creates a new test database, and run ``syncdb`` against it.
 
-    ``verbosity`` has the same behaviour as in the test runner.
+    ``verbosity`` has the same behavior as in the test runner.
 
     ``Autoclobber`` describes the behavior that will occur if a database with
     the same name as the test database is discovered. If ``autoclobber`` is False,
@@ -450,4 +450,4 @@ a number of utility methods in the ``django.test.utils`` module.
     Destroys the database with the name ``settings.DATABASE_NAME`` matching,
     and restores the value of ``settings.DATABASE_NAME`` to the provided name.
 
-    ``verbosity`` has the same behaviour as in the test runner.
+    ``verbosity`` has the same behavior as in the test runner.
diff --git a/docs/tutorial02.txt b/docs/tutorial02.txt
index bc1717e67c..06cde251e5 100644
--- a/docs/tutorial02.txt
+++ b/docs/tutorial02.txt
@@ -377,7 +377,7 @@ By default, ``TEMPLATE_DIRS`` is empty. So, let's add a line to it, to tell
 Django where our templates live::
 
     TEMPLATE_DIRS = (
-        "/home/mytemplates", # Change this to your own directory.
+        "/home/my_username/mytemplates", # Change this to your own directory.
     )
 
 Now copy the template ``admin/base_site.html`` from within the default Django
diff --git a/docs/tutorial03.txt b/docs/tutorial03.txt
index 248d234043..c4c1b4c546 100644
--- a/docs/tutorial03.txt
+++ b/docs/tutorial03.txt
@@ -91,7 +91,7 @@ Finally, it calls that ``detail()`` function like so::
 The ``poll_id='23'`` part comes from ``(?P<poll_id>\d+)``. Using parenthesis around a
 pattern "captures" the text matched by that pattern and sends it as an argument
 to the view function; the ``?P<poll_id>`` defines the name that will be used to
-identify the matched pattern; and ``\d+`` is a regular experession to match a sequence of
+identify the matched pattern; and ``\d+`` is a regular expression to match a sequence of
 digits (i.e., a number).
 
 Because the URL patterns are regular expressions, there really is no limit on
@@ -257,7 +257,7 @@ provides a shortcut. Here's the full ``index()`` view, rewritten::
     from mysite.polls.models import Poll
 
     def index(request):
-        latest_poll_list = Poll.objects.all().order_by('-pub_date')
+        latest_poll_list = Poll.objects.all().order_by('-pub_date')[:5]
         return render_to_response('polls/index.html', {'latest_poll_list': latest_poll_list})
 
 Note that we no longer need to import ``loader``, ``Context`` or
diff --git a/docs/tutorial04.txt b/docs/tutorial04.txt
index f234ed0ce1..c5e2ea3cea 100644
--- a/docs/tutorial04.txt
+++ b/docs/tutorial04.txt
@@ -207,7 +207,7 @@ for the polls app, we manually specify a template name for the results view:
 template. Note that we use ``dict()`` to return an altered dictionary in place.
 
 In previous parts of the tutorial, the templates have been provided with a context
-that contains the ``poll` and ``latest_poll_list`` context variables. However,
+that contains the ``poll`` and ``latest_poll_list`` context variables. However,
 the generic views provide the variables ``object`` and ``object_list`` as context.
 Therefore, you need to change your templates to match the new context variables.
 Go through your templates, and modify any reference to ``latest_poll_list`` to