Merge remote-tracking branch 'core/master' into schema-alteration

Conflicts:
	django/db/backends/mysql/base.py
	django/db/backends/postgresql_psycopg2/base.py

20 files changed, 736 insertions, 321 deletions

diff --git a/docs/ref/class-based-views/base.txt b/docs/ref/class-based-views/base.txt
index 3f82b44f46..cc9aa852f1 100644
--- a/docs/ref/class-based-views/base.txt
+++ b/docs/ref/class-based-views/base.txt
@@ -8,6 +8,11 @@ themselves or inherited from. They may not provide all the capabilities
 required for projects, in which case there are Mixins and Generic class-based
 views.
 
+Many of Django's built-in class-based views inherit from other class-based
+views or various mixins. Because this inheritence chain is very important, the
+ancestor classes are  documented under the section title of **Ancestors (MRO)**.
+MRO is an acronym for Method Resolution Order.
+
 View
 ----
 
@@ -20,6 +25,7 @@ View
 
     1. :meth:`dispatch()`
     2. :meth:`http_method_not_allowed()`
+    3. :meth:`options()`
 
     **Example views.py**::
 
@@ -41,8 +47,20 @@ View
             url(r'^mine/$', MyView.as_view(), name='my-view'),
         )
 
+    **Attributes**
+
+    .. attribute:: http_method_names = ['get', 'post', 'put', 'delete', 'head', 'options', 'trace']
+
+        The default list of HTTP method names that this view will accept.
+
     **Methods**
 
+    .. classmethod:: as_view(**initkwargs)
+
+        Returns a callable view that takes a request and returns a response::
+
+            response = MyView.as_view()(request)
+
     .. method:: dispatch(request, *args, **kwargs)
 
         The ``view`` part of the view -- the method that accepts a ``request``
@@ -53,6 +71,11 @@ View
         delegated to :meth:`~View.get()`, a ``POST`` to :meth:`~View.post()`,
         and so on.
 
+        By default, a ``HEAD`` request will be delegated to :meth:`~View.get()`.
+        If you need to handle ``HEAD`` requests in a different way than ``GET``,
+        you can override the :meth:`~View.head()` method. See
+        :ref:`supporting-other-http-methods` for an example.
+
         The default implementation also sets ``request``, ``args`` and
         ``kwargs`` as instance variables, so any method on the view can know
         the full details of the request that was made to invoke the view.
@@ -62,14 +85,13 @@ View
         If the view was called with a HTTP method it doesn't support, this
         method is called instead.
 
-        The default implementation returns ``HttpResponseNotAllowed`` with list
-        of allowed methods in plain text.
+        The default implementation returns ``HttpResponseNotAllowed`` with a
+        list of allowed methods in plain text.
 
-    .. note::
+    .. method:: options(request, *args, **kwargs)
 
-        Documentation on class-based views is a work in progress. As yet, only the
-        methods defined directly on the class are documented here, not methods
-        defined on superclasses.
+        Handles responding to requests for the OPTIONS HTTP verb.  Returns a
+        list of the allowed HTTP method names for the view.
 
 TemplateView
 ------------
@@ -81,6 +103,8 @@ TemplateView
 
     **Ancestors (MRO)**
 
+    This view inherits methods and attributes from the following views:
+
     * :class:`django.views.generic.base.TemplateView`
     * :class:`django.views.generic.base.TemplateResponseMixin`
     * :class:`django.views.generic.base.View`
@@ -116,28 +140,11 @@ TemplateView
             url(r'^$', HomePageView.as_view(), name='home'),
         )
 
-    **Methods and Attributes**
-
-    .. attribute:: template_name
-
-        The full name of a template to use.
-
-    .. method:: get_context_data(**kwargs)
-
-        Return a context data dictionary consisting of the contents of
-        ``kwargs`` stored in the context variable ``params``.
-
     **Context**
 
     * ``params``: The dictionary of keyword arguments captured from the URL
       pattern that served the view.
 
-    .. note::
-
-        Documentation on class-based views is a work in progress. As yet, only the
-        methods defined directly on the class are documented here, not methods
-        defined on superclasses.
-
 RedirectView
 ------------
 
@@ -156,6 +163,8 @@ RedirectView
 
     **Ancestors (MRO)**
 
+    This view inherits methods and attributes from the following view:
+
     * :class:`django.views.generic.base.View`
 
     **Method Flowchart**
@@ -194,7 +203,7 @@ RedirectView
             url(r'^go-to-django/$', RedirectView.as_view(url='http://djangoproject.com'), name='go-to-django'),
         )
 
-    **Methods and Attributes**
+    **Attributes**
 
     .. attribute:: url
 
@@ -215,6 +224,8 @@ RedirectView
         then the query string is discarded. By default, ``query_string`` is
         ``False``.
 
+    **Methods**
+
     .. method:: get_redirect_url(**kwargs)
 
         Constructs the target URL for redirection.
@@ -225,9 +236,3 @@ RedirectView
         :attr:`~RedirectView.query_string`. Subclasses may implement any
         behavior they wish, as long as the method returns a redirect-ready URL
         string.
-
-    .. note::
-
-        Documentation on class-based views is a work in progress. As yet, only the
-        methods defined directly on the class are documented here, not methods
-        defined on superclasses.
diff --git a/docs/ref/class-based-views/generic-date-based.txt b/docs/ref/class-based-views/generic-date-based.txt
index 12776cbb94..64b269f514 100644
--- a/docs/ref/class-based-views/generic-date-based.txt
+++ b/docs/ref/class-based-views/generic-date-based.txt
@@ -2,13 +2,15 @@
 Generic date views
 ==================
 
-Date-based generic views (in the module :mod:`django.views.generic.dates`)
-are views for displaying drilldown pages for date-based data.
+.. module:: django.views.generic.dates
+
+Date-based generic views, provided in :mod:`django.views.generic.dates`, are
+views for displaying drilldown pages for date-based data.
 
 ArchiveIndexView
 ----------------
 
-.. class:: django.views.generic.dates.ArchiveIndexView
+.. class:: ArchiveIndexView
 
     A top-level index page showing the "latest" objects, by date. Objects with
     a date in the *future* are not included unless you set ``allow_future`` to
@@ -36,7 +38,7 @@ ArchiveIndexView
 YearArchiveView
 ---------------
 
-.. class:: django.views.generic.dates.YearArchiveView
+.. class:: YearArchiveView
 
     A yearly archive page showing all available months in a given year. Objects
     with a date in the *future* are not displayed unless you set
@@ -58,13 +60,15 @@ YearArchiveView
 
         A boolean specifying whether to retrieve the full list of objects for
         this year and pass those to the template. If ``True``, the list of
-        objects will be made available to the context. By default, this is
+        objects will be made available to the context. If ``False``, the
+        ``None`` queryset will be used as the object list. By default, this is
         ``False``.
 
     .. method:: get_make_object_list()
 
-        Determine if an object list will be returned as part of the context. If
-        ``False``, the ``None`` queryset will be used as the object list.
+        Determine if an object list will be returned as part of the context.
+        Returns :attr:`~YearArchiveView.make_object_list` by default.
+
 
     **Context**
 
@@ -80,16 +84,18 @@ YearArchiveView
       :class:`datetime.datetime<python:datetime.datetime>` objects, in
       ascending order.
 
-    * ``year``: A :class:`datetime.date<python:datetime.date>` object
+    * ``year``: A :class:`~datetime.date` object
       representing the given year.
 
-    * ``next_year``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the next year. If the next year is in the
-      future, this will be ``None``.
+    * ``next_year``: A :class:`~datetime.date` object
+      representing the first day of the next year, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
-    * ``previous_year``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the previous year. Unlike ``next_year``,
-      this will never be ``None``.
+    * ``previous_year``: A :class:`~datetime.date` object
+      representing the first day of the previous year, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
     **Notes**
 
@@ -98,7 +104,7 @@ YearArchiveView
 MonthArchiveView
 ----------------
 
-.. class:: django.views.generic.dates.MonthArchiveView
+.. class:: MonthArchiveView
 
     A monthly archive page showing all objects in a given month. Objects with a
     date in the *future* are not displayed unless you set ``allow_future`` to
@@ -131,16 +137,18 @@ MonthArchiveView
       :class:`datetime.datetime<python:datetime.datetime>` objects, in
       ascending order.
 
-    * ``month``: A :class:`datetime.date<python:datetime.date>` object
+    * ``month``: A :class:`~datetime.date` object
       representing the given month.
 
-    * ``next_month``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the next month. If the next month is in the
-      future, this will be ``None``.
+    * ``next_month``: A :class:`~datetime.date` object
+      representing the first day of the next month, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
-    * ``previous_month``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the previous month. Unlike ``next_month``,
-      this will never be ``None``.
+    * ``previous_month``: A :class:`~datetime.date` object
+      representing the first day of the previous month, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
     **Notes**
 
