gis: Merged revisions 7837-7838,7842-7852,7856-7869,7871,7876-7877,7882-7891,7900-7917 via svnmerge from trunk.

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

15 files changed, 253 insertions, 208 deletions

diff --git a/docs/contributing.txt b/docs/contributing.txt
index 686c440c96..f3bee14069 100644
--- a/docs/contributing.txt
+++ b/docs/contributing.txt
@@ -392,7 +392,7 @@ translated, here's what to do:
     * Create translations using the methods described in the
       `i18n documentation`_.
     * Create a diff of the ``.po`` file against the current Subversion trunk.
-    * Make sure that `` bin/compile-messages.py -l <lang>`` runs without
+    * Make sure that `` django-admin.py compilemessages -l <lang>`` runs without
       producing any warnings.
     * Attach the patch to a ticket in Django's ticket system.
 
@@ -738,6 +738,11 @@ If you're using another backend:
       deleted when the tests are finished. This means your user account needs
       permission to execute ``CREATE DATABASE``.
 
+You will also need to ensure that your database uses UTF-8 as the default
+character set. If your database server doesn't use UTF-8 as a default charset,
+you will need to include a value for ``TEST_DATABASE_CHARSET`` in your settings
+file.
+   
 If you want to run the full suite of tests, you'll need to install a number of
 dependencies:
 
diff --git a/docs/db-api.txt b/docs/db-api.txt
index 9a604bf320..5fdcd946bd 100644
--- a/docs/db-api.txt
+++ b/docs/db-api.txt
@@ -2212,6 +2212,18 @@ updated is that it can only access one database table, the model's main
 table. So don't try to filter based on related fields or anything like that;
 it won't work.
 
+Be aware that the ``update()`` method is converted directly to an SQL
+statement. It is a bulk operation for direct updates. It doesn't run any
+``save()`` methods on your models, or emit the ``pre_save`` or ``post_save``
+signals (which are a consequence of calling ``save()``). If you want to save
+every item in a ``QuerySet`` and make sure that the ``save()`` method is
+called on each instance, you don't need any special function to handle that.
+Just loop over them and call ``save()``:
+
+    for item in my_queryset:
+        item.save()
+
+
 Extra instance methods
 ======================
 
diff --git a/docs/django-admin.txt b/docs/django-admin.txt
index 309166fe94..f5cc02ee52 100644
--- a/docs/django-admin.txt
+++ b/docs/django-admin.txt
@@ -85,6 +85,32 @@ your admin's index page. See `Tutorial 2`_ for more information.
 
 .. _Tutorial 2: ../tutorial02/
 
+cleanup 
+-------
+
+**New in Django development version**
+
+Can be run as a cronjob or directly to clean out old data from the database
+(only expired sessions at the moment).
+
+compilemessages
+---------------
+
+**New in Django development version**
+
+Compiles .po files created with ``makemessages`` to .mo files for use with
+the builtin gettext support. See the `i18n documentation`_ for details.
+
+--locale
+~~~~~~~~
+
+Use the ``--locale`` or ``-l`` option to specify the locale to process.
+If not provided all locales are processed.
+
+Example usage::
+
+    django-admin.py compilemessages --locale=br_PT
+
 createcachetable <tablename>
 ----------------------------
 
@@ -362,6 +388,62 @@ Example usage::
 
     django-admin.py loaddata --verbosity=2
 
+makemessages
+------------
+
+**New in Django development version**
+
+Runs over the entire source tree of the current directory and pulls out all
+strings marked for translation. It creates (or updates) a message file in the
+conf/locale (in the django tree) or locale (for project and application)
+directory. After making changes to the messages files you need to compile them
+with ``compilemessages`` for use with the builtin gettext support. See the
+`i18n documentation`_ for details.
+
+.. _i18n documentation: ../i18n/#how-to-create-language-files
+
+--all
+~~~~~
+
+Use the ``--all`` or ``-a`` option to update the message files for all
+available languages.
+
+Example usage::
+
+    django-admin.py makemessages --all
+
+--locale
+~~~~~~~~
+
+Use the ``--locale`` or ``-l`` option to specify the locale to process.
+
+Example usage::
+
+    django-admin.py makemessages --locale=br_PT
+
+--domain
+~~~~~~~~
+
+Use the ``--domain`` or ``-d`` option to change the domain of the messages files.
+Currently supported:
+
+	* ``django`` for all ``*.py`` and ``*.html`` files (default) 
+	* ``djangojs`` for ``*.js`` files
+
+--verbosity
+~~~~~~~~~~~
+
+Use ``--verbosity`` or ``-v`` to specify the amount of notification and debug
+information that ``django-admin.py`` should print to the console.
+
+	* ``0`` means no output.
+	* ``1`` means normal output (default).
+	* ``2`` means verbose output.
+
+Example usage::
+
+    django-admin.py makemessages --verbosity=2
+
 reset <appname appname ...>
 ---------------------------
 
