[soc2009/model-validation] Merged to trunk at r11603

SECURITY ALERT: Corrected regular expressions for URL and email fields.

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/model-validation@11617 bcc190cf-cafb-0310-a4f2-bffc1f526a37

20 files changed, 197 insertions, 114 deletions

diff --git a/docs/howto/static-files.txt b/docs/howto/static-files.txt
index 43062bebb6..9e6511a743 100644
--- a/docs/howto/static-files.txt
+++ b/docs/howto/static-files.txt
@@ -126,7 +126,7 @@ Here's the default ``static/directory_index.html`` template:
     listings. The template that was loaded had to be called
     ``static/directory_listing`` (with no ``.html`` extension). For backwards
     compatibility with earlier versions, Django will still load templates with
-    the older (no extension) name, but it will prefer a the
+    the older (no extension) name, but it will prefer the
     ``directory_index.html`` version.
 
 Limiting use to DEBUG=True
diff --git a/docs/internals/index.txt b/docs/internals/index.txt
index 1cbbb87f06..4f9007705e 100644
--- a/docs/internals/index.txt
+++ b/docs/internals/index.txt
@@ -23,3 +23,4 @@ the hood".
    committers
    release-process
    deprecation
+   svn
diff --git a/docs/internals/svn.txt b/docs/internals/svn.txt
index 7d010a7cfa..372fbd1202 100644
--- a/docs/internals/svn.txt
+++ b/docs/internals/svn.txt
@@ -114,14 +114,9 @@ not; in either case there comes a time when the branch is no longer
 being actively worked on by any developer. At this point the branch is
 considered closed.
 
-Unfortunately, Subversion has no standard way of indicating
-this. Generally, you can recognize a dead branch by viewing it through
-the web interface, which lists the date of the most recent change to
-the branch. Branches which have gone more than a month or two with no
-activity can usually be assumed to be closed. In the future, the
-layout of branches in the repository may be rearranged to make it
-easier to tell which branches are still active (e.g., by moving closed
-or abandoned branches into the ``django/branches/attic`` directory).
+Unfortunately, Subversion has no standard way of indicating this. As a
+workaround, branches of Django which are closed and no longer
+maintained are moved into the directory ``django/branches/attic``.
 
 For reference, the following are branches whose code eventually became
 part of Django itself, and so are no longer separately maintained:
@@ -184,6 +179,9 @@ were never finished:
 
 * ``sqlalchemy``
 
+All of the above-mentioned branches now reside in
+``django/branches/attic``.
+
 
 Support and bugfix branches
 ---------------------------
@@ -201,7 +199,7 @@ will be created there approximately one month after each new Django
 release. For example, shortly after the release of Django 1.0, the
 branch ``django/branches/releases/1.0.X`` was created to receive bug
 fixes, and shortly after the release of Django 1.1 the branch
-``django/branches/releases/1.1.X`` will be created.
+``django/branches/releases/1.1.X`` was created.
 
 Prior to the Django 1.0 release, these branches were maintaind within
 the top-level ``django/branches`` directory, and so the following
diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index ae4af665f1..69c8d0f3db 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -643,8 +643,7 @@ Save these changes and start a new Python interactive shell by running
     >>> Poll.objects.filter(question__startswith='What')
     [<Poll: What's up?>]
 
-    # Get the poll whose year is 2007. Of course, if you're going through this
-    # tutorial in another year, change as appropriate.
+    # Get the poll whose year is 2007.
     >>> Poll.objects.get(pub_date__year=2007)
     <Poll: What's up?>
 
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
index 584672e4f0..c1e05eda1d 100644
--- a/docs/ref/contrib/admin/index.txt
+++ b/docs/ref/contrib/admin/index.txt
@@ -25,21 +25,26 @@ Django's admin interface.
 Overview
 ========
 
-There are five steps in activating the Django admin site:
+There are six steps in activating the Django admin site:
 
-    1. Add ``django.contrib.admin`` to your ``INSTALLED_APPS`` setting.
+    1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS`
+       setting.
 
-    2. Determine which of your application's models should be editable in the
+    2. Admin has two dependencies - ``django.contrib.auth`` and
+       ``django.contrib.contenttypes``. If these applications are not
+       in your :setting:`INSTALLED_APPS` list, add them.
+
+    3. Determine which of your application's models should be editable in the
        admin interface.
 
-    3. For each of those models, optionally create a ``ModelAdmin`` class that
+    4. For each of those models, optionally create a ``ModelAdmin`` class that
        encapsulates the customized admin functionality and options for that
        particular model.
 
-    4. Instantiate an ``AdminSite`` and tell it about each of your models and
+    5. Instantiate an ``AdminSite`` and tell it about each of your models and
        ``ModelAdmin`` classes.
 
-    5. Hook the ``AdminSite`` instance into your URLconf.
+    6. Hook the ``AdminSite`` instance into your URLconf.
 
 Other topics
 ------------
@@ -845,7 +850,7 @@ the admin application URL dispatching handler to render the pages that deal
 with model instances CRUD operations. As a result, completely overriding these
 methods will significantly change the behavior of the admin application.
 
-One comon reason for overriding these methods is to augment the context data
+One common reason for overriding these methods is to augment the context data
 that is provided to the template that renders the view. In the following
 example, the change view is overridden so that the rendered template is
 provided some extra mapping data that would not otherwise be available::
diff --git a/docs/ref/contrib/comments/index.txt b/docs/ref/contrib/comments/index.txt
index f6e1553bac..880be34101 100644
--- a/docs/ref/contrib/comments/index.txt
+++ b/docs/ref/contrib/comments/index.txt
@@ -24,13 +24,13 @@ Quick start guide
 
 To get started using the ``comments`` app, follow these steps:
 
-    #. Install the comments framework by adding ``'django.contrib.comments'`` to    
+    #. Install the comments framework by adding ``'django.contrib.comments'`` to
        :setting:`INSTALLED_APPS`.
 
     #. Run ``manage.py syncdb`` so that Django will create the comment tables.
 
     #. Add the comment app's URLs to your project's ``urls.py``:
-   
+
        .. code-block:: python
 
             urlpatterns = patterns('',
@@ -41,9 +41,9 @@ To get started using the ``comments`` app, follow these steps:
 
     #. Use the `comment template tags`_ below to embed comments in your
        templates.
-    
+
 You might also want to examine :ref:`ref-contrib-comments-settings`.
-    
+
 Comment template tags
 =====================
 
@@ -67,20 +67,20 @@ different ways you can specify which object to attach to:
     #. Refer to the object directly -- the more common method. Most of the
        time, you'll have some object in the template's context you want
        to attach the comment to; you can simply use that object.
-       
-       For example, in a blog entry page that has a variable named ``entry``, 
+
+       For example, in a blog entry page that has a variable named ``entry``,
        you could use the following to load the number of comments::
-       
+
             {% get_comment_count for entry as comment_count %}.
-            
+
     #. Refer to the object by content-type and object id. You'd use this method
        if you, for some reason, don't actually have direct access to the object.
-       
+
        Following the above example, if you knew the object ID was ``14`` but
        didn't have access to the actual object, you could do something like::
-       
+
             {% get_comment_count for blog.entry 14 as comment_count %}
-            
+
        In the above, ``blog.entry`` is the app label and (lower-cased) model
        name of the model class.
 
@@ -89,7 +89,7 @@ different ways you can specify which object to attach to:
 Displaying comments
 -------------------
 
-To get a the list of comments for some object, use :ttag:`get_comment_list`::
+To get the list of comments for some object, use :ttag:`get_comment_list`::
 
     {% get_comment_list for [object] as [varname] %}
 
@@ -99,7 +99,7 @@ For example::
     {% for comment in comment_list %}
         ...
     {% endfor %}
-    
+
 This returns a list of :class:`~django.contrib.comments.models.Comment` objects;
 see :ref:`the comment model documentation <ref-contrib-comments-models>` for
 details.
@@ -116,9 +116,9 @@ To count comments attached to an object, use :ttag:`get_comment_count`::
 For example::
 
         {% get_comment_count for event as comment_count %}
-        
+
         <p>This event has {{ comment_count }} comments.</p>
-        
+
 
 Displaying the comment post form
 --------------------------------
@@ -153,7 +153,7 @@ If you want more control over the look and feel of the comment form, you use use
 you can use in the template::
 
     {% get_comment_form for [object] as [varname] %}
-    
+
 A complete form might look like::
 
     {% get_comment_form for event as form %}
@@ -164,7 +164,7 @@ A complete form might look like::
         <td><input type="submit" name="preview" class="submit-post" value="Preview"></td>
       </tr>
     </form>
-    
+
 Be sure to read the `notes on the comment form`_, below, for some special
 considerations you'll need to make if you're using this approach.
 
@@ -185,7 +185,7 @@ Redirecting after the comment post
 
 To specify the URL you want to redirect to after the comment has been posted,
 you can include a hidden form input called ``next`` in your comment form. For example::
- 
+
     <input type="hidden" name="next" value="{% url my_comment_was_posted %}" />
 
 .. _notes-on-the-comment-form:
@@ -198,24 +198,24 @@ should know about:
 
     * It contains a number of hidden fields that contain timestamps, information
       about the object the comment should be attached to, and a "security hash"
-      used to validate this information. If someone tampers with this data -- 
+      used to validate this information. If someone tampers with this data --
       something comment spammers will try -- the comment submission will fail.
-      
+
       If you're rendering a custom comment form, you'll need to make sure to
       pass these values through unchanged.
-      
+
     * The timestamp is used to ensure that "reply attacks" can't continue very
       long. Users who wait too long between requesting the form and posting a
       comment will have their submissions refused.
-      
+
     * The comment form includes a "honeypot_" field. It's a trap: if any data is
       entered in that field, the comment will be considered spam (spammers often
       automatically fill in all fields in an attempt to make valid submissions).
-      
+
       The default form hides this field with a piece of CSS and further labels
       it with a warning field; if you use the comment form with a custom
       template you should be sure to do the same.
-    
+
 .. _honeypot: http://en.wikipedia.org/wiki/Honeypot_(computing)
 
 More information
@@ -230,4 +230,4 @@ More information
    upgrade
    custom
    forms
-   moderation
\ No newline at end of file
+   moderation
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 177df12862..0cb5be4b92 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -844,7 +844,7 @@ define the details of how the relation works.
     current date/time to be chosen.
 
     Instead of a dictionary this can also be a :class:`~django.db.models.Q`
-    object (an object with a :meth:`get_sql` method) for more complex queries.
+    object for more :ref:`complex queries <complex-lookups-with-q>`.
 
     ``limit_choices_to`` has no effect on the inline FormSets that are created
     to display related objects in the admin.
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
index 8402567f7a..9bf73f5b85 100644
--- a/docs/ref/models/options.txt
+++ b/docs/ref/models/options.txt
@@ -19,6 +19,17 @@ Available ``Meta`` options
 
 If ``True``, this model will be an :ref:`abstract base class <abstract-base-classes>`.
 
+``app_label``
+-------------
+
+.. attribute:: Options.app_label
+
+If a model exists outside of the standard :file:`models.py` (for instance, if
+the app's models are in submodules of ``myapp.models``), the model must define
+which app it is part of::
+
+    app_label = 'myapp'
+
 ``db_table``
 ------------
 
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index f78ebc506a..efd7c549b8 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -20,7 +20,7 @@ Throughout this reference we'll use the :ref:`example weblog models
 When QuerySets are evaluated
 ============================
 
-Internally, a ``QuerySet`` can be constructed, filter, sliced, and generally
+Internally, a ``QuerySet`` can be constructed, filtered, sliced, and generally
 passed around without actually hitting the database. No database activity
 actually occurs until you do something to evaluate the queryset.
 
@@ -1512,9 +1512,10 @@ regex
 
 Case-sensitive regular expression match.
 
-The regular expression syntax is that of the database backend in use. In the
-case of SQLite, which doesn't natively support regular-expression lookups, the
-syntax is that of Python's ``re`` module.
+The regular expression syntax is that of the database backend in use.
+In the case of SQLite, which has no built in regular expression support,
+this feature is provided by a (Python) user-defined REGEXP function, and
+the regular expression syntax is therefore that of Python's ``re`` module.
 
 Example::
 
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 9df156a6f2..77d991bc1f 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -262,7 +262,7 @@ a subclass of dictionary. Exceptions are outlined here:
 
     Returns the value for the given key. If the key has more than one value,
     ``__getitem__()`` returns the last value. Raises
-    ``django.utils.datastructure.MultiValueDictKeyError`` if the key does not
+    ``django.utils.datastructures.MultiValueDictKeyError`` if the key does not
     exist. (This is a subclass of Python's standard ``KeyError``, so you can
     stick to catching ``KeyError``.)
 
@@ -310,7 +310,7 @@ a subclass of dictionary. Exceptions are outlined here:
            >>> q = QueryDict('a=1&a=2&a=3')
            >>> q.items()
            [('a', '3')]
-           
+
 .. method:: QueryDict.iteritems()
 
     Just like the standard dictionary ``iteritems()`` method. Like
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index 87e1ce3b77..cc203f1817 100644
--- a/docs/ref/signals.txt
+++ b/docs/ref/signals.txt
@@ -8,6 +8,9 @@ A list of all the signals that Django sends.
 
 .. seealso::
 
+    See the documentation on the :ref:`signal dispatcher <topics-signals>` for
+    information regarding how to register for and receive signals.
+
     The :ref:`comment framework <ref-contrib-comments-index>` sends a :ref:`set
     of comment-related signals <ref-contrib-comments-signals>`.
 
@@ -98,7 +101,7 @@ pre_save
 
 .. data:: django.db.models.signals.pre_save
    :module:
-   
+
 This is sent at the beginning of a model's :meth:`~django.db.models.Model.save`
 method.
 
@@ -114,8 +117,8 @@ post_save
 ---------
 
 .. data:: django.db.models.signals.post_save
-   :module: 
-   
+   :module:
+
 Like :data:`pre_save`, but sent at the end of the
 :meth:`~django.db.models.Model.save` method.
 
@@ -135,7 +138,7 @@ pre_delete
 
 .. data:: django.db.models.signals.pre_delete
    :module:
-   
+
 Sent at the beginning of a model's :meth:`~django.db.models.Model.delete`
 method.
 
@@ -151,8 +154,8 @@ post_delete
 -----------
 
 .. data:: django.db.models.signals.post_delete
-   :module: 
-   
+   :module:
+
 Like :data:`pre_delete`, but sent at the end of the
 :meth:`~django.db.models.Model.delete` method.
 
@@ -172,7 +175,7 @@ class_prepared
 
 .. data:: django.db.models.signals.class_prepared
    :module:
-   
+
 Sent whenever a model class has been "prepared" -- that is, once model has
 been defined and registered with Django's model system. Django uses this
 signal internally; it's not generally used in third-party applications.
@@ -241,8 +244,8 @@ request_started
 ---------------
 
 .. data:: django.core.signals.request_started
-   :module: 
-   
+   :module:
+
 Sent when Django begins processing an HTTP request.
 
 Arguments sent with this signal:
@@ -258,7 +261,7 @@ request_finished
 
 .. data:: django.core.signals.request_finished
    :module:
-   
+
 Sent when Django finishes processing an HTTP request.
 
 Arguments sent with this signal:
@@ -271,7 +274,7 @@ got_request_exception
 
 .. data:: django.core.signals.got_request_exception
    :module:
-   
+
 This signal is sent whenever Django encounters an exception while processing an incoming HTTP request.
 
 Arguments sent with this signal:
@@ -295,7 +298,7 @@ template_rendered
 
 .. data:: django.test.signals.template_rendered
    :module:
-   
+
 Sent when the test system renders a template. This signal is not emitted during
 normal operation of a Django server -- it is only available during testing.
 
diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt
index 5af2e17449..cd4bdc5e96 100644
--- a/docs/releases/1.1.txt
+++ b/docs/releases/1.1.txt
@@ -21,7 +21,7 @@ Django has a policy of :ref:`API stability <misc-api-stability>`. This means
 that, in general, code you develop against Django 1.0 should continue to work
 against 1.1 unchanged. However, we do sometimes make backwards-incompatible
 changes if they're necessary to resolve bugs, and there are a handful of such
-(minor) changes between Django 1.0 and Django 1.1. 
+(minor) changes between Django 1.0 and Django 1.1.
 
 Before upgrading to Django 1.1 you should double-check that the following
 changes don't impact you, and upgrade your code if they do.
@@ -41,12 +41,12 @@ However, **users on 64-bit platforms may experience some problems** using the
 would generate a 64-bit, 16 character digest in the constraint name; for
 example::
 
-    ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ... 
-    
+    ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...
+
 Following this change, all platforms, regardless of word size, will generate a
 32-bit, 8 character digest in the constraint name; for example::
 
-    ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ... 
+    ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...
 
 As a result of this change, you will not be able to use the :djadmin:`reset`
 management command on any table made by a 64-bit machine. This is because the
@@ -94,13 +94,13 @@ other than raise a ``DeprecationWarning``.
 If you've been relying on this middleware, the easiest upgrade path is:
 
     * Examine `the code as it existed before it was removed`__.
-    
+
     * Verify that it works correctly with your upstream proxy, modifying
       it to support your particular proxy (if necessary).
-      
+
     * Introduce your modified version of ``SetRemoteAddrFromForwardedFor`` as a
       piece of middleware in your own project.
-    
+
 __ http://code.djangoproject.com/browser/django/trunk/django/middleware/http.py?rev=11000#L33
 
 Names of uploaded files are available later
@@ -115,7 +115,7 @@ it was available in a model's pre-save signal handler.
 
 In Django 1.1 the file is saved as part of saving the model in the database, so
 the actual file name used on disk cannot be relied on until *after* the model
-has been saved saved.
+has been saved.
 
 Changes to how model formsets are saved
 ---------------------------------------
@@ -132,8 +132,8 @@ public methods.
 Fixed the ``join`` filter's escaping behavior
 ---------------------------------------------
 
-The :ttag:`join` filter no longer escapes the literal value that is 
-passed in for the connector. 
+The :ttag:`join` filter no longer escapes the literal value that is
+passed in for the connector.
 
 This is backwards incompatible for the special situation of the literal string
 containing one of the five special HTML characters. Thus, if you were writing
@@ -157,13 +157,13 @@ One feature has been marked as deprecated in Django 1.1:
 
     * You should no longer use ``AdminSite.root()`` to register that admin
       views. That is, if your URLconf contains the line::
-      
+
             (r'^admin/(.*)', admin.site.root),
-            
+
       You should change it to read::
-        
+
             (r'^admin/', include(admin.site.urls)),
-            
+
 You should begin to remove use of this features from your code immediately.
 
 ``AdminSite.root`` will will raise a ``PendingDeprecationWarning`` if used in
@@ -289,7 +289,7 @@ test client:
     * The test :class:`Client` now can automatically follow redirects with the
       ``follow`` argument to :meth:`Client.get` and :meth:`Client.post`. This
       makes testing views that issue redirects simpler.
-      
+
     * It's now easier to get at the template context in the response returned
       the test client: you'll simply access the context as
       ``request.context[key]``. The old way, which treats ``request.context`` as
@@ -351,13 +351,13 @@ features:
 
     * Support for SpatiaLite_ -- a spatial database for SQLite -- as a spatial
       backend.
-      
+
     * Geographic aggregates (``Collect``, ``Extent``, ``MakeLine``, ``Union``)
       and ``F`` expressions.
-    
+
     * New ``GeoQuerySet`` methods: ``collect``, ``geojson``, and
       ``snap_to_grid``.
-      
+
     * A new list interface methods for ``GEOSGeometry`` objects.
 
 For more details, see the `GeoDjango documentation`_.
@@ -412,23 +412,23 @@ Other new features and changes introduced since Django 1.0 include:
 * The :djadmin:`dumpdata` management command now accepts individual
   model names as arguments, allowing you to export the data just from
   particular models.
-  
+
 * There's a new :tfilter:`safeseq` template filter which works just like
   :tfilter:`safe` for lists, marking each item in the list as safe.
-  
+
 * :ref:`Cache backends <topics-cache>` now support ``incr()`` and
   ``decr()`` commands to increment and decrement the value of a cache key.
   On cache backends that support atomic increment/decrement -- most
   notably, the memcached backend -- these operations will be atomic, and
   quite fast.
-  
+
 * Django now can :ref:`easily delegate authentication to the web server
   <howto-auth-remote-user>` via a new authentication backend that supports
   the standard ``REMOTE_USER`` environment variable used for this purpose.
-  
+
 * There's a new :func:`django.shortcuts.redirect` function that makes it
   easier to issue redirects given an object, a view name, or a URL.
-  
+
 * The ``postgresql_psycopg2`` backend now supports :ref:`native PostgreSQL
   autocommit <postgresql-notes>`. This is an advanced, PostgreSQL-specific
   feature, that can make certain read-heavy applications a good deal
@@ -448,7 +448,7 @@ mailing list:
 join the discussions!
 
 Django's online documentation also includes pointers on how to contribute to
-Django: 
+Django:
 
     * :ref:`How to contribute to Django <internals-contributing>`
 
diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
index 615382bb07..6a62be8c32 100644
--- a/docs/topics/auth.txt
+++ b/docs/topics/auth.txt
@@ -212,14 +212,15 @@ Methods
     .. method:: models.User.has_perm(perm)
 
         Returns ``True`` if the user has the specified permission, where perm is
-        in the format ``"<application name>.<lowercased model name>"``. If the
-        user is inactive, this method will always return ``False``.
+        in the format ``"<app label>.<permission codename>"``.
+        If the user is inactive, this method will always return ``False``.
 
     .. method:: models.User.has_perms(perm_list)
 
         Returns ``True`` if the user has each of the specified permissions,
-        where each perm is in the format ``"package.codename"``. If the user is
-        inactive, this method will always return ``False``.
+        where each perm is in the format 
+        ``"<app label>.<permission codename>"``. If the user is inactive,
+        this method will always return ``False``.
 
     .. method:: models.User.has_module_perms(package_name)
 
@@ -689,8 +690,10 @@ The login_required decorator
 
         * If the user isn't logged in, redirect to
           :setting:`settings.LOGIN_URL <LOGIN_URL>` (``/accounts/login/`` by
-          default), passing the current absolute URL in the query string as
-          ``next`` or the value of ``redirect_field_name``. For example:
+          default), passing the current absolute URL in the query string. The
+          name of the GET argument is determined by the ``redirect_field_name``
+          argument provided to the decorator. The default argument name is
+          ``next``. For example:
           ``/accounts/login/?next=/polls/3/``.
 
         * If the user is logged in, execute the view normally. The view code is