@@ -149,7 +157,7 @@ MonthArchiveView
 WeekArchiveView
 ---------------
 
-.. class:: django.views.generic.dates.WeekArchiveView
+.. class:: WeekArchiveView
 
     A weekly archive page showing all objects in a given week. Objects with a
     date in the *future* are not displayed unless you set ``allow_future`` to
@@ -175,16 +183,18 @@ WeekArchiveView
     :class:`~django.views.generic.dates.BaseDateListView`), the template's
     context will be:
 
-    * ``week``: A :class:`datetime.date<python:datetime.date>` object
+    * ``week``: A :class:`~datetime.date` object
       representing the first day of the given week.
 
-    * ``next_week``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the next week. If the next week is in the
-      future, this will be ``None``.
+    * ``next_week``: A :class:`~datetime.date` object
+      representing the first day of the next week, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
-    * ``previous_week``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the previous week. Unlike ``next_week``,
-      this will never be ``None``.
+    * ``previous_week``: A :class:`~datetime.date` object
+      representing the first day of the previous week, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
     **Notes**
 
@@ -193,7 +203,7 @@ WeekArchiveView
 DayArchiveView
 --------------
 
-.. class:: django.views.generic.dates.DayArchiveView
+.. class:: DayArchiveView
 
     A day archive page showing all objects in a given day. Days in the future
     throw a 404 error, regardless of whether any objects exist for future days,
@@ -220,24 +230,28 @@ DayArchiveView
     :class:`~django.views.generic.dates.BaseDateListView`), the template's
     context will be:
 
-    * ``day``: A :class:`datetime.date<python:datetime.date>` object
+    * ``day``: A :class:`~datetime.date` object
       representing the given day.
 
-    * ``next_day``: A :class:`datetime.date<python:datetime.date>` object
-      representing the next day. If the next day is in the future, this will be
-      ``None``.
+    * ``next_day``: A :class:`~datetime.date` object
+      representing the next day, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
-    * ``previous_day``: A :class:`datetime.date<python:datetime.date>` object
-      representing the previous day. Unlike ``next_day``, this will never be
-      ``None``.
+    * ``previous_day``: A :class:`~datetime.date` object
+      representing the previous day, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
-    * ``next_month``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the next month. If the next month is in the
-      future, this will be ``None``.
+    * ``next_month``: A :class:`~datetime.date` object
+      representing the first day of the next month, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
-    * ``previous_month``: A :class:`datetime.date<python:datetime.date>` object
-      representing the first day of the previous month. Unlike ``next_month``,
-      this will never be ``None``.
+    * ``previous_month``: A :class:`~datetime.date` object
+      representing the first day of the previous month, according to
+      :attr:`~BaseDateListView.allow_empty` and
+      :attr:`~DateMixin.allow_future`.
 
     **Notes**
 
@@ -246,7 +260,7 @@ DayArchiveView
 TodayArchiveView
 ----------------
 
-.. class:: django.views.generic.dates.TodayArchiveView
+.. class:: TodayArchiveView
 
     A day archive page showing all objects for *today*. This is exactly the
     same as :class:`django.views.generic.dates.DayArchiveView`, except today's
@@ -271,7 +285,7 @@ TodayArchiveView
 DateDetailView
 --------------
 
-.. class:: django.views.generic.dates.DateDetailView
+.. class:: DateDetailView
 
     A page representing an individual object. If the object has a date value in
     the future, the view will throw a 404 error by default, unless you set
@@ -293,6 +307,22 @@ DateDetailView
 
 .. note::
 
-    All of the generic views listed above have matching Base* views that only
-    differ in that the they do not include the
-    :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`.
+    All of the generic views listed above have matching ``Base`` views that
+    only differ in that the they do not include the
+    :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`:
+
+    .. class:: BaseArchiveIndexView
+
+    .. class:: BaseYearArchiveView
+
+    .. class:: BaseMonthArchiveView
+
+    .. class:: BaseWeekArchiveView
+
+    .. class:: BaseDayArchiveView
+
+    .. class:: BaseTodayArchiveView
+
+    .. class:: BaseDateDetailView
+
+
diff --git a/docs/ref/class-based-views/generic-display.txt b/docs/ref/class-based-views/generic-display.txt
index ef3bc179ee..12603ff0df 100644
--- a/docs/ref/class-based-views/generic-display.txt
+++ b/docs/ref/class-based-views/generic-display.txt
@@ -15,6 +15,8 @@ DetailView
 
     **Ancestors (MRO)**
 
+    This view inherits methods and attributes from the following views:
+
     * :class:`django.views.generic.detail.SingleObjectTemplateResponseMixin`
     * :class:`django.views.generic.base.TemplateResponseMixin`
     * :class:`django.views.generic.detail.BaseDetailView`
@@ -71,7 +73,9 @@ ListView
     objects (usually, but not necessarily a queryset) that the view is
     operating upon.
 
-    **Mixins**
+    **Ancestors (MRO)**
+
+    This view inherits methods and attributes from the following views:
 
     * :class:`django.views.generic.list.ListView`
     * :class:`django.views.generic.list.MultipleObjectTemplateResponseMixin`
@@ -90,3 +94,54 @@ ListView
     6. :meth:`get_context_data()`
     7. :meth:`get()`
     8. :meth:`render_to_response()`
+
+
+    **Example views.py**::
+
+        from django.views.generic.list import ListView
+        from django.utils import timezone
+
+        from articles.models import Article
+
+        class ArticleListView(ListView):
+
+            model = Article
+
+            def get_context_data(self, **kwargs):
+                context = super(ArticleListView, self).get_context_data(**kwargs)
+                context['now'] = timezone.now()
+                return context
+
+    **Example urls.py**::
+
+        from django.conf.urls import patterns, url
+
+        from article.views import ArticleListView
+
+        urlpatterns = patterns('',
+            url(r'^$', ArticleListView.as_view(), name='article-list'),
+        )
+
+.. class:: django.views.generic.list.BaseListView
+
+    A base view for displaying a list of objects. It is not intended to be used
+    directly, but rather as a parent class of the
+    :class:`django.views.generic.list.ListView` or other views representing
+    lists of objects.
+
+    **Ancestors (MRO)**
+
+    This view inherits methods and attributes from the following views:
+
+    * :class:`django.views.generic.list.MultipleObjectMixin`
+    * :class:`django.views.generic.base.View`
+
+    **Methods**
+
+    .. method:: get(request, *args, **kwargs)
+
+        Adds :attr:`object_list` to the context. If
+        :attr:`~django.views.generic.list.MultipleObjectMixin.allow_empty`
+        is True then display an empty list. If
+        :attr:`~django.views.generic.list.MultipleObjectMixin.allow_empty` is
+        False then raise a 404 error.
diff --git a/docs/ref/class-based-views/index.txt b/docs/ref/class-based-views/index.txt
index f0e7bbc6c1..c4b632604a 100644
--- a/docs/ref/class-based-views/index.txt
+++ b/docs/ref/class-based-views/index.txt
@@ -23,7 +23,7 @@ it is safe to store state variables on the instance (i.e., ``self.foo = 3`` is
 a thread-safe operation).
 
 A class-based view is deployed into a URL pattern using the