diff --git a/docs/generic_views.txt b/docs/generic_views.txt
index b7beb0b4be..c4fea21016 100644
--- a/docs/generic_views.txt
+++ b/docs/generic_views.txt
@@ -816,15 +816,14 @@ specify the page number in the URL in one of two ways:
 These values and lists are 1-based, not 0-based, so the first page would be
 represented as page ``1``. 
 
-An example of the use of pagination can be found in the `object pagination`_
-example model. 
+For more on pagination, read the `pagination documentation`_.
 	 
-.. _`object pagination`: ../models/pagination/
+.. _`pagination documentation`: ../pagination/
 
 **New in Django development version:** 
 
-As a special case, you are also permitted to use 
-``last`` as a value for ``page``::
+As a special case, you are also permitted to use ``last`` as a value for
+``page``::
 
     /objects/?page=last
 
diff --git a/docs/i18n.txt b/docs/i18n.txt
index d6c86e1c9d..c221b43718 100644
--- a/docs/i18n.txt
+++ b/docs/i18n.txt
@@ -122,8 +122,8 @@ Translation works on variables. Again, here's an identical example::
 
 (The caveat with using variables or computed values, as in the previous two
 examples, is that Django's translation-string-detecting utility,
-``make-messages.py``, won't be able to find these strings. More on
-``make-messages`` later.)
+``django-admin.py makemessages``, won't be able to find these strings. More on
+``makemessages`` later.)
 
 The strings you pass to ``_()`` or ``ugettext()`` can take placeholders,
 specified with Python's standard named-string interpolation syntax. Example::
@@ -266,10 +266,11 @@ Internally, all block and inline translations use the appropriate
 Each ``RequestContext`` has access to three translation-specific variables:
 
     * ``LANGUAGES`` is a list of tuples in which the first element is the
-      language code and the second is the language name (in that language).
+      language code and the second is the language name (translated into the
+      currently active locale).
     * ``LANGUAGE_CODE`` is the current user's preferred language, as a string.
       Example: ``en-us``. (See "How language preference is discovered", below.)
-    * ``LANGUAGE_BIDI`` is the current language's direction. If True, it's a
+    * ``LANGUAGE_BIDI`` is the current locale's direction. If True, it's a
       right-to-left language, e.g: Hebrew, Arabic. If False it's a
       left-to-right language, e.g: English, French, German etc.
 
@@ -392,12 +393,17 @@ file is a plain-text file, representing a single language, that contains all
 available translation strings and how they should be represented in the given
 language. Message files have a ``.po`` file extension.
 
-Django comes with a tool, ``bin/make-messages.py``, that automates the creation
-and upkeep of these files.
+Django comes with a tool, ``django-admin.py makemessages``, that automates the
+creation and upkeep of these files. 
+
+.. admonition:: A note to Django veterans
+
+    The old tool ``bin/make-messages.py`` has been moved to the command
+    ``django-admin.py makemessages`` to provide consistency throughout Django.
 
 To create or update a message file, run this command::
 
-    bin/make-messages.py -l de
+    django-admin.py makemessages -l de
 
 ...where ``de`` is the language code for the message file you want to create.
 The language code, in this case, is in locale format. For example, it's
@@ -422,11 +428,11 @@ do the same, but the location of the locale directory is ``locale/LANG/LC_MESSAG
 
 .. admonition:: No gettext?
 
-    If you don't have the ``gettext`` utilities installed, ``make-messages.py``
-    will create empty files. If that's the case, either install the ``gettext``
-    utilities or just copy the English message file
-    (``conf/locale/en/LC_MESSAGES/django.po``) and use it as a starting point;
-    it's just an empty translation file.
+    If you don't have the ``gettext`` utilities installed,
+    ``django-admin.py makemessages`` will create empty files. If that's the
+    case, either install the ``gettext`` utilities or just copy the English
+    message file (``conf/locale/en/LC_MESSAGES/django.po``) and use it as a
+    starting point; it's just an empty translation file.
 
 The format of ``.po`` files is straightforward. Each ``.po`` file contains a
 small bit of metadata, such as the translation maintainer's contact
