queryset-refactor: Merged from trunk up to [7122].

git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7124 bcc190cf-cafb-0310-a4f2-bffc1f526a37

11 files changed, 79 insertions, 17 deletions

diff --git a/docs/api_stability.txt b/docs/api_stability.txt
index 5ccf104327..769359b75e 100644
--- a/docs/api_stability.txt
+++ b/docs/api_stability.txt
@@ -88,7 +88,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 dependancies on optional
+     content-types contrib package to avoid core dependencies on optional
      components.
 
    - The comments framework, which is yet undocumented, will likely get a complete
diff --git a/docs/contenttypes.txt b/docs/contenttypes.txt
index 3ef83f2066..51ca8f0198 100644
--- a/docs/contenttypes.txt
+++ b/docs/contenttypes.txt
@@ -215,7 +215,7 @@ each ``TaggedItem`` will have a ``content_object`` field that returns the
 object it's related to, and you can also assign to that field or use it when
 creating a ``TaggedItem``::
 
-    >>> from django.contrib.models.auth import User
+    >>> from django.contrib.auth.models import User
     >>> guido = User.objects.get(username='Guido')
     >>> t = TaggedItem(content_object=guido, tag='bdfl')
     >>> t.save()
@@ -235,7 +235,7 @@ a "reverse" generic relationship to enable an additional API. For example::
 ``Bookmark`` instances will each have a ``tags`` attribute, which can
 be used to retrieve their associated ``TaggedItems``::
 
-    >>> b = Bookmark('http://www.djangoproject.com/')
+    >>> b = Bookmark(url='http://www.djangoproject.com/')
     >>> b.save()
     >>> t1 = TaggedItem(content_object=b, tag='django')
     >>> t1.save()
diff --git a/docs/distributions.txt b/docs/distributions.txt
index 48c30c7068..0c051c8da5 100644
--- a/docs/distributions.txt
+++ b/docs/distributions.txt
@@ -5,7 +5,7 @@ Third-party distributions of Django
 Several third-party distributors are now providing versions of Django integrated
 with their package-management systems. These can make installation and upgrading
 much easier for users of Django since the integration includes the ability to
-automatically install dependancies (like database adapters) that Django
+automatically install dependencies (like database adapters) that Django
 requires.
 
 Typically, these packages are based on the latest stable release of Django, so
diff --git a/docs/django-admin.txt b/docs/django-admin.txt
index 21821ab2e9..e79c105bbd 100644
--- a/docs/django-admin.txt
+++ b/docs/django-admin.txt
@@ -717,7 +717,7 @@ in Python package syntax, e.g. ``mysite.settings``. If this isn't provided,
 variable.
 
 Note that this option is unnecessary in ``manage.py``, because it uses
-``settings.py`` from the current project by default. 
+``settings.py`` from the current project by default.
 
 Extra niceties
 ==============
@@ -765,9 +765,9 @@ a command that can be executed as an action when you run ``manage.py``::
                 __init__.py
                 explode.py
         views.py
-        
+
 In this example, the ``explode`` command will be made available to any project
-that includes the ``fancy_blog`` application in ``settings.INSTALLED_APPS``.
+that includes the ``blog`` application in ``settings.INSTALLED_APPS``.
 
 The ``explode.py`` module has only one requirement -- it must define a class
 called ``Command`` that extends ``django.core.management.base.BaseCommand``.
diff --git a/docs/install.txt b/docs/install.txt
index 331a5ea8e3..542036e2af 100644
--- a/docs/install.txt
+++ b/docs/install.txt
@@ -138,7 +138,7 @@ Installing a distribution-specific package
 Check the `distribution specific notes`_ to see if your
 platform/distribution provides official Django packages/installers.
 Distribution-provided packages will typically allow for automatic
-installation of dependancies and easy upgrade paths.
+installation of dependencies and easy upgrade paths.
 
 Installing an official release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/model-api.txt b/docs/model-api.txt
index 6b8310176b..cccd2ffded 100644
--- a/docs/model-api.txt
+++ b/docs/model-api.txt
@@ -384,7 +384,7 @@ The admin represents this as an ``<input type="text">`` (a single-line input).
 ``IPAddressField``
 ~~~~~~~~~~~~~~~~~~
 
-An IP address, in string format (i.e. "24.124.1.30").
+An IP address, in string format (e.g. "192.0.2.30").
 
 The admin represents this as an ``<input type="text">`` (a single-line input).
 
@@ -952,10 +952,10 @@ the relationship should work. All are optional:
     ``limit_choices_to``     See the description under ``ForeignKey`` above.
 
     ``symmetrical``          Only used in the definition of ManyToManyFields on self.
-                             Consider the following model:
+                             Consider the following model::
 
-                             class Person(models.Model):
-                                 friends = models.ManyToManyField("self")
+                                 class Person(models.Model):
+                                     friends = models.ManyToManyField("self")
 
                              When Django processes this model, it identifies that it has
                              a ``ManyToManyField`` on itself, and as a result, it
@@ -1871,7 +1871,7 @@ more simply as::
 
 If you define a ``__unicode__()`` method on your model and not a ``__str__()``
 method, Django will automatically provide you with a ``__str__()`` that calls