@@ -726,14 +729,14 @@ the following line to your URLconf::
 
         * ``next``: The URL to redirect to after successful login. This may
           contain a query string, too.
-        
+
         * ``site``: The current :class:`~django.contrib.sites.models.Site`,
           according to the :setting:`SITE_ID` setting. If you don't have the
           site framework installed, this will be set to an instance of
           :class:`~django.contrib.sites.models.RequestSite`, which derives the
           site name and domain from the current
           :class:`~django.http.HttpRequest`.
-        
+
         * ``site_name``: An alias for ``site.name``. If you don't have the site
           framework installed, this will be set to the value of
           :attr:`request.META['SERVER_NAME'] <django.http.HttpRequest.META>`.
@@ -745,11 +748,11 @@ the following line to your URLconf::
     :file:`myapp/login.html` instead::
 
         (r'^accounts/login/$', 'django.contrib.auth.views.login', {'template_name': 'myapp/login.html'}),
-        
+
     You can also specify the name of the ``GET`` field which contains the URL
     to redirect to after login by passing ``redirect_field_name`` to the view.
     By default, the field is called ``next``.
-        
+
     Here's a sample :file:`registration/login.html` template you can use as a
     starting point. It assumes you have a :file:`base.html` template that
     defines a ``content`` block:
@@ -803,7 +806,7 @@ includes a few other useful built-in views located in
         * ``template_name``: The full name of a template to display after
           logging the user out. This will default to
           :file:`registration/logged_out.html` if no argument is supplied.