@@ -439,8 +445,8 @@ For example, if your Django app contained a translation string for the text
 
     _("Welcome to my site.")
 
-...then ``make-messages.py`` will have created a ``.po`` file containing the
-following snippet -- a message::
+...then ``django-admin.py makemessages`` will have created a ``.po`` file
+containing the following snippet -- a message::
 
     #: path/to/python/module.py:23
     msgid "Welcome to my site."
@@ -475,24 +481,30 @@ otherwise, they'll be tacked together without whitespace!
 To reexamine all source code and templates for new translation strings and
 update all message files for **all** languages, run this::
 
-    make-messages.py -a
+    django-admin.py makemessages -a
 
 Compiling message files
 -----------------------
 
 After you create your message file -- and each time you make changes to it --
 you'll need to compile it into a more efficient form, for use by ``gettext``.
-Do this with the ``bin/compile-messages.py`` utility.
+Do this with the ``django-admin.py compilemessages`` utility.
 
 This tool runs over all available ``.po`` files and creates ``.mo`` files,
 which are binary files optimized for use by ``gettext``. In the same directory
-from which you ran ``make-messages.py``, run ``compile-messages.py`` like
-this::
+from which you ran ``django-admin.py makemessages``, run
+``django-admin.py compilemessages`` like this::
 
-   bin/compile-messages.py
+   django-admin.py compilemessages
 
 That's it. Your translations are ready for use.
 
+.. admonition:: A note to Django veterans
+
+    The old tool ``bin/compile-messages.py`` has been moved to the command
+    ``django-admin.py compilemessages`` to provide consistency throughout
+    Django.
+
 .. admonition:: A note to translators
 
     If you've created a translation in a language Django doesn't yet support,
@@ -597,9 +609,9 @@ Notes:
               ('en', ugettext('English')),
           )
 
-      With this arrangement, ``make-messages.py`` will still find and mark
-      these strings for translation, but the translation won't happen at
-      runtime -- so you'll have to remember to wrap the languages in the *real*
+      With this arrangement, ``django-admin.py makemessages`` will still find
+      and mark these strings for translation, but the translation won't happen
+      at runtime -- so you'll have to remember to wrap the languages in the *real*
       ``ugettext()`` in any code that uses ``LANGUAGES`` at runtime.
 
     * The ``LocaleMiddleware`` can only select languages for which there is a
@@ -676,15 +688,16 @@ All message file repositories are structured the same way. They are:
       searched in that order for ``<language>/LC_MESSAGES/django.(po|mo)``
     * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``
 
-To create message files, you use the same ``make-messages.py`` tool as with the
-Django message files. You only need to be in the right place -- in the directory
-where either the ``conf/locale`` (in case of the source tree) or the ``locale/``
-(in case of app messages or project messages) directory are located. And you
-use the same ``compile-messages.py`` to produce the binary ``django.mo`` files
-that are used by ``gettext``.
+To create message files, you use the same ``django-admin.py makemessages``
+tool as with the Django message files. You only need to be in the right place
+-- in the directory where either the ``conf/locale`` (in case of the source
+tree) or the ``locale/`` (in case of app messages or project messages)
+directory are located. And you use the same ``django-admin.py compilemessages``
+to produce the binary ``django.mo`` files that are used by ``gettext``.
 
-You can also run ``compile-message.py --settings=path.to.settings`` to make
-the compiler process all the directories in your ``LOCALE_PATHS`` setting.
+You can also run ``django-admin.py compilemessages --settings=path.to.settings``
+to make the compiler process all the directories in your ``LOCALE_PATHS``
+setting.
 
 Application message files are a bit complicated to discover -- they need the
 ``LocaleMiddleware``. If you don't use the middleware, only the Django message
@@ -694,15 +707,15 @@ Finally, you should give some thought to the structure of your translation
 files. If your applications need to be delivered to other users and will
 be used in other projects, you might want to use app-specific translations.
 But using app-specific translations and project translations could produce
-weird problems with ``make-messages``: ``make-messages`` will traverse all
+weird problems with ``makemessages``: ``makemessages`` will traverse all
 directories below the current path and so might put message IDs into the
 project message file that are already in application message files.
 
 The easiest way out is to store applications that are not part of the project
 (and so carry their own translations) outside the project tree. That way,