-:meth:`~View.as_view()` classmethod::
+:meth:`~django.views.generic.base.View.as_view()` classmethod::
 
     urlpatterns = patterns('',
         (r'^view/$', MyView.as_view(size=42)),
@@ -37,9 +37,10 @@ A class-based view is deployed into a URL pattern using the
     is modified, the actions of one user visiting your view could have an
     effect on subsequent users visiting the same view.
 
-Any argument passed into :meth:`~View.as_view()` will be assigned onto the
-instance that is used to service a request. Using the previous example,
-this means that every request on ``MyView`` is able to use ``self.size``.
+Any argument passed into :meth:`~django.views.generic.base.View.as_view()` will
+be assigned onto the instance that is used to service a request. Using the
+previous example, this means that every request on ``MyView`` is able to use
+``self.size``.
 
 Base vs Generic views
 ---------------------
diff --git a/docs/ref/class-based-views/mixins-date-based.txt b/docs/ref/class-based-views/mixins-date-based.txt
index 6bf6f10b5d..01181ebb6c 100644
--- a/docs/ref/class-based-views/mixins-date-based.txt
+++ b/docs/ref/class-based-views/mixins-date-based.txt
@@ -2,11 +2,12 @@
 Date-based mixins
 =================
 
+.. currentmodule:: django.views.generic.dates
 
 YearMixin
 ---------
 
-.. class:: django.views.generic.dates.YearMixin
+.. class:: YearMixin
 
     A mixin that can be used to retrieve and provide parsing information for a
     year component of a date.
@@ -20,29 +21,45 @@ YearMixin
 
     .. attribute:: year
 
-        **Optional** The value for the year (as a string). By default, set to
+        **Optional** The value for the year, as a string. By default, set to
         ``None``, which means the year will be determined using other means.
 
     .. method:: get_year_format()
 
-        Returns the :func:`~time.strftime` format to use when parsing the year. Returns
-        :attr:`YearMixin.year_format` by default.
+        Returns the :func:`~time.strftime` format to use when parsing the
+        year. Returns :attr:`~YearMixin.year_format` by default.
 
     .. method:: get_year()
 
-        Returns the year for which this view will display data. Tries the
-        following sources, in order:
+        Returns the year for which this view will display data, as a string.
+        Tries the following sources, in order:
 
         * The value of the :attr:`YearMixin.year` attribute.
-        * The value of the `year` argument captured in the URL pattern
+        * The value of the `year` argument captured in the URL pattern.
         * The value of the `year` GET query argument.
 
         Raises a 404 if no valid year specification can be found.
 
+    .. method:: get_next_year(date)
+
+        Returns a date object containing the first day of the year after the
+        date provided. This function can also return ``None`` or raise an
+        :class:`~django.http.Http404` exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
+
+    .. method:: get_previous_year(date)
+
+        Returns a date object containing the first day of the year before the
+        date provided. This function can also return ``None`` or raise an
+        :class:`~django.http.Http404` exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
+
 MonthMixin
 ----------
 
-.. class:: django.views.generic.dates.MonthMixin
+.. class:: MonthMixin
 
     A mixin that can be used to retrieve and provide parsing information for a
     month component of a date.
@@ -51,26 +68,26 @@ MonthMixin
 
     .. attribute:: month_format
 
-        The :func:`~time.strftime` format to use when parsing the month. By default, this is
-        ``'%b'``.
+        The :func:`~time.strftime` format to use when parsing the month. By
+        default, this is ``'%b'``.
 
     .. attribute:: month
 
-        **Optional** The value for the month (as a string). By default, set to
+        **Optional** The value for the month, as a string. By default, set to
         ``None``, which means the month will be determined using other means.
 
     .. method:: get_month_format()
 
-        Returns the :func:`~time.strftime` format to use when parsing the month. Returns
-        :attr:`MonthMixin.month_format` by default.
+        Returns the :func:`~time.strftime` format to use when parsing the
+        month. Returns :attr:`~MonthMixin.month_format` by default.
 
     .. method:: get_month()
 
-        Returns the month for which this view will display data. Tries the
-        following sources, in order:
+        Returns the month for which this view will display data, as a string.
+        Tries the following sources, in order:
 
         * The value of the :attr:`MonthMixin.month` attribute.
-        * The value of the `month` argument captured in the URL pattern
+        * The value of the `month` argument captured in the URL pattern.
         * The value of the `month` GET query argument.
 
         Raises a 404 if no valid month specification can be found.
@@ -78,20 +95,23 @@ MonthMixin
     .. method:: get_next_month(date)
 
         Returns a date object containing the first day of the month after the
-        date provided. Returns ``None`` if mixed with a view that sets
-        ``allow_future = False``, and the next month is in the future. If
-        ``allow_empty = False``, returns the next month that contains data.
+        date provided. This function can also return ``None`` or raise an
+        :class:`~django.http.Http404` exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
 
     .. method:: get_prev_month(date)
 
         Returns a date object containing the first day of the month before the
-        date provided. If ``allow_empty = False``, returns the previous month
-        that contained data.
+        date provided. This function can also return ``None`` or raise an
+        :class:`~django.http.Http404` exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
 
 DayMixin
 --------
 
-.. class:: django.views.generic.dates.DayMixin
+.. class:: DayMixin
 
     A mixin that can be used to retrieve and provide parsing information for a
     day component of a date.
@@ -100,46 +120,50 @@ DayMixin
 
     .. attribute:: day_format
 
-        The :func:`~time.strftime` format to use when parsing the day. By default, this is
-        ``'%d'``.
+        The :func:`~time.strftime` format to use when parsing the day. By
+        default, this is ``'%d'``.
 
     .. attribute:: day
 
-        **Optional** The value for the day (as a string). By default, set to
+        **Optional** The value for the day, as a string. By default, set to
         ``None``, which means the day will be determined using other means.
 
     .. method:: get_day_format()
 
-        Returns the :func:`~time.strftime` format to use when parsing the day. Returns
-        :attr:`DayMixin.day_format` by default.
+        Returns the :func:`~time.strftime` format to use when parsing the day.
+        Returns :attr:`~DayMixin.day_format` by default.
 
     .. method:: get_day()
 
-        Returns the day for which this view will display data. Tries the
-        following sources, in order:
+        Returns the day for which this view will display data, as a string.
+        Tries the following sources, in order:
 
         * The value of the :attr:`DayMixin.day` attribute.
-        * The value of the `day` argument captured in the URL pattern
+        * The value of the `day` argument captured in the URL pattern.
         * The value of the `day` GET query argument.
 
         Raises a 404 if no valid day specification can be found.
 
     .. method:: get_next_day(date)
 
-        Returns a date object containing the next day after the date provided.
-        Returns ``None`` if mixed with a view that sets ``allow_future = False``,
-        and the next day is in the future. If ``allow_empty = False``, returns
-        the next day that contains data.
+        Returns a date object containing the next valid day after the date
+        provided. This function can also return ``None`` or raise an
+        :class:`~django.http.Http404` exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
 
     .. method:: get_prev_day(date)
 
-        Returns a date object containing the previous day. If
-        ``allow_empty = False``, returns the previous day that contained data.
+        Returns a date object containing the previous valid day. This function
+        can also return ``None`` or raise an :class:`~django.http.Http404`
+        exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
 
 WeekMixin
 ---------
 
-.. class:: django.views.generic.dates.WeekMixin
+.. class:: WeekMixin
 
     A mixin that can be used to retrieve and provide parsing information for a
     week component of a date.
@@ -148,23 +172,24 @@ WeekMixin
 
     .. attribute:: week_format
 
-        The :func:`~time.strftime` format to use when parsing the week. By default, this is
-        ``'%U'``.
+        The :func:`~time.strftime` format to use when parsing the week. By
+        default, this is ``'%U'``, which means the week starts on Sunday. Set
+        it to ``'%W'`` if your week starts on Monday.
 
     .. attribute:: week
 
-        **Optional** The value for the week (as a string). By default, set to
+        **Optional** The value for the week, as a string. By default, set to
         ``None``, which means the week will be determined using other means.
 
     .. method:: get_week_format()
 
-        Returns the :func:`~time.strftime` format to use when parsing the week. Returns
-        :attr:`WeekMixin.week_format` by default.
+        Returns the :func:`~time.strftime` format to use when parsing the
+        week. Returns :attr:`~WeekMixin.week_format` by default.
 
     .. method:: get_week()
 
-        Returns the week for which this view will display data. Tries the
-        following sources, in order:
+        Returns the week for which this view will display data, as a string.
+        Tries the following sources, in order:
 
         * The value of the :attr:`WeekMixin.week` attribute.
         * The value of the `week` argument captured in the URL pattern
@@ -172,11 +197,26 @@ WeekMixin
 
         Raises a 404 if no valid week specification can be found.
 
+    .. method:: get_next_week(date)
+
+        Returns a date object containing the first day of the week after the
+        date provided. This function can also return ``None`` or raise an
+        :class:`~django.http.Http404` exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
+
+    .. method:: get_prev_week(date)
+
+        Returns a date object containing the first day of the week before the
+        date provided. This function can also return ``None`` or raise an
+        :class:`~django.http.Http404` exception, depending on the values of
+        :attr:`~BaseDateListView.allow_empty` and
+        :attr:`~DateMixin.allow_future`.
 
 DateMixin
 ---------
 
-.. class:: django.views.generic.dates.DateMixin
+.. class:: DateMixin
 
     A mixin class providing common behavior for all date-based views.
 
@@ -186,7 +226,7 @@ DateMixin
 
         The name of the ``DateField`` or ``DateTimeField`` in the
         ``QuerySet``'s model that the date-based archive should use to
-        determine the objects on the page.
+        determine the list of objects to display on the page.
 
         When :doc:`time zone support </topics/i18n/timezones>` is enabled and
         ``date_field`` is a ``DateTimeField``, dates are assumed to be in the
@@ -210,26 +250,26 @@ DateMixin
     .. method:: get_date_field()
 
         Returns the name of the field that contains the date data that this
-        view will operate on. Returns :attr:`DateMixin.date_field` by default.
+        view will operate on. Returns :attr:`~DateMixin.date_field` by default.
 
     .. method:: get_allow_future()
 
         Determine whether to include "future" objects on this page, where
         "future" means objects in which the field specified in ``date_field``
         is greater than the current date/time. Returns
-        :attr:`DateMixin.allow_future` by default.
+        :attr:`~DateMixin.allow_future` by default.
 
 BaseDateListView
 ----------------
 
-.. class:: django.views.generic.dates.BaseDateListView
+.. class:: BaseDateListView
 
     A base class that provides common behavior for all date-based views. There
     won't normally be a reason to instantiate
     :class:`~django.views.generic.dates.BaseDateListView`; instantiate one of
     the subclasses instead.
 
-    While this view (and it's subclasses) are executing, ``self.object_list``
+    While this view (and its subclasses) are executing, ``self.object_list``
     will contain the list of objects that the view is operating upon, and
     ``self.date_list`` will contain the list of dates for which data is
     available.
@@ -245,10 +285,18 @@ BaseDateListView
 
         A boolean specifying whether to display the page if no objects are
         available. If this is ``True`` and no objects are available, the view
-        will display an empty page instead of raising a 404. By default, this
-        is ``False``.
+        will display an empty page instead of raising a 404.
+
+        This is identical to :attr:`MultipleObjectMixin.allow_empty`, except
+        for the default value, which is ``False``.
+
+    .. attribute:: date_list_period
 
-    .. method:: get_dated_items():
+        **Optional** A string defining the aggregation period for
+        ``date_list``. It must be one of ``'year'`` (default), ``'month'``, or
+        ``'day'``.
+
+    .. method:: get_dated_items()
 
         Returns a 3-tuple containing (``date_list``, ``object_list``,
         ``extra_context``).
@@ -265,10 +313,17 @@ BaseDateListView
         ``lookup``. Enforces any restrictions on the queryset, such as
         ``allow_empty`` and ``allow_future``.
 
-    .. method:: get_date_list(queryset, date_type)
+    .. method:: get_date_list_period()
+
+        Returns the aggregation period for ``date_list``. Returns
+        :attr:`~BaseDateListView.date_list_period` by default.
+
+    .. method:: get_date_list(queryset, date_type=None)
 
-        Returns the list of dates of type ``date_type`` for which
-        ``queryset`` contains entries. For example, ``get_date_list(qs,
-        'year')`` will return the list of years for which ``qs`` has entries.
-        See :meth:`~django.db.models.query.QuerySet.dates()` for the
-        ways that the ``date_type`` argument can be used.
+        Returns the list of dates of type ``date_type`` for which ``queryset``
+        contains entries. For example, ``get_date_list(qs, 'year')`` will
+        return the list of years for which ``qs`` has entries. If
+        ``date_type`` isn't provided, the result of
+        :meth:`BaseDateListView.get_date_list_period` is used. See
+        :meth:`~django.db.models.query.QuerySet.dates()` for the ways that the
+        ``date_type`` argument can be used.
diff --git a/docs/ref/class-based-views/mixins-multiple-object.txt b/docs/ref/class-based-views/mixins-multiple-object.txt
index 8bc613b887..cdb743fcbd 100644
--- a/docs/ref/class-based-views/mixins-multiple-object.txt
+++ b/docs/ref/class-based-views/mixins-multiple-object.txt
@@ -86,7 +86,8 @@ MultipleObjectMixin
 
     .. method:: get_queryset()
 
-        Returns the queryset that represents the data this view will display.
+        Get the list of items for this view. This must be an iterable and may
+        be a queryset (in which queryset-specific behavior will be enabled).
 
     .. method:: paginate_queryset(queryset, page_size)
 
diff --git a/docs/ref/class-based-views/mixins-simple.txt b/docs/ref/class-based-views/mixins-simple.txt
index 61fc945cd3..d2f0df241e 100644
--- a/docs/ref/class-based-views/mixins-simple.txt
+++ b/docs/ref/class-based-views/mixins-simple.txt
@@ -9,16 +9,17 @@ ContextMixin
 
     .. versionadded:: 1.5
 
-    **classpath**
-
-    ``django.views.generic.base.ContextMixin``
-
     **Methods**
 
     .. method:: get_context_data(**kwargs)
 
         Returns a dictionary representing the template context. The keyword
-        arguments provided will make up the returned context.
+        arguments provided will make up the returned context. Example usage::
+
+            def get_context_data(self, **kwargs):
+                context = super(RandomNumberView, self).get_context_data(**kwargs)
+                context['number'] = random.randrange(1, 100)
+                return context
 
         The template context of all class-based generic views include a
         ``view`` variable that points to the ``View`` instance.
@@ -42,7 +43,13 @@ TemplateResponseMixin
     suitable context. The template to use is configurable and can be
     further customized by subclasses.
 
-    **Methods and Attributes**
+    **Attributes**
+
+    .. attribute:: template_name
+
+        The full name of a template to use as defined by a string. Not defining
+        a template_name will raise a
+        :class:`django.core.exceptions.ImproperlyConfigured` exception.
 
     .. attribute:: response_class
 
@@ -57,12 +64,14 @@ TemplateResponseMixin
         instantiation, create a ``TemplateResponse`` subclass and assign it to
         ``response_class``.
 
+    **Methods**
+
     .. method:: render_to_response(context, **response_kwargs)
 
         Returns a ``self.response_class`` instance.
 
-        If any keyword arguments are provided, they will be
-        passed to the constructor of the response class.
+        If any keyword arguments are provided, they will be passed to the
+        constructor of the response class.
 
         Calls :meth:`~TemplateResponseMixin.get_template_names()` to obtain the
         list of template names that will be searched looking for an existent
diff --git a/docs/ref/contrib/comments/moderation.txt b/docs/ref/contrib/comments/moderation.txt
index 4f4b326cb2..f03c7fda0d 100644
--- a/docs/ref/contrib/comments/moderation.txt
+++ b/docs/ref/contrib/comments/moderation.txt
@@ -32,11 +32,11 @@ A simple example is the best illustration of this. Suppose we have the
 following model, which would represent entries in a Weblog::
 
     from django.db import models
-    
+
     class Entry(models.Model):
         title = models.CharField(maxlength=250)
         body = models.TextField()
-        pub_date = models.DateTimeField()
+        pub_date = models.DateField()
         enable_comments = models.BooleanField()
 
 Now, suppose that we want the following steps to be applied whenever a
@@ -55,11 +55,11 @@ Accomplishing this is fairly straightforward and requires very little
 code::
 
     from django.contrib.comments.moderation import CommentModerator, moderator
-    
+
     class EntryModerator(CommentModerator):
         email_notification = True
         enable_field = 'enable_comments'
-    
+
     moderator.register(Entry, EntryModerator)
 
 The :class:`CommentModerator` class pre-defines a number of useful moderation
diff --git a/docs/ref/contrib/contenttypes.txt b/docs/ref/contrib/contenttypes.txt
index 0226435159..e98da6e429 100644
--- a/docs/ref/contrib/contenttypes.txt
+++ b/docs/ref/contrib/contenttypes.txt
@@ -187,6 +187,14 @@ The ``ContentTypeManager``
         probably won't ever need to call this method yourself; Django will call
         it automatically when it's needed.
 
+    .. method:: get_for_id(id)
+
+        Lookup a :class:`~django.contrib.contenttypes.models.ContentType` by ID.
+        Since this method uses the same shared cache as
+        :meth:`~django.contrib.contenttypes.models.ContentTypeManager.get_for_model`,
+        it's preferred to use this method over the usual
+        ``ContentType.objects.get(pk=id)``
+
     .. method:: get_for_model(model[, for_concrete_model=True])
 
         Takes either a model class or an instance of a model, and returns the
diff --git a/docs/ref/contrib/formtools/form-wizard.txt b/docs/ref/contrib/formtools/form-wizard.txt
index b8e585a4d2..d5231de3e5 100644
--- a/docs/ref/contrib/formtools/form-wizard.txt
+++ b/docs/ref/contrib/formtools/form-wizard.txt
@@ -155,7 +155,8 @@ or the
 :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
 method, which are documented in the
 :class:`~django.views.generic.base.TemplateResponseMixin` documentation.  The
-latter one allows you to use a different template for each form.
+latter one allows you to use a different template for each form (:ref:`see the
+example below <wizard-template-for-each-form>`).
 
 This template expects a ``wizard`` object that has various items attached to
 it:
@@ -238,6 +239,65 @@ wizard's :meth:`as_view` method takes a list of your
         (r'^contact/$', ContactWizard.as_view([ContactForm1, ContactForm2])),
     )
 
+.. _wizard-template-for-each-form:
+
+Using a different template for each form
+----------------------------------------
+
+As mentioned above, you may specify a different template for each form.
+Consider an example using a form wizard to implement a multi-step checkout
+process for an online store. In the first step, the user specifies a billing
+and shipping address. In the second step, the user chooses payment type. If
+they chose to pay by credit card, they will enter credit card information in
+the next step. In the final step, they will confirm the purchase.
+
+Here's what the view code might look like::
+
+    from django.http import HttpResponseRedirect
+    from django.contrib.formtools.wizard.views import SessionWizardView
+
+    FORMS = [("address", myapp.forms.AddressForm),
+             ("paytype", myapp.forms.PaymentChoiceForm),
+             ("cc", myapp.forms.CreditCardForm),
+             ("confirmation", myapp.forms.OrderForm)]
+
+    TEMPLATES = {"address": "checkout/billingaddress.html",
+                 "paytype": "checkout/paymentmethod.html",
+                 "cc": "checkout/creditcard.html",
+                 "confirmation": "checkout/confirmation.html"}
+
+    def pay_by_credit_card(wizard):
+        """Return true if user opts to pay by credit card"""
+        # Get cleaned data from payment step
+        cleaned_data = wizard.get_cleaned_data_for_step('paytype') or {'method': 'none'}
+        # Return true if the user selected credit card
+        return cleaned_data['method'] == 'cc'
+
+
+    class OrderWizard(SessionWizardView):
+        def get_template_names(self):
+            return [TEMPLATES[self.steps.current]]
+
+        def done(self, form_list, **kwargs):
+            do_something_with_the_form_data(form_list)
+            return HttpResponseRedirect('/page-to-redirect-to-when-done/')
+            ...
+
+The ``urls.py`` file would contain something like::
+
+    urlpatterns = patterns('',
+        (r'^checkout/$', OrderWizard.as_view(FORMS, condition_dict={'cc': pay_by_credit_card})),
+    )
+
+Note that the ``OrderWizard`` object is initialized with a list of pairs.
+The first element in the pair is a string that corresponds to the name of the
+step and the second is the form class.
+
+In this example, the
+:meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
+method returns a list containing a single template, which is selected based on
+the name of the current step.
+
 .. _wizardview-advanced-methods:
 
 Advanced ``WizardView`` methods
diff --git a/docs/ref/contrib/gis/install.txt b/docs/ref/contrib/gis/install.txt
index 5dc3726ad1..b815973202 100644
--- a/docs/ref/contrib/gis/install.txt
+++ b/docs/ref/contrib/gis/install.txt
@@ -959,15 +959,15 @@ Ubuntu & Debian GNU/Linux
 Ubuntu
 ^^^^^^
 
-11.10
-~~~~~
+11.10 through 12.04
+~~~~~~~~~~~~~~~~~~~
 
-In Ubuntu 11.10, PostgreSQL was upgraded to 9.1. The installation commands are:
+In Ubuntu 11.10, PostgreSQL was upgraded to 9.1. The installation command is:
 
 .. code-block:: bash
 
-    $ sudo apt-get install binutils gdal-bin libproj-dev postgresql-9.1-postgis \
-         postgresql-server-dev-9.1 python-psycopg2
+    $ sudo apt-get install binutils gdal-bin libproj-dev \
+         postgresql-9.1-postgis postgresql-server-dev-9.1 python-psycopg2
 
 .. _ubuntu10:
 
@@ -976,7 +976,7 @@ In Ubuntu 11.10, PostgreSQL was upgraded to 9.1. The installation commands are:
 
 In Ubuntu 10.04, PostgreSQL was upgraded to 8.4 and GDAL was upgraded to 1.6.
 Ubuntu 10.04 uses PostGIS 1.4, while Ubuntu 10.10 uses PostGIS 1.5 (with
-geography support).  The installation commands are:
+geography support).  The installation command is:
 
 .. code-block:: bash
 