-          
+
         * ``redirect_field_name``: The name of a ``GET`` field containing the
           URL to redirect to after log out. Overrides ``next_page`` if the given
           ``GET`` parameter is passed.
@@ -862,17 +865,17 @@ includes a few other useful built-in views located in
         * ``email_template_name``: The full name of a template to use for
           generating the e-mail with the new password. This will default to
           :file:`registration/password_reset_email.html` if not supplied.
-        
+
         * ``password_reset_form``: Form that will be used to set the password.
           Defaults to ``SetPasswordForm``.
-        
+
         * ``token_generator``: Instance of the class to check the password. This
           will default to ``default_token_generator``, it's an instance of
           ``django.contrib.auth.tokens.PasswordResetTokenGenerator``.
-          
+
         * ``post_reset_redirect``: The URL to redirect to after a successful
           password change.
-          
+
     **Template context:**
 
         * ``form``: The form for resetting the user's password.
@@ -900,11 +903,11 @@ includes a few other useful built-in views located in
 
         * ``login_url``: The URL of the login page to redirect to. This will
           default to :setting:`settings.LOGIN_URL <LOGIN_URL>` if not supplied.
-          
+
         * ``redirect_field_name``: The name of a ``GET`` field containing the
           URL to redirect to after log out. Overrides ``next`` if the given
           ``GET`` parameter is passed.