-``make-messages`` on the project level will only translate strings that are
-connected to your explicit project and not strings that are distributed
-independently.
+``django-admin.py makemessages`` on the project level will only translate
+strings that are connected to your explicit project and not strings that are
+distributed independently.
 
 The ``set_language`` redirect view
 ==================================
@@ -857,14 +870,14 @@ Creating JavaScript translation catalogs
 ----------------------------------------
 
 You create and update the translation catalogs the same way as the other
-Django translation catalogs -- with the make-messages.py tool. The only
-difference is you need to provide a ``-d djangojs`` parameter, like this::
+Django translation catalogs -- with the django-admin.py makemessages tool. The
+only difference is you need to provide a ``-d djangojs`` parameter, like this::
 
-    make-messages.py -d djangojs -l de
+    django-admin.py makemessages -d djangojs -l de
 
 This would create or update the translation catalog for JavaScript for German.
-After updating translation catalogs, just run ``compile-messages.py`` the same
-way as you do with normal Django translation catalogs.
+After updating translation catalogs, just run ``django-admin.py compilemessages``
+the same way as you do with normal Django translation catalogs.
 
 Specialties of Django translation
 ==================================
diff --git a/docs/man/compile-messages.1 b/docs/man/compile-messages.1
deleted file mode 100644
index d26a94aca7..0000000000
--- a/docs/man/compile-messages.1
+++ /dev/null
@@ -1,40 +0,0 @@
-.TH "compile-messages.py" "1" "August 2007" "Django Project" ""
-.SH "NAME"
-compile-messages.py \- Internationalization utility for the Django
-web framework
-.SH "SYNOPSIS"
-.B compile-messages.py \fR[-l <locale>]
-
-.SH "DESCRIPTION"
-A Django-customised wrapper around gettext's \fBmsgfmt\fR command. Generates
-binary message catalogs (.mo files) from textual translation descriptions (.po
-files).
-.sp
-The script should be invoked after running
-.BI make-messages.py,
-in the same directory from which
-.BI make-messages.py
-was invoked.
-
-.SH "OPTIONS"
-.TP
-.I \-l <locale>
-Compile the message catalogs for a specific locale. If this option is omitted,
-all message catalogs are (re-)compiled.
-
-.SH "SEE ALSO"
-The man page for
-.BI msgfmt
-from the GNU gettext utilities, and the internationalization documentation
-for Django:
-.sp
-.I http://www.djangoproject.com/documentation/i18n/
-
-.SH "AUTHORS/CREDITS"
-Originally developed at World Online in Lawrence, Kansas, USA. Refer to the
-AUTHORS file in the Django distribution for contributors.
-
-.SH "LICENSE"
-New BSD license. For the full license text refer to the LICENSE file in the
-Django distribution.
-
diff --git a/docs/man/django-admin.1 b/docs/man/django-admin.1
index fec5053ccb..c482a3fc6e 100644
--- a/docs/man/django-admin.1
+++ b/docs/man/django-admin.1
@@ -1,4 +1,4 @@
-.TH "django-admin.py" "1" "June 2007" "Django Project" ""
+.TH "django-admin.py" "1" "March 2008" "Django Project" ""
 .SH "NAME"
 django\-admin.py \- Utility script for the Django web framework
 .SH "SYNOPSIS"
@@ -21,6 +21,12 @@ script found at the top level of each Django project directory.
 .BI "adminindex [" "appname ..." "]"
 Prints the admin\-index template snippet for the given app name(s).
 .TP
+.BI cleanup
+Cleans out old data from the database (only expired sessions at the moment).
+.TP
+.BI "compilemessages [" "\-\-locale=LOCALE" "]"
+Compiles .po files to .mo files for use with builtin gettext support.
+.TP
 .BI "createcachetable [" "tablename" "]"
 Creates the table needed to use the SQL cache backend
 .TP
@@ -43,6 +49,11 @@ Executes
 .B sqlall
 for the given app(s) in the current database.
 .TP
+.BI "makemessages [" "\-\-locale=LOCALE" "] [" "\-\-domain=DOMAIN" "] [" "\-\-all" "]"
+Runs over the entire source tree of the current directory and pulls out all
+strings marked for translation. It creates (or updates) a message file in the
+conf/locale (in the django tree) or locale (for project and application) directory.
+.TP
 .BI "reset [" "appname ..." "]"
 Executes
 .B sqlreset