diff --git a/docs/ref/contrib/gis/tutorial.txt b/docs/ref/contrib/gis/tutorial.txt
index 15863aee7b..ec265342b3 100644
--- a/docs/ref/contrib/gis/tutorial.txt
+++ b/docs/ref/contrib/gis/tutorial.txt
@@ -674,8 +674,8 @@ __ http://spatialreference.org/ref/epsg/32140/
 .. admonition:: Raw queries
 
     When using :doc:`raw queries </topics/db/sql>`, you should generally wrap
-    your geometry fields with the ``asText()`` SQL function so as the field
-    value will be recognized by GEOS::
+    your geometry fields with the ``asText()`` SQL function (or ``ST_AsText``
+    for PostGIS) so as the field value will be recognized by GEOS::
 
         City.objects.raw('SELECT id, name, asText(point) from myapp_city')
 
diff --git a/docs/ref/contrib/markup.txt b/docs/ref/contrib/markup.txt
index 8f3e0a95f9..9215c64f93 100644
--- a/docs/ref/contrib/markup.txt
+++ b/docs/ref/contrib/markup.txt
@@ -5,6 +5,9 @@ django.contrib.markup
 .. module:: django.contrib.markup
    :synopsis: A collection of template filters that implement common markup languages.
 
+.. deprecated:: 1.5
+    This module has been deprecated.
+
 Django provides template filters that implement the following markup
 languages:
 