-          
+
 .. function:: password_reset_confirm(request[, uidb36, token, template_name, token_generator, set_password_form, post_reset_redirect])
 
     Presents a form for entering a new password.
@@ -929,7 +932,7 @@ includes a few other useful built-in views located in
    Presents a view which informs the user that the password has been
    successfully changed.
 
-   **Optional arguments:** 
+   **Optional arguments:**
 
        * ``template_name``: The full name of a template to display the view.
          This will default to :file:`registration/password_reset_complete.html`.
@@ -1060,8 +1063,8 @@ The permission_required decorator
         my_view = permission_required('polls.can_vote')(my_view)
 
     As for the :meth:`User.has_perm` method, permission names take the form
-    ``"<application name>.<lowercased model name>"`` (i.e. ``polls.choice`` for
-    a ``Choice`` model in the ``polls`` application).
+    ``"<app label>.<permission codename>"`` (i.e. ``polls.can_vote`` for a
+    permission on a model in the ``polls`` application).
 
     Note that :func:`~django.contrib.auth.decorators.permission_required()`
     also takes an optional ``login_url`` parameter. Example::
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index 174dbae121..c9fd1b4012 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -361,6 +361,17 @@ then requests to ``/foo/1/`` and ``/foo/23/`` will be cached separately, as
 you may expect. But once a particular URL (e.g., ``/foo/23/``) has been
 requested, subsequent requests to that URL will use the cache.
 