@@ -136,7 +147,15 @@ Verbosity level: 0=minimal output, 1=normal output, 2=all output.
 .TP
 .I \-\-adminmedia=ADMIN_MEDIA_PATH
 Specifies the directory from which to serve admin media when using the development server.
-
+.TP
+.I \-l, \-\-locale=LOCALE
+The locale to process when using makemessages or compilemessages.
+.TP
+.I \-d, \-\-domain=DOMAIN
+The domain of the message files (default: "django") when using makemessages.
+.TP
+.I \-a, \-\-all
+Process all available locales when using makemessages.
 .SH "ENVIRONMENT"
 .TP
 .I DJANGO_SETTINGS_MODULE
diff --git a/docs/man/make-messages.1 b/docs/man/make-messages.1
deleted file mode 100644
index b8c83dcff5..0000000000
--- a/docs/man/make-messages.1
+++ /dev/null
@@ -1,62 +0,0 @@
-.TH "make-messages.py" "1" "August 2007" "Django Project" ""
-.SH "NAME"
-make-messages.py \- Internationalization utility for the Django
-web framework
-.SH "SYNOPSIS"
-.B make-messages.py\fR [\-a] [\-v] [\-l <locale>] [\-d <domain>]
-
-.SH "DESCRIPTION"
-This script creates or updates one or more message files for a Django app,
-a Django project or the Django framework itself.  It should be run from one
-of three places: the root directory of a Django app; the root directory
-of a Django project; or the root django directory (the one in your PYTHONPATH,
-not the root of a Subversion checkout).
-.sp
-The script will run over the source tree of an application, project or Django
-itself (depending on where it is invoked), pulling out all strings marked for
-translation and creating or updating a standard PO-format message file for the
-specified language. Refer to Django's internationalization documentation for
-details of where this file is created.
-.sp
-The \fI\-a\fR and \fI\-l\fR options are used to control whether message
-catalogs are created for all locales, or just a single one.
-
-.SH "OPTIONS"
-.TP
-.I \-a
-Run make-messages for all locales specified in the Django settings file. Cannot
-be used in conjuntion with \fI\-l\fR.
-.TP
-.I \-d <domain>
-Specifies the translation domain to use. Valid domains are \fIdjango\fR or
-\fIdjangojs\fR, depending on whether you wish to generate translation strings
-for the Python or JavaScript components of your app, your project or the
-framework itself.  The default domain is \fIdjango\fR.
-.TP
-.I \-l <locale>
-Extract messages for a particular locale.
-.TP
-.I \-v
-Run verbosely.
-
-.SH "ENVIRONMENT"
-.TP
-.I DJANGO_SETTINGS_MODULE
-This environment variable defines the settings module to be read.
-It should be in Python-import form, e.g. "myproject.settings".
-
-.SH "SEE ALSO"
-The Django internationalization documentation:
-.sp
-.I http://www.djangoproject.com/documentation/i18n/
-.sp
-The PO file format is documented in the GNU gettext documentation.
-
-.SH "AUTHORS/CREDITS"
-Originally developed at World Online in Lawrence, Kansas, USA. Refer to the
-AUTHORS file in the Django distribution for contributors.
-
-.SH "LICENSE"
-New BSD license. For the full license text refer to the LICENSE file in the
-Django distribution.
-
diff --git a/docs/newforms.txt b/docs/newforms.txt
index 296fc04c85..4240fe9985 100644
--- a/docs/newforms.txt
+++ b/docs/newforms.txt
@@ -1331,23 +1331,12 @@ given length.
     * Validates that non-empty file data has been bound to the form.
     * Error message keys: ``required``, ``invalid``, ``missing``, ``empty``
 
-An ``UploadedFile`` object has two attributes:
+To learn more about the ``UploadedFile`` object, see the `file uploads documentation`_.
 
-    ======================  ====================================================
-    Attribute               Description
-    ======================  ====================================================
-    ``filename``            The name of the file, provided by the uploading
-                            client.
-                            
-    ``content``             The array of bytes comprising the file content.
-    ======================  ====================================================
-
-The string representation of an ``UploadedFile`` is the same as the filename
-attribute.
-
-When you use a ``FileField`` on a form, you must also remember to
+When you use a ``FileField`` in a form, you must also remember to
 `bind the file data to the form`_.
 
+.. _file uploads documentation: ../upload_handling/
 .. _`bind the file data to the form`: `Binding uploaded files to a form`_
 
 ``FilePathField``