-``__unicode()__`` and then converts the result correctly to a UTF-8 encoded
+``__unicode__()`` and then converts the result correctly to a UTF-8 encoded
 string object. This is recommended development practice: define only
 ``__unicode__()`` and let Django take care of the conversion to string objects
 when required.
diff --git a/docs/modelforms.txt b/docs/modelforms.txt
index a99e27fff7..853fb3159e 100644
--- a/docs/modelforms.txt
+++ b/docs/modelforms.txt
@@ -320,3 +320,41 @@ parameter when declaring the form field::
    ...
    ...     class Meta:
    ...         model = Article
+
+Form inheritance
+----------------
+
+As with basic forms, you can extend and reuse ``ModelForms`` by inheriting
+them. This is useful if you need to declare extra fields or extra methods on a
+parent class for use in a number of forms derived from models. For example,
+using the previous ``ArticleForm`` class::
+
+    >>> class EnhancedArticleForm(ArticleForm):
+    ...     def clean_pub_date(self):
+    ...         ...
+
+This creates a form that behaves identically to ``ArticleForm``, except there's
+some extra validation and cleaning for the ``pub_date`` field.
+
+You can also subclass the parent's ``Meta`` inner class if you want to change
+the ``Meta.fields`` or ``Meta.excludes`` lists::
+
+    >>> class RestrictedArticleForm(EnhancedArticleForm):
+    ...     class Meta(ArticleForm.Meta):
+    ...         exclude = ['body']
+
+This adds the extra method from the ``EnhancedArticleForm`` and modifies
+the original ``ArticleForm.Meta`` to remove one field.
+
+There are a couple of things to note, however.
+
+ * Normal Python name resolution rules apply. If you have multiple base
+   classes that declare a ``Meta`` inner class, only the first one will be
+   used. This means the child's ``Meta``, if it exists, otherwise the
+   ``Meta`` of the first parent, etc.
+
+ * For technical reasons, a subclass cannot inherit from both a ``ModelForm``
+   and a ``Form`` simultaneously.
+
+Chances are these notes won't affect you unless you're trying to do something
+tricky with subclassing.
diff --git a/docs/request_response.txt b/docs/request_response.txt
index 47c66355e8..e50cfc5ea3 100644
--- a/docs/request_response.txt
+++ b/docs/request_response.txt
@@ -576,7 +576,7 @@ Three things to note about 404 views:
       in the 404.
 
     * The 404 view is passed a ``RequestContext`` and will have access to
-      variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` (e.g.
+      variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` setting (e.g.,
       ``MEDIA_URL``).
 
     * If ``DEBUG`` is set to ``True`` (in your settings module), then your 404
diff --git a/docs/shortcuts.txt b/docs/shortcuts.txt
index f1d7f38ffa..005fdc3029 100644
--- a/docs/shortcuts.txt
+++ b/docs/shortcuts.txt
@@ -30,9 +30,9 @@ Optional arguments
 ``context_instance``
     The context instance to render the template with. By default, the template
     will be rendered with a ``Context`` instance (filled with values from
-    ``dictionary``). If you need to use `context processors`_, you will want to
-    render the template with a ``RequestContext`` instance instead. Your code
-    might look something like this::
+    ``dictionary``). If you need to use `context processors`_, render the
+    template with a ``RequestContext`` instance instead. Your code might look
+    something like this::
 
         return render_to_response('my_template.html',
                                   my_data_dictionary,
diff --git a/docs/templates.txt b/docs/templates.txt
index c351c951c9..d473a6f06f 100644
--- a/docs/templates.txt
+++ b/docs/templates.txt
@@ -1406,6 +1406,8 @@ Joins a list with a string, like Python's ``str.join(list)``.
 last
 ~~~~
 
+**New in Django development version.**
+
 Returns the last item in a list.
 
 length
diff --git a/docs/url_dispatch.txt b/docs/url_dispatch.txt
index 6ed7043fd5..789399de8d 100644
--- a/docs/url_dispatch.txt
+++ b/docs/url_dispatch.txt
@@ -190,6 +190,28 @@ The remaining arguments should be tuples in this format::
 ...where ``optional dictionary`` and ``optional name`` are optional. (See
 `Passing extra options to view functions`_ below.)
 
+.. note::
+    Because `patterns()` is a function call, it accepts a maximum of 255
+    arguments (URL patterns, in this case). This is a limit for all Python
+    function calls. This is rarely a problem in practice, because you'll
+    typically structure your URL patterns modularly by using `include()`
+    sections. However, on the off-chance you do hit the 255-argument limit,
+    realize that `patterns()` returns a Python list, so you can split up the
+    construction of the list.
+
+    ::
+
+        urlpatterns = patterns('',
+            ...
+            )
+        urlpatterns += patterns('',
+            ...
+            )
+
+    Python lists have unlimited size, so there's no limit to how many URL
+    patterns you can construct. The only limit is that you can only create 254
+    at a time (the 255th argument is the initial prefix argument).
+
 url
 ---