+``cache_page`` can also take an optional keyword argument, ``key_prefix``, which
+works in the same way as the ``CACHE_MIDDLEWARE_KEY_PREFIX`` setting for the
+middleware.  It can be used like this::
+
+    my_view = cache_page(my_view, 60 * 15, key_prefix="site1")
+
+Or, using Python 2.4's decorator syntax::
+
+    @cache_page(60 * 15, key_prefix="site1")
+    def my_view(request):
+
 Specifying per-view cache in the URLconf
 ----------------------------------------
 
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
index 5e353b2ec3..968ea7fbc8 100644
--- a/docs/topics/db/queries.txt
+++ b/docs/topics/db/queries.txt
@@ -622,6 +622,8 @@ To avoid this problem, simply save the ``QuerySet`` and reuse it::
     >>> print [p.headline for p in queryset] # Evaluate the query set.
     >>> print [p.pub_date for p in queryset] # Re-use the cache from the evaluation.
 
+.. _complex-lookups-with-q:
+
 Complex lookups with Q objects
 ==============================
 
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index add581268b..c5aa9c8a77 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -371,6 +371,35 @@ parameter when declaring the form field::
    ...     class Meta:
    ...         model = Article
 
+.. note::
+
+    If you explicitly instantiate a form field like this, Django assumes that you
+    want to completely define its behavior; therefore, default attributes (such as
+    ``max_length`` or ``required``) are not drawn from the corresponding model. If
+    you want to maintain the behavior specified in the model, you must set the
+    relevant arguments explicitly when declaring the form field.
+
+    For example, if the ``Article`` model looks like this::
+
+        class Article(models.Model):
+            headline = models.CharField(max_length=200, null=True, blank=True,
+                                        help_text="Use puns liberally")
+            content = models.TextField()
+
+    and you want to do some custom validation for ``headline``, while keeping
+    the ``blank`` and ``help_text`` values as specified, you might define
+    ``ArticleForm`` like this::
+
+        class ArticleForm(ModelForm):
+            headline = MyFormField(max_length=200, required=False,
+                                   help_text="Use puns liberally")
+
+            class Meta:
+                model = Article
+
+    See the :ref:`form field documentation <ref-forms-fields>` for more information
+    on fields and their arguments.
+
 Changing the order of fields
 ----------------------------
 