@@ -1412,7 +1401,7 @@ These control the range of values permitted in the field.
 
 Using an ImageField requires that the `Python Imaging Library`_ is installed.
 
-When you use a ``FileField`` on a form, you must also remember to
+When you use an ``ImageField`` in a form, you must also remember to
 `bind the file data to the form`_.
 
 .. _Python Imaging Library: http://www.pythonware.com/products/pil/
@@ -1817,15 +1806,21 @@ reuse certain sets of widget attributes over and over again. Rather than
 repeat these attribute definitions every time you need them, Django allows
 you to capture those definitions as a custom widget.
 
-For example, if you find that you are including a lot of comment fields on forms,
-you could capture the idea of a ``TextInput`` with a specific ``size`` attribute
-as a custom extension to the ``TextInput`` widget::
+For example, if you find that you are including a lot of comment fields on
+forms, you could capture the idea of a ``TextInput`` with a specific
+default ``size`` attribute as a custom extension to the ``TextInput`` widget::
 
     class CommentWidget(forms.TextInput):
         def __init__(self, *args, **kwargs):
-            kwargs.setdefault('attrs',{}).update({'size': '40'})
+            attrs = kwargs.setdefault('attrs',{})
+            if 'size' not in attrs:
+                attrs['size'] = 40
             super(CommentWidget, self).__init__(*args, **kwargs)
 
+We allow the ``size`` attribute to be overridden by the user, but, by default,
+this widget will behave as if ``attrs={'size': 40}`` was always passed into the
+constructor.
+
 Then you can use this widget in your forms::
 
     class CommentForm(forms.Form):
diff --git a/docs/pagination.txt b/docs/pagination.txt
index 486c92264b..bfdf8eea1c 100644
--- a/docs/pagination.txt
+++ b/docs/pagination.txt
@@ -59,6 +59,11 @@ page::
     ...
     InvalidPage
 
+Note that you can give ``Paginator`` a list/tuple or a Django ``QuerySet``. The
+only difference is in implementation; if you pass a ``QuerySet``, the
+``Paginator`` will call its ``count()`` method instead of using ``len()``,
+because the former is more efficient.
+
 ``Paginator`` objects
 =====================
 
@@ -77,6 +82,21 @@ Attributes
 
 ``page_range`` -- A 1-based range of page numbers, e.g., ``[1, 2, 3, 4]``.
 
+``InvalidPage`` exceptions
+==========================
+
+The ``page()`` method raises ``InvalidPage`` if the requested page is invalid
+(i.e., not an integer) or contains no objects. Generally, it's enough to trap
+the ``InvalidPage`` exception, but if you'd like more granularity, you can trap
+either of the following exceptions:
+
+``PageNotAnInteger`` -- Raised when ``page()`` is given a value that isn't an integer.
+
+``EmptyPage`` -- Raised when ``page()`` is given a valid value but no objects exist on that page.
+
+Both of the exceptions are subclasses of ``InvalidPage``, so you can handle
+them both with a simple ``except InvalidPage``.
+
 ``Page`` objects
 ================
 
@@ -116,13 +136,6 @@ Attributes
 
 ``paginator`` -- The associated ``Paginator`` object.
 
-``QuerySetPaginator`` objects
-=============================
-
-Use ``QuerySetPaginator`` instead of ``Paginator`` if you're paginating across
-a ``QuerySet`` from Django's database API. This is slightly more efficient, and
-there are no API differences between the two classes.
-
 The legacy ``ObjectPaginator`` class
 ====================================
 
diff --git a/docs/sessions.txt b/docs/sessions.txt
index 0c47f0deed..648832b85d 100644
--- a/docs/sessions.txt
+++ b/docs/sessions.txt
@@ -349,7 +349,7 @@ table. Django updates this row each time the session data changes. If the user
 logs out manually, Django deletes the row. But if the user does *not* log out,
 the row never gets deleted.
 
-Django provides a sample clean-up script in ``django/bin/daily_cleanup.py``.
+Django provides a sample clean-up script in ``django-admin.py cleanup``.
 That script deletes any session in the session table whose ``expire_date`` is
 in the past -- but your application may have different requirements.
 
diff --git a/docs/settings.txt b/docs/settings.txt
index a68d2ff92f..d7715714d3 100644
--- a/docs/settings.txt
+++ b/docs/settings.txt
@@ -279,7 +279,7 @@ Default: ``''`` (Empty string)
 
 The database backend to use. The build-in database backends are
 ``'postgresql_psycopg2'``, ``'postgresql'``, ``'mysql'``, ``'mysql_old'``,