diff --git a/docs/ref/contrib/messages.txt b/docs/ref/contrib/messages.txt
index 4cf90ee381..bc921a9d33 100644
--- a/docs/ref/contrib/messages.txt
+++ b/docs/ref/contrib/messages.txt
@@ -5,14 +5,16 @@ The messages framework
 .. module:: django.contrib.messages
    :synopsis: Provides cookie- and session-based temporary message storage.
 
-Quite commonly in web applications, you may need to display a one-time
-notification message (also know as "flash message") to the user after
-processing a form or some other types of user input. For this, Django provides
-full support for cookie- and session-based messaging, for both anonymous and
-authenticated users. The messages framework allows you to temporarily store
-messages in one request and retrieve them for display in a subsequent request
-(usually the next one). Every message is tagged with a specific ``level`` that
-determines its priority (e.g., ``info``, ``warning``, or ``error``).
+Quite commonly in web applications, you need to display a one-time
+notification message (also known as "flash message") to the user after
+processing a form or some other types of user input.
+
+For this, Django provides full support for cookie- and session-based
+messaging, for both anonymous and authenticated users. The messages framework
+allows you to temporarily store messages in one request and retrieve them for
+display in a subsequent request (usually the next one). Every message is
+tagged with a specific ``level`` that determines its priority (e.g., ``info``,
+``warning``, or ``error``).
 
 Enabling messages
 =================
@@ -20,32 +22,27 @@ Enabling messages
 Messages are implemented through a :doc:`middleware </ref/middleware>`
 class and corresponding :doc:`context processor </ref/templates/api>`.
 
-To enable message functionality, do the following:
-
-* Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
-  it contains ``'django.contrib.messages.middleware.MessageMiddleware'``.
+The default ``settings.py`` created by ``django-admin.py startproject``
+already contains all the settings required to enable message functionality:
 
-  If you are using a :ref:`storage backend <message-storage-backends>` that
-  relies on :doc:`sessions </topics/http/sessions>` (the default),
-  ``'django.contrib.sessions.middleware.SessionMiddleware'`` must be
-  enabled and appear before ``MessageMiddleware`` in your
-  :setting:`MIDDLEWARE_CLASSES`.
+* ``'django.contrib.messages'`` is in :setting:`INSTALLED_APPS`.
 
-* Edit the :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting and make sure
-  it contains ``'django.contrib.messages.context_processors.messages'``.
+* :setting:`MIDDLEWARE_CLASSES` contains
+  ``'django.contrib.sessions.middleware.SessionMiddleware'`` and
+  ``'django.contrib.messages.middleware.MessageMiddleware'``.
 
-* Add ``'django.contrib.messages'`` to your :setting:`INSTALLED_APPS`
-  setting
+  The default :ref:`storage backend <message-storage-backends>` relies on
+  :doc:`sessions </topics/http/sessions>`. That's why ``SessionMiddleware``
+  must be enabled and appear before ``MessageMiddleware`` in
+  :setting:`MIDDLEWARE_CLASSES`.
 
-The default ``settings.py`` created by ``django-admin.py startproject`` has
-``MessageMiddleware`` activated and the ``django.contrib.messages`` app
-installed. Also, the default value for :setting:`TEMPLATE_CONTEXT_PROCESSORS`
-contains ``'django.contrib.messages.context_processors.messages'``.
+* :setting:`TEMPLATE_CONTEXT_PROCESSORS`   contains
+  ``'django.contrib.messages.context_processors.messages'``.
 
-If you don't want to use messages, you can remove the
-``MessageMiddleware`` line from :setting:`MIDDLEWARE_CLASSES`, the ``messages``
-context processor from :setting:`TEMPLATE_CONTEXT_PROCESSORS` and
-``'django.contrib.messages'`` from your :setting:`INSTALLED_APPS`.
+If you don't want to use messages, you can remove
+``'django.contrib.messages'`` from your :setting:`INSTALLED_APPS`, the
+``MessageMiddleware`` line from :setting:`MIDDLEWARE_CLASSES`, and the
+``messages`` context processor from :setting:`TEMPLATE_CONTEXT_PROCESSORS`.
 
 Configuring the message engine
 ==============================