@@ -512,6 +541,12 @@ Then, pass your ``BaseAuthorFormSet`` class to the factory function::
 
     >>> AuthorFormSet = modelformset_factory(Author, formset=BaseAuthorFormSet)
 
+If you want to return a formset that doesn't include *any* pre-existing
+instances of the model, you can specify an empty QuerySet::
+
+   >>> AuthorFormSet(queryset=Author.objects.none())
+
+
 Controlling which fields are used with ``fields`` and ``exclude``
 -----------------------------------------------------------------
 
diff --git a/docs/topics/generic-views.txt b/docs/topics/generic-views.txt
index e4094ac000..c48c858f0b 100644
--- a/docs/topics/generic-views.txt
+++ b/docs/topics/generic-views.txt
@@ -64,7 +64,7 @@ code! --, actually the ``direct_to_template`` view simply grabs information from
 the extra-parameters dictionary and uses that information when rendering the
 view.
 
-Because this generic view -- and all the others -- is a regular view functions
+Because this generic view -- and all the others -- is a regular view function
 like any other, we can reuse it inside our own views. As an example, let's
 extend our "about" example to map URLs of the form ``/about/<whatever>/`` to
 statically rendered ``about/<whatever>.html``. We'll do this by first modifying
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index d3956504c7..3b1429b440 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -453,6 +453,20 @@ Default: ``'sessionid'``
 
 The name of the cookie to use for sessions. This can be whatever you want.
 