-``'sqlite3'``, ``'oracle'``, and ``'oracle'``.
+``'sqlite3'``, and ``'oracle'``.
 
 In the Django development version, you can use a database backend that doesn't
 ship with Django by setting ``DATABASE_ENGINE`` to a fully-qualified path (i.e.
@@ -682,10 +682,10 @@ settings file::
         ('en', gettext('English')),
     )
 
-With this arrangement, ``make-messages.py`` will still find and mark these
-strings for translation, but the translation won't happen at runtime -- so
-you'll have to remember to wrap the languages in the *real* ``gettext()`` in
-any code that uses ``LANGUAGES`` at runtime.
+With this arrangement, ``django-admin.py makemessages`` will still find and
+mark these strings for translation, but the translation won't happen at
+runtime -- so you'll have to remember to wrap the languages in the *real*
+``gettext()`` in any code that uses ``LANGUAGES`` at runtime.
 
 LOCALE_PATHS
 ------------
diff --git a/docs/testing.txt b/docs/testing.txt
index 0b18545efb..bb091bfd6b 100644
--- a/docs/testing.txt
+++ b/docs/testing.txt
@@ -89,7 +89,7 @@ read Python's official documentation for the details.
     For example, this function has a docstring that describes what it does::
 
         def add_two(num):
-            "Adds 2 to the given number and returns the result."
+            "Return the result of adding two to the provided number."
             return num + 2
 
     Because tests often make great documentation, putting tests directly in
@@ -600,8 +600,6 @@ Specifically, a ``Response`` object has the following attributes:
                      ``context`` will be a list of ``Context``
                      objects, in the order in which they were rendered.
 
-    ``headers``      The HTTP headers of the response. This is a dictionary.
-
     ``request``      The request data that stimulated the response.
 
     ``status_code``  The HTTP status of the response, as an integer. See
@@ -619,6 +617,10 @@ Specifically, a ``Response`` object has the following attributes:
                      which they were rendered.
     ===============  ==========================================================
 
+You can also use dictionary syntax on the response object to query the value
+of any settings in the HTTP headers. For example, you could determine the
+content type of a response using ``response['Content-Type']``.
+
 .. _RFC2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
 .. _template inheritance: ../templates/#template-inheritance
 
diff --git a/docs/tutorial01.txt b/docs/tutorial01.txt
index 04863cc7fd..9e765b1a9b 100644
--- a/docs/tutorial01.txt
+++ b/docs/tutorial01.txt
@@ -146,7 +146,7 @@ database's connection parameters:
     * ``DATABASE_ENGINE`` -- Either 'postgresql_psycopg2', 'mysql' or 'sqlite3'.
       Other backends are `also available`_.
     * ``DATABASE_NAME`` -- The name of your database, or the full (absolute)
-      path to the database file if you're using SQLite.
+      path to the database file if you're using SQLite. 
     * ``DATABASE_USER`` -- Your database username (not used for SQLite).
     * ``DATABASE_PASSWORD`` -- Your database password (not used for SQLite).
     * ``DATABASE_HOST`` -- The host your database is on. Leave this as an
@@ -161,6 +161,9 @@ database's connection parameters:
     this point. Do that with "``CREATE DATABASE database_name;``" within your
     database's interactive prompt.
 
+    If you're using SQLite, you don't need to create anything beforehand - the
+    database file will be created automatically when it is needed.
+
 While you're editing ``settings.py``, take note of the ``INSTALLED_APPS``
 setting towards the bottom of the file. That variable holds the names of all
 Django applications that are activated in this Django instance. Apps can be
diff --git a/docs/upload_handling.txt b/docs/upload_handling.txt
index 34cd085ac9..3b88ce4e3d 100644
--- a/docs/upload_handling.txt
+++ b/docs/upload_handling.txt
@@ -22,7 +22,7 @@ Consider a simple form containing a ``FileField``::
     class UploadFileForm(forms.Form):
         title = forms.CharField(max_length=50)
         file  = forms.FileField()
-        
+
 A view handling this form will receive the file data in ``request.FILES``, which
 is a dictionary containing a key for each ``FileField`` (or ``ImageField``, or
 other ``FileField`` subclass) in the form. So the data from the above form would