@@ -56,34 +53,35 @@ Storage backends
 ----------------
 
 The messages framework can use different backends to store temporary messages.
-If the default FallbackStorage isn't suitable to your needs, you can change
-which backend is being used by adding a `MESSAGE_STORAGE`_ to your
-settings, referencing the module and class of the storage class. For
-example::
 
-    MESSAGE_STORAGE = 'django.contrib.messages.storage.cookie.CookieStorage'
+Django provides three built-in storage classes:
 
-The value should be the full path of the desired storage class.
+.. class:: django.contrib.messages.storage.session.SessionStorage
 
-Three storage classes are available:
+    This class stores all messages inside of the request's session. Therefore
+    it requires Django's ``contrib.sessions`` application.
 
-``'django.contrib.messages.storage.session.SessionStorage'``
-    This class stores all messages inside of the request's session. It
-    requires Django's ``contrib.sessions`` application.
+.. class:: django.contrib.messages.storage.cookie.CookieStorage
 
-``'django.contrib.messages.storage.cookie.CookieStorage'``
     This class stores the message data in a cookie (signed with a secret hash
     to prevent manipulation) to persist notifications across requests. Old
-    messages are dropped if the cookie data size would exceed 4096 bytes.
+    messages are dropped if the cookie data size would exceed 2048 bytes.
+
+.. class:: django.contrib.messages.storage.fallback.FallbackStorage
 
-``'django.contrib.messages.storage.fallback.FallbackStorage'``
-    This is the default storage class.
+    This class first uses ``CookieStorage``, and falls back to using
+    ``SessionStorage`` for the messages that could not fit in a single cookie.
+    It also requires Django's ``contrib.sessions`` application.
 
-    This class first uses CookieStorage for all messages, falling back to using
-    SessionStorage for the messages that could not fit in a single cookie.
+    This behavior avoids writing to the session whenever possible. It should
+    provide the best performance in the general case.
 
-    Since it is uses SessionStorage, it also requires Django's
-    ``contrib.sessions`` application.
+:class:`~django.contrib.messages.storage.fallback.FallbackStorage` is the
+default storage class. If it isn't suitable to your needs, you can select
+another storage class by setting `MESSAGE_STORAGE`_ to its full import path,
+for example::
+
+    MESSAGE_STORAGE = 'django.contrib.messages.storage.cookie.CookieStorage'
 
 To write your own storage class, subclass the ``BaseStorage`` class in
 ``django.contrib.messages.storage.base`` and implement the ``_get`` and
@@ -97,8 +95,8 @@ to that of the Python logging module. Message levels allow you to group
 messages by type so they can be filtered or displayed differently in views and
 templates.
 
-The built-in levels (which can be imported from ``django.contrib.messages``
-directly) are:
+The built-in levels, which can be imported from ``django.contrib.messages``
+directly, are:
 
 =========== ========
 Constant    Purpose
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
index 082ec17a35..7c06bf97ee 100644
--- a/docs/ref/forms/fields.txt
+++ b/docs/ref/forms/fields.txt
@@ -398,11 +398,21 @@ For each field, we describe the default widget used if you don't specify
 
     If no ``input_formats`` argument is provided, the default input formats are::
 
-        '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
-        '%b %d %Y', '%b %d, %Y',            # 'Oct 25 2006', 'Oct 25, 2006'
-        '%d %b %Y', '%d %b, %Y',            # '25 Oct 2006', '25 Oct, 2006'
-        '%B %d %Y', '%B %d, %Y',            # 'October 25 2006', 'October 25, 2006'
-        '%d %B %Y', '%d %B, %Y',            # '25 October 2006', '25 October, 2006'
+        '%Y-%m-%d',       # '2006-10-25'
+        '%m/%d/%Y',       # '10/25/2006'
+        '%m/%d/%y',       # '10/25/06'
+
+    Additionally, if you specify :setting:`USE_L10N=False<USE_L10N>` in your settings, the
+    following will also be included in the default input formats::
+
+        '%b %m %d',       # 'Oct 25 2006'
+        '%b %d, %Y',      # 'Oct 25, 2006'
+        '%d %b %Y',       # '25 Oct 2006'
+        '%d %b, %Y',      # '25 Oct, 2006'
+        '%B %d %Y',       # 'October 25 2006'
+        '%B %d, %Y',      # 'October 25, 2006'
+        '%d %B %Y',       # '25 October 2006'
+        '%d %B, %Y',      # '25 October, 2006'
 
 ``DateTimeField``
 ~~~~~~~~~~~~~~~~~
@@ -842,7 +852,7 @@ Slightly complex built-in ``Field`` classes
 ``MultiValueField``
 ~~~~~~~~~~~~~~~~~~~
 
-.. class:: MultiValueField(**kwargs)
+.. class:: MultiValueField(fields=(), **kwargs)
 
     * Default widget: ``TextInput``
     * Empty value: ``''`` (an empty string)
@@ -851,22 +861,39 @@ Slightly complex built-in ``Field`` classes
       as an argument to the ``MultiValueField``.
     * Error message keys: ``required``, ``invalid``
 
-    This abstract field (must be subclassed) aggregates the logic of multiple
-    fields. Subclasses should not have to implement clean(). Instead, they must
-    implement compress(), which takes a list of valid values and returns a
-    "compressed" version of those values -- a single value.  For example,
-    :class:`SplitDateTimeField` is a subclass which combines a time field and
-    a date field into a datetime object.
+    Aggregates the logic of multiple fields that together produce a single
+    value.
+
+    This field is abstract and must be subclassed. In contrast with the
+    single-value fields, subclasses of :class:`MultiValueField` must not
+    implement :meth:`~django.forms.Field.clean` but instead - implement
+    :meth:`~MultiValueField.compress`.
 
     Takes one extra required argument:
 
     .. attribute:: fields
 
-        A list of fields which are cleaned into a single field. Each value in
-        ``clean`` is cleaned by the corresponding field in ``fields`` -- the first
-        value is cleaned by the first field, the second value is cleaned by
-        the second field, etc.  Once all fields are cleaned, the list of clean
-        values is "compressed" into a single value.
+        A tuple of fields whose values are cleaned and subsequently combined
+        into a single value.  Each value of the field is cleaned by the
+        corresponding field in ``fields`` -- the first value is cleaned by the
+        first field, the second value is cleaned by the second field, etc.
+        Once all fields are cleaned, the list of clean values is combined into
+        a single value by :meth:`~MultiValueField.compress`.
+
+    .. attribute:: MultiValueField.widget
+
+        Must be a subclass of :class:`django.forms.MultiWidget`.
+        Default value is :class:`~django.forms.widgets.TextInput`, which
+        probably is not very useful in this case.
+
+    .. method:: compress(data_list)
+
+        Takes a list of valid values and returns  a "compressed" version of
+        those values -- in a single value. For example,
+        :class:`SplitDateTimeField` is a subclass which combines a time field
+        and a date field into a ``datetime`` object.
+
+        This method must be implemented in the subclasses.
 
 ``SplitDateTimeField``
 ~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
index eab314a4cd..4724cbdec2 100644
--- a/docs/ref/forms/widgets.txt
+++ b/docs/ref/forms/widgets.txt
@@ -11,6 +11,16 @@ A widget is Django's representation of a HTML input element. The widget
 handles the rendering of the HTML, and the extraction of data from a GET/POST
 dictionary that corresponds to the widget.
 
+.. tip::
+
+    Widgets should not be confused with the :doc:`form fields </ref/forms/fields>`.
+    Form fields deal with the logic of input validation and are used directly
+    in templates. Widgets deal with rendering of HTML form input elements on
+    the web page and extraction of raw submitted data. However, widgets do
+    need to be :ref:`assigned <widget-to-field>` to form fields.
+
+.. _widget-to-field:
+
 Specifying widgets
 ------------------
 
@@ -95,15 +105,23 @@ choices are inherent to the model and not just the representational widget.
 Customizing widget instances
 ----------------------------
 
-When Django renders a widget as HTML, it only renders the bare minimum
-HTML - Django doesn't add a class definition, or any other widget-specific
-attributes. This means that all :class:`TextInput` widgets will appear the same
-on your Web page.
+When Django renders a widget as HTML, it only renders very minimal markup -
+Django doesn't add class names, or any other widget-specific attributes. This
+means, for example, that all :class:`TextInput` widgets will appear the same
+on your Web pages.
+
+There are two ways to customize widgets: :ref:`per widget instance
+<styling-widget-instances>` and :ref:`per widget class <styling-widget-classes>`.
 