+SESSION_COOKIE_PATH
+-------------------
+
+.. versionadded:: 1.0
+
+Default: ``'/'``
+
+The path set on the session cookie. This should either match the URL path of
+your Django installation or be parent of that path.
+
+This is useful if you have multiple Django instances running under the same
+hostname. They can use different cookie paths, and each instance will only see
+its own session cookie.
+
 SESSION_COOKIE_SECURE
 ---------------------
 
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 2bc35a3b9f..e8039fe253 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -147,7 +147,7 @@ will be returned::
 ``get_object_or_404``
 =====================
 
-.. function:: get_object_or_404(object, *args, **kwargs)
+.. function:: get_object_or_404(klass, *args, **kwargs)
 
    Calls :meth:`~django.db.models.QuerySet.get()` on a given model manager,
    but it raises ``django.http.Http404`` instead of the model's
diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt
index cec6002b7b..25d2f083fd 100644
--- a/docs/topics/testing.txt
+++ b/docs/topics/testing.txt
@@ -515,7 +515,7 @@ arguments at time of construction:
         >>> c = Client()
         >>> c.get('/customers/details/?name=fred&age=7')
 
-        If you provide URL both an encoded GET data and a data argument,
+        If you provide a URL with both an encoded GET data and a data argument,
         the data argument will take precedence.
 
         If you set ``follow`` to ``True`` the client will follow any redirects
@@ -627,7 +627,7 @@ arguments at time of construction:
 
         .. versionadded:: 1.1
 
-        Makes an PUT request on the provided ``path`` and returns a
+        Makes a PUT request on the provided ``path`` and returns a
         ``Response`` object. Useful for testing RESTful interfaces. Acts just
         like :meth:`Client.post` except with the PUT request method.
 
@@ -1127,11 +1127,11 @@ Django, such as your machine's mail server, if you're running one.)
 
 During test running, each outgoing e-mail is saved in
 ``django.core.mail.outbox``. This is a simple list of all
-:class:`<~django.core.mail.EmailMessage>` instances that have been sent.
+:class:`~django.core.mail.EmailMessage` instances that have been sent.
 It does not exist under normal execution conditions, i.e., when you're not
 running unit tests. The outbox is created during test setup, along with the
-dummy :class:`<~django.core.mail.SMTPConnection>`. When the test framework is
-torn down, the standard :class:`<~django.core.mail.SMTPConnection>` class is
+dummy :class:`~django.core.mail.SMTPConnection`. When the test framework is
+torn down, the standard :class:`~django.core.mail.SMTPConnection` class is
 restored, and the test outbox is destroyed.
 
 The ``outbox`` attribute is a special attribute that is created *only* when