@@ -64,34 +64,34 @@ methods to access the uploaded content:
     ``UploadedFile.read()``
         Read the entire uploaded data from the file. Be careful with this
         method: if the uploaded file is huge it can overwhelm your system if you
-        try to read it into memory. You'll probably want to use ``chunk()``
+        try to read it into memory. You'll probably want to use ``chunks()``
         instead; see below.
-        
+
     ``UploadedFile.multiple_chunks()``
         Returns ``True`` if the uploaded file is big enough to require
         reading in multiple chunks. By default this will be any file
         larger than 2.5 megabytes, but that's configurable; see below.
-    
+
     ``UploadedFile.chunk()``
         A generator returning chunks of the file. If ``multiple_chunks()`` is
         ``True``, you should use this method in a loop instead of ``read()``.
-        
+
         In practice, it's often easiest simply to use ``chunks()`` all the time;
         see the example below.
-    
+
     ``UploadedFile.file_name``
         The name of the uploaded file (e.g. ``my_file.txt``).
-        
+
     ``UploadedFile.file_size``
         The size, in bytes, of the uploaded file.
-        
+
 There are a few other methods and attributes available on ``UploadedFile``
 objects; see `UploadedFile objects`_ for a complete reference.
 
 Putting it all together, here's a common way you might handle an uploaded file::
-    
+
     def handle_uploaded_file(f):
-        destination = open('some/file/name.txt', 'wb')
+        destination = open('some/file/name.txt', 'wb+')
         for chunk in f.chunks():
             destination.write(chunk)
 
@@ -126,27 +126,27 @@ Three `settings`_ control Django's file upload behavior:
         The maximum size, in bytes, for files that will be uploaded
         into memory. Files larger than ``FILE_UPLOAD_MAX_MEMORY_SIZE``
         will be streamed to disk.
-        
+
         Defaults to 2.5 megabytes.
-        
+
     ``FILE_UPLOAD_TEMP_DIR``
         The directory where uploaded files larger than ``FILE_UPLOAD_TEMP_DIR``
         will be stored.
-        
+
         Defaults to your system's standard temporary directory (i.e. ``/tmp`` on
         most Unix-like systems).
-        
+
     ``FILE_UPLOAD_HANDLERS``
         The actual handlers for uploaded files. Changing this setting
         allows complete customization -- even replacement -- of
         Django's upload process. See `upload handlers`_, below,
         for details.
-        
+
         Defaults to::
-        
+
             ("django.core.files.uploadhandler.MemoryFileUploadHandler",
              "django.core.files.uploadhandler.TemporaryFileUploadHandler",)
-            
+
         Which means "try to upload to memory first, then fall back to temporary
         files."
 
@@ -161,35 +161,39 @@ All ``UploadedFile`` objects define the following methods/attributes:
         Returns a byte string of length ``num_bytes``, or the complete file if
         ``num_bytes`` is ``None``.
 
-    ``UploadedFile.chunk(self, chunk_size=None)``
+    ``UploadedFile.chunks(self, chunk_size=None)``
         A generator yielding small chunks from the file. If ``chunk_size`` isn't
-        given, chunks will be 64 kb.
+        given, chunks will be 64 KB.
 
     ``UploadedFile.multiple_chunks(self, chunk_size=None)``
         Returns ``True`` if you can expect more than one chunk when calling
-        ``UploadedFile.chunk(self, chunk_size)``.
+        ``UploadedFile.chunks(self, chunk_size)``.
 
     ``UploadedFile.file_size``
         The size, in bytes, of the uploaded file.
-    
+
     ``UploadedFile.file_name``
         The name of the uploaded file as provided by the user.
-    
+
     ``UploadedFile.content_type``
         The content-type header uploaded with the file (e.g. ``text/plain`` or
         ``application/pdf``). Like any data supplied by the user, you shouldn't
         trust that the uploaded file is actually this type. You'll still need to
         validate that the file contains the content that the content-type header
         claims -- "trust but verify."
-    
+
     ``UploadedFile.charset``
         For ``text/*`` content-types, the character set (i.e. ``utf8``) supplied
         by the browser. Again, "trust but verify" is the best policy here.
 
+    ``UploadedFile.__iter__()``
+        Iterates over the lines in the file.
+
     ``UploadedFile.temporary_file_path()``
         Only files uploaded onto disk will have this method; it returns the full
         path to the temporary uploaded file.
 
+
 Upload Handlers
 ===============