-If you want to make one widget look different to another, you need to
-specify additional attributes for each widget. When you specify a
-widget, you can provide a list of attributes that will be added to the
-rendered HTML for the widget.
+.. _styling-widget-instances:
+
+Styling widget instances
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you want to make one widget instance look different from another, you will
+need to specify additional attributes at the time when the widget object is
+instantiated and assigned to a form field (and perhaps add some rules to your
+CSS files).
 
 For example, take the following simple form::
 
@@ -126,10 +144,9 @@ provided for each widget will be rendered exactly the same::
 
 On a real Web page, you probably don't want every widget to look the same. You
 might want a larger input element for the comment, and you might want the
-'name' widget to have some special CSS class. To do this, you use the
-:attr:`Widget.attrs` argument when creating the widget:
-
-For example::
+'name' widget to have some special CSS class. It is also possible to specify
+the 'type' attribute to take advantage of the new HTML5 input types.  To do
+this, you use the :attr:`Widget.attrs` argument when creating the widget::
 
     class CommentForm(forms.Form):
         name = forms.CharField(
@@ -146,24 +163,41 @@ Django will then include the extra attributes in the rendered output:
     <tr><th>Url:</th><td><input type="text" name="url"/></td></tr>
     <tr><th>Comment:</th><td><input type="text" name="comment" size="40"/></td></tr>
 
-.. _built-in widgets:
+.. _styling-widget-classes:
 
-Built-in widgets
-----------------
+Styling widget classes
+^^^^^^^^^^^^^^^^^^^^^^
 
-Django provides a representation of all the basic HTML widgets, plus some
-commonly used groups of widgets:
+With widgets, it is possible to add media (``css`` and ``javascript``)
+and more deeply customize their appearance and behavior.
 
-``Widget``
-~~~~~~~~~~
+In a nutshell, you will need to subclass the widget and either
+:ref:`define a class "Media" <media-as-a-static-definition>` as a member of the
+subclass, or :ref:`create a property "media" <dynamic-property>`, returning an
+instance of that class.
+
+These methods involve somewhat advanced Python programming and are described in
+detail in the :doc:`Form Media </topics/forms/media>` topic guide.
+
+.. _base-widget-classes:
+
+Base Widget classes
+-------------------
 
-.. class:: Widget
+Base widget classes :class:`Widget` and :class:`MultiWidget` are subclassed by
+all the :ref:`built-in widgets <built-in widgets>` and may serve as a
+foundation for custom widgets.
 
-    This abstract class cannot be rendered, but provides the basic attribute :attr:`~Widget.attrs`.
+.. class:: Widget(attrs=None)
+
+    This abstract class cannot be rendered, but provides the basic attribute
+    :attr:`~Widget.attrs`.  You may also implement or override the
+    :meth:`~Widget.render()` method on custom widgets.
 
     .. attribute:: Widget.attrs
 
-        A dictionary containing HTML attributes to be set on the rendered widget.
+        A dictionary containing HTML attributes to be set on the rendered
+        widget.
 
         .. code-block:: python
 
@@ -171,6 +205,74 @@ commonly used groups of widgets:
             >>> name.render('name', 'A name')
             u'<input title="Your name" type="text" name="name" value="A name" size="10" />'
 
+    .. method:: render(name, value, attrs=None)
+
+        Returns HTML for the widget, as a Unicode string. This method must be
+        implemented by the subclass, otherwise ``NotImplementedError`` will be
+        raised.
+
+        The 'value' given is not guaranteed to be valid input, therefore
+        subclass implementations should program defensively.
+
+.. class:: MultiWidget(widgets, attrs=None)
+
+    A widget that is composed of multiple widgets.
+    :class:`~django.forms.widgets.MultiWidget` works hand in hand with the
+    :class:`~django.forms.MultiValueField`.
+
+    .. method:: render(name, value, attrs=None)
+
+        Argument `value` is handled differently in this method from the
+        subclasses of :class:`~Widget`.
+
+        If `value` is a list, output of :meth:`~MultiWidget.render` will be a
+        concatenation of rendered child widgets. If `value` is not a list, it
+        will be first processed by the method :meth:`~MultiWidget.decompress()`
+        to create the list and then processed as above.
+
+        Unlike in the single value widgets, method :meth:`~MultiWidget.render`
+        need not be implemented in the subclasses.
+
+    .. method:: decompress(value)
+
+        Returns a list of "decompressed" values for the given value of the
+        multi-value field that makes use of the widget. The input value can be
+        assumed as valid, but not necessarily non-empty.
+
+        This method **must be implemented** by the subclass, and since the
+        value may be empty, the implementation must be defensive.
+
+        The rationale behind "decompression" is that it is necessary to "split"
+        the combined value of the form field into the values of the individual
+        field encapsulated within the multi-value field (e.g. when displaying
+        the partially or fully filled-out form).
+
+        .. tip::
+
+            Note that :class:`~django.forms.MultiValueField` has a
+            complementary method :meth:`~django.forms.MultiValueField.compress`
+            with the opposite responsibility - to combine cleaned values of
+            all member fields into one.
+
+
+.. _built-in widgets:
+
+Built-in widgets
+----------------
+
+Django provides a representation of all the basic HTML widgets, plus some
+commonly used groups of widgets in the ``django.forms.widgets`` module,
+including :ref:`the input of text <text-widgets>`, :ref:`various checkboxes
+and selectors <selector-widgets>`, :ref:`uploading files <file-upload-widgets>`,
+and :ref:`handling of multi-valued input <composite-widgets>`.
+
+.. _text-widgets:
+
+Widgets handling input of text
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These widgets make use of the HTML elements ``input`` and ``textarea``.
+
 ``TextInput``
 ~~~~~~~~~~~~~
 
@@ -204,39 +306,8 @@ commonly used groups of widgets:
 
     Hidden input: ``<input type='hidden' ...>``
 
-``MultipleHiddenInput``
-~~~~~~~~~~~~~~~~~~~~~~~
-
-.. class:: MultipleHiddenInput
-
-    Multiple ``<input type='hidden' ...>`` widgets.
-
-    A widget that handles multiple hidden widgets for fields that have a list
-    of values.
-
-    .. attribute:: MultipleHiddenInput.choices
-
-        This attribute is optional when the field does not have a
-        :attr:`~Field.choices` attribute. If it does, it will override anything
-        you set here when the attribute is updated on the :class:`Field`.
-
-``FileInput``
-~~~~~~~~~~~~~
-
-.. class:: FileInput
-
-    File upload input: ``<input type='file' ...>``
-
-``ClearableFileInput``
-~~~~~~~~~~~~~~~~~~~~~~
-
-.. class:: ClearableFileInput
-
-    .. versionadded:: 1.3
-
-    File upload input: ``<input type='file' ...>``, with an additional checkbox
-    input to clear the field's value, if the field is not required and has
-    initial data.
+    Note that there also is a :class:`MultipleHiddenInput` widget that
+    encapsulates a set of hidden input elements.
 
 ``DateInput``
 ~~~~~~~~~~~~~
@@ -245,7 +316,7 @@ commonly used groups of widgets:
 
     Date input as a simple text box: ``<input type='text' ...>``
 
-    Takes one optional argument:
+    Takes same arguments as :class:`TextInput`, with one more optional argument:
 
     .. attribute:: DateInput.format
 
@@ -262,7 +333,7 @@ commonly used groups of widgets:
 
     Date/time input as a simple text box: ``<input type='text' ...>``
 
-    Takes one optional argument:
+    Takes same arguments as :class:`TextInput`, with one more optional argument:
 
     .. attribute:: DateTimeInput.format
 
@@ -279,7 +350,7 @@ commonly used groups of widgets:
 
     Time input as a simple text box: ``<input type='text' ...>``
 
-    Takes one optional argument:
+    Takes same arguments as :class:`TextInput`, with one more optional argument:
 
     .. attribute:: TimeInput.format
 
@@ -296,6 +367,11 @@ commonly used groups of widgets:
 
     Text area: ``<textarea>...</textarea>``
 
+.. _selector-widgets:
+
+Selector and checkbox widgets
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 ``CheckboxInput``
 ~~~~~~~~~~~~~~~~~
 
@@ -439,6 +515,50 @@ commonly used groups of widgets:
           ...
         </ul>
 
+.. _file-upload-widgets:
+
+File upload widgets
+^^^^^^^^^^^^^^^^^^^
+
+``FileInput``
+~~~~~~~~~~~~~
+
+.. class:: FileInput
+
+    File upload input: ``<input type='file' ...>``
+
+``ClearableFileInput``
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. class:: ClearableFileInput
+
+    .. versionadded:: 1.3
+
+    File upload input: ``<input type='file' ...>``, with an additional checkbox
+    input to clear the field's value, if the field is not required and has
+    initial data.
+
+.. _composite-widgets:
+
+Composite widgets
+^^^^^^^^^^^^^^^^^
+
+``MultipleHiddenInput``
+~~~~~~~~~~~~~~~~~~~~~~~
+
+.. class:: MultipleHiddenInput
+
+    Multiple ``<input type='hidden' ...>`` widgets.
+
+    A widget that handles multiple hidden widgets for fields that have a list
+    of values.
+
+    .. attribute:: MultipleHiddenInput.choices
+
+        This attribute is optional when the field does not have a
+        :attr:`~Field.choices` attribute. If it does, it will override anything
+        you set here when the attribute is updated on the :class:`Field`.
+
 ``MultiWidget``
 ~~~~~~~~~~~~~~~
 
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 275c696230..8b3c31f029 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -195,6 +195,14 @@ support tablespaces for indexes, this option is ignored.
 The default value for the field. This can be a value or a callable object. If
 callable it will be called every time a new object is created.
 
+The default cannot be a mutable object (model instance, list, set, etc.), as a
+reference to the same instance of that object would be used as the default
+value in all new model instances. Instead, wrap the desired default in a
+callable.  For example, if you had a custom ``JSONField`` and wanted to specify
+a dictionary as the default, use a ``lambda`` as follows::
+
+    contact_info = JSONField("ContactInfo", default=lambda:{"email": "to1@example.com"})
+
 ``editable``
 ------------
 
@@ -983,10 +991,10 @@ define the details of how the relation works.
     this with functions from the Python ``datetime`` module to limit choices of
     objects by date. For example::
 
-        limit_choices_to = {'pub_date__lte': datetime.now}
+        limit_choices_to = {'pub_date__lte': datetime.date.today}
 
     only allows the choice of related objects with a ``pub_date`` before the
-    current date/time to be chosen.
+    current date to be chosen.
 
     Instead of a dictionary this can also be a :class:`~django.db.models.Q`
     object for more :ref:`complex queries <complex-lookups-with-q>`. However,
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index 472ac96457..2fdc87df8c 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -135,7 +135,7 @@ access to more than a single field::
             raise ValidationError('Draft entries may not have a publication date.')
         # Set the pub_date for published items if it hasn't been set already.
         if self.status == 'published' and self.pub_date is None:
-            self.pub_date = datetime.datetime.now()
+            self.pub_date = datetime.date.today()
 
 Any :exc:`~django.core.exceptions.ValidationError` exceptions raised by
 ``Model.clean()`` will be stored in a special key error dictionary key,
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index 4f5f8858b5..8ec7cfc791 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -31,6 +31,9 @@ You can evaluate a ``QuerySet`` in the following ways:
       for e in Entry.objects.all():
           print(e.headline)
 
+  Note: Don't use this if all you want to do is determine if at least one
+  result exists. It's more efficient to use :meth:`~QuerySet.exists`.
+
 * **Slicing.** As explained in :ref:`limiting-querysets`, a ``QuerySet`` can
   be sliced, using Python's array-slicing syntax. Slicing an unevaluated
   ``QuerySet`` usually returns another unevaluated ``QuerySet``, but Django
@@ -75,7 +78,7 @@ You can evaluate a ``QuerySet`` in the following ways:
 
   Note: *Don't* use this if all you want to do is determine if at least one
   result exists, and don't need the actual objects. It's more efficient to
-  use :meth:`exists() <QuerySet.exists>` (see below).
+  use :meth:`~QuerySet.exists` (see below).
 
 .. _pickling QuerySets:
 
@@ -1047,7 +1050,7 @@ defer
 In some complex data-modeling situations, your models might contain a lot of
 fields, some of which could contain a lot of data (for example, text fields),
 or require expensive processing to convert them to Python objects. If you are
-using the results of a queryset in some situation where you know you don't know
+using the results of a queryset in some situation where you don't know
 if you need those particular fields when you initially fetch the data, you can
 tell Django not to retrieve them from the database.
 
@@ -1523,9 +1526,40 @@ exists
 
 Returns ``True`` if the :class:`.QuerySet` contains any results, and ``False``
 if not. This tries to perform the query in the simplest and fastest way
-possible, but it *does* execute nearly the same query. This means that calling
-:meth:`.QuerySet.exists` is faster than ``bool(some_query_set)``, but not by
-a large degree. If ``some_query_set`` has not yet been evaluated, but you know
+possible, but it *does* execute nearly the same query as a normal
+:class:`.QuerySet` query.
+
+:meth:`~.QuerySet.exists` is useful for searches relating to both
+object membership in a :class:`.QuerySet` and to the existence of any objects in
+a :class:`.QuerySet`, particularly in the context of a large :class:`.QuerySet`.
+
+The most efficient method of finding whether a model with a unique field
+(e.g. ``primary_key``) is a member of a :class:`.QuerySet` is::
+
+    entry = Entry.objects.get(pk=123)
+    if some_query_set.filter(pk=entry.pk).exists():
+        print("Entry contained in queryset")
+
+Which will be faster than the following which requires evaluating and iterating
+through the entire queryset::
+
+    if entry in some_query_set:
+       print("Entry contained in QuerySet")
+
+And to find whether a queryset contains any items::
+
+    if some_query_set.exists():
+        print("There is at least one object in some_query_set")
+
+Which will be faster than::
+
+    if some_query_set:
+        print("There is at least one object in some_query_set")
+
+... but not by a large degree (hence needing a large queryset for efficiency
+gains).
+
+Additionally, if a ``some_query_set`` has not yet been evaluated, but you know
 that it will be at some point, then using ``some_query_set.exists()`` will do
 more overall work (one query for the existence check plus an extra one to later
 retrieve the results) than simply using ``bool(some_query_set)``, which
@@ -1945,6 +1979,17 @@ SQL equivalent::
 You can use ``range`` anywhere you can use ``BETWEEN`` in SQL — for dates,
 numbers and even characters.
 
+.. warning::
+
+    Filtering a ``DateTimeField`` with dates won't include items on the last
+    day, because the bounds are interpreted as "0am on the given date". If
+    ``pub_date`` was a ``DateTimeField``, the above expression would be turned
+    into this SQL::
+
+        SELECT ... WHERE pub_date BETWEEN '2005-01-01 00:00:00' and '2005-03-31 00:00:00';
+
+    Generally speaking, you can't mix dates and datetimes.
+
 .. fieldlookup:: year
 
 year
@@ -1958,7 +2003,7 @@ Example::
 
 SQL equivalent::
 
-    SELECT ... WHERE pub_date BETWEEN '2005-01-01' AND '2005-12-31 23:59:59.999999';
+    SELECT ... WHERE pub_date BETWEEN '2005-01-01' AND '2005-12-31';
 
 (The exact SQL syntax varies for each database engine.)
 
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 4729a2b6f1..16d067172d 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -1304,25 +1304,13 @@ The URL where requests are redirected after login when the
 This is used by the :func:`~django.contrib.auth.decorators.login_required`
 decorator, for example.
 
-.. _`note on LOGIN_REDIRECT_URL setting`:
-
-.. note::
-    You can use :func:`~django.core.urlresolvers.reverse_lazy` to reference
-    URLs by their name instead of providing a hardcoded value. Assuming a
-    ``urls.py`` with an URLpattern named ``home``::
-
-        urlpatterns = patterns('',
-            url('^welcome/$', 'test_app.views.home', name='home'),
-        )
-
-    You can use :func:`~django.core.urlresolvers.reverse_lazy` like this::
-
-        from django.core.urlresolvers import reverse_lazy
-
-        LOGIN_REDIRECT_URL = reverse_lazy('home')
+.. versionchanged:: 1.5
 
-    This also works fine with localized URLs using
-    :func:`~django.conf.urls.i18n.i18n_patterns`.
+This setting now also accepts view function names and
+:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
+configuration duplication since you no longer have to define the URL in two
+places (``settings`` and URLconf).
+For backward compatibility reasons the default remains unchanged.
 
 .. setting:: LOGIN_URL
 
@@ -1334,8 +1322,13 @@ Default: ``'/accounts/login/'``
 The URL where requests are redirected for login, especially when using the
 :func:`~django.contrib.auth.decorators.login_required` decorator.
 
-.. note::
-    See the `note on LOGIN_REDIRECT_URL setting`_
+.. versionchanged:: 1.5
+
+This setting now also accepts view function names and
+:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
+configuration duplication since you no longer have to define the URL in two
+places (``settings`` and URLconf).
+For backward compatibility reasons the default remains unchanged.
 
 .. setting:: LOGOUT_URL
 
@@ -1346,9 +1339,6 @@ Default: ``'/accounts/logout/'``
 
 LOGIN_URL counterpart.
 
-.. note::
-    See the `note on LOGIN_REDIRECT_URL setting`_
-
 .. setting:: MANAGERS
 
 MANAGERS