[per-object-permissions] Merged to revision 3582

git-svn-id: http://code.djangoproject.com/svn/django/branches/per-object-permissions@3583 bcc190cf-cafb-0310-a4f2-bffc1f526a37

17 files changed, 497 insertions, 58 deletions

diff --git a/docs/add_ons.txt b/docs/add_ons.txt
index 90c98b7176..6507f3b139 100644
--- a/docs/add_ons.txt
+++ b/docs/add_ons.txt
@@ -2,12 +2,15 @@
 The "contrib" add-ons
 =====================
 
-Django aims to follow Python's "batteries included" philosophy. It ships with a
-variety of extra, optional tools that solve common Web-development problems.
+Django aims to follow Python's `"batteries included" philosophy`_. It ships
+with a variety of extra, optional tools that solve common Web-development
+problems.
 
 This code lives in ``django/contrib`` in the Django distribution. Here's a
 rundown of the packages in ``contrib``:
 
+.. _"batteries included" philosophy: http://docs.python.org/tut/node12.html#batteries-included
+
 admin
 =====
 
diff --git a/docs/api_stability.txt b/docs/api_stability.txt
index 475a209400..a9d6904735 100644
--- a/docs/api_stability.txt
+++ b/docs/api_stability.txt
@@ -6,6 +6,9 @@ Although Django has not reached a 1.0 release, the bulk of Django's public APIs
 stable as of the 0.95 release. This document explains which APIs will and will not
 change before the 1.0 release.
 
+What "stable" means
+===================
+
 In this context, stable means:
 
    - All the public APIs -- everything documented in the linked documents, and
@@ -24,6 +27,9 @@ In this context, stable means:
    - We'll only break backwards compatibility of these APIs if a bug or
      security hole makes it completely unavoidable.
 
+Stable APIs
+===========
+
 These APIs are stable:
 
    - `Caching`_.
@@ -114,4 +120,4 @@ change:
 .. _url dispatch: http://www.djangoproject.com/documentation/url_dispatch/
 .. _forms and validation: http://www.djangoproject.com/documentation/forms/
 .. _serialization: http://www.djangoproject.com/documentation/serialization/
-.. _authentication: http://www.djangoproject.com/documentation/authentication/
\ No newline at end of file
+.. _authentication: http://www.djangoproject.com/documentation/authentication/
diff --git a/docs/db-api.txt b/docs/db-api.txt
index ce6bb0ab3b..bd178dbd7d 100644
--- a/docs/db-api.txt
+++ b/docs/db-api.txt
@@ -578,6 +578,9 @@ related ``Person`` *and* the related ``City``::
     p = b.author         # Hits the database.
     c = p.hometown       # Hits the database.
 
+Note that ``select_related()`` does not follow foreign keys that have
+``null=True``.
+
 ``extra(select=None, where=None, params=None, tables=None)``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -715,12 +718,12 @@ The ``DoesNotExist`` exception inherits from
 A convenience method for creating an object and saving it all in one step.  Thus::
 
     p = Person.objects.create(first_name="Bruce", last_name="Springsteen")
-    
+
 and::
 
     p = Person(first_name="Bruce", last_name="Springsteen")
     p.save()
-    
+
 are equivalent.
 
 ``get_or_create(**kwargs)``
@@ -1468,11 +1471,12 @@ the ``ForeignKey`` ``Manager`` has these additional methods:
           b.entry_set.remove(e) # Disassociates Entry e from Blog b.
 
       In order to prevent database inconsistency, this method only exists on
-      ``ForeignKey``s where ``null=True``. If the related field can't be set to
-      ``None`` (``NULL``), then an object can't be removed from a relation
-      without being added to another. In the above example, removing ``e`` from
-      ``b.entry_set()`` is equivalent to doing ``e.blog = None``, and because
-      the ``blog`` ``ForeignKey`` doesn't have ``null=True``, this is invalid.
+      ``ForeignKey`` objects where ``null=True``. If the related field can't be
+      set to ``None`` (``NULL``), then an object can't be removed from a
+      relation without being added to another. In the above example, removing
+      ``e`` from ``b.entry_set()`` is equivalent to doing ``e.blog = None``,
+      and because the ``blog`` ``ForeignKey`` doesn't have ``null=True``, this
+      is invalid.
 
     * ``clear()``: Removes all objects from the related object set.
 
@@ -1556,13 +1560,13 @@ Queries over related objects
 ----------------------------
 
 Queries involving related objects follow the same rules as queries involving
-normal value fields. When specifying the the value for a query to match, you 
-may use either an object instance itself, or the primary key value for the 
+normal value fields. When specifying the the value for a query to match, you
+may use either an object instance itself, or the primary key value for the
 object.
 
 For example, if you have a Blog object ``b`` with ``id=5``, the following
 three queries would be identical::
-     
+
     Entry.objects.filter(blog=b) # Query using object instance
     Entry.objects.filter(blog=b.id) # Query using id from instance
     Entry.objects.filter(blog=5) # Query using id directly
diff --git a/docs/documentation.txt b/docs/documentation.txt
new file mode 100644
index 0000000000..bacfb176b1
--- /dev/null
+++ b/docs/documentation.txt
@@ -0,0 +1,148 @@
+====================================
+How to read the Django documentation
+====================================
+
+We've put a lot of effort into making Django's documentation useful, easy to
+read and as complete as possible. Here are a few tips on how to make the best
+of it, along with some style guidelines.
+
+(Yes, this is documentation about documentation. Rest assured we have no plans
+to write a document about how to read the document about documentation.)
+
+How documentation is updated
+============================
+
+Just as the Django code base is developed and improved on a daily basis, our
+documentation is consistently improving. We improve documentation for several
+reasons:
+
+    * To make content fixes, such as grammar/typo corrections.
+    * To add information and/or examples to existing sections that need to be
+      expanded.
+    * To document Django features that aren't yet documented. (The list of
+      such features is shrinking but exists nonetheless.)
+    * To add documentation for new features as new features get added, or as
+      Django APIs or behaviors change.
+
+Django's documentation is kept in the same source control system as its code.
+It lives in the `django/trunk/docs`_ directory of our Subversion repository.
+Each document is a separate text file that covers a narrowly focused topic,
+such as the "generic views" framework or how to construct a database model.
+
+.. _django/trunk/docs: http://code.djangoproject.com/browser/django/trunk/docs
+
+Where to get it
+===============
+
+You can read Django documentation in several ways. They are, in order of
+preference:
+
+On the Web
+----------
+
+The most recent version of the Django documentation lives at
+http://www.djangoproject.com/documentation/ . These HTML pages are generated
+automatically from the text files in source control every 15 minutes. That
+means they reflect the "latest and greatest" in Django -- they include the very
+latest corrections and additions, and they discuss the latest Django features,
+which may only be available to users of the Django development version. (See
+"Differences between versions" below.)
+
+A key advantage of the Web-based documentation is the comment section at the
+bottom of each document. This is an area for anybody to submit changes,
+corrections and suggestions about the given document. The Django developers
+frequently monitor the comments there and use them to improve the documentation
+for everybody.
+
+We encourage you to help improve the docs: it's easy! Note, however, that
+comments should explicitly relate to the documentation, rather than asking
+broad tech-support questions. If you need help with your particular Django
+setup, try the `django-users mailing list`_ instead of posting a comment to the
+documentation.
+
+.. _django-users mailing list: http://groups.google.com/group/django-users
+
+In plain text
+-------------
+
+For offline reading, or just for convenience, you can read the Django
+documentation in plain text.
+
+If you're using an official release of Django, note that the zipped package
+(tarball) of the code includes a ``docs/`` directory, which contains all the
+documentation for that release.
+
+If you're using the development version of Django (aka the Subversion "trunk"),
+note that the ``docs/`` directory contains all of the documentation. You can
+``svn update`` it, just as you ``svn update`` the Python code, in order to get
+the latest changes.
+
+You can check out the latest Django documentation from Subversion using this
+shell command::
+
+    svn co http://code.djangoproject.com/svn/django/trunk/docs/ django_docs
+
+One low-tech way of taking advantage of the text documentation is by using the
+Unix ``grep`` utility to search for a phrase in all of the documentation. For
+example, this will show you each mention of the phrase "edit_inline" in any
+Django document::
+
+    grep edit_inline /path/to/django/docs/*.txt
+
+Formatting
+~~~~~~~~~~
+
+The text documentation is written in ReST (ReStructured Text) format. That
+means it's easy to read but is also formatted in a way that makes it easy to
+convert into other formats, such as HTML. If you're interested, the script that
+converts the ReST text docs into djangoproject.com's HTML lives at
+`djangoproject.com/django_website/apps/docs/parts/build_documentation.py`_ in
+the Django Subversion repository.
+
+.. _djangoproject.com/django_website/apps/docs/parts/build_documentation.py: http://code.djangoproject.com/browser/djangoproject.com/django_website/apps/docs/parts/build_documentation.py
+
+Differences between versions
+============================
+
+As previously mentioned, the text documentation in our Subversion repository
+contains the "latest and greatest" changes and additions. These changes often
+include documentation of new features added in the Django development version
+-- the Subversion ("trunk") version of Django. For that reason, it's worth
+pointing out our policy on keeping straight the documentation for various
+versions of the framework.
+
+We follow this policy:
+
+    * The primary documentation on djangoproject.com is an HTML version of the
+      latest docs in Subversion. These docs always correspond to the latest
+      official Django release, plus whatever features we've added/changed in
+      the framework *since* the latest release.
+
+    * As we add features to Django's development version, we try to update the
+      documentation in the same Subversion commit transaction.
+
+    * To distinguish feature changes/additions in the docs, we use the phrase
+      **New in Django development version**. In practice, this means that the
+      current documentation on djangoproject.com can be used by users of either
+      the latest release *or* the development version.
+
+    * Documentation for a particular Django release is frozen once the version
+      has been released officially. It remains a snapshot of the docs as of the
+      moment of the release. We will make exceptions to this rule in
+      the case of retroactive security updates or other such retroactive
+      changes. Once documentation is frozen, we add a note to the top of each
+      frozen document that says "These docs are frozen for Django version XXX"
+      and links to the current version of that document.
+
+    * Once a document is frozen for a Django release, we remove comments from
+      that page, in favor of having comments on the latest version of that
+      document. This is for the sake of maintainability and usability, so that
+      users have one, and only one, place to leave comments on a particular
+      document. We realize that some people may be stuck on a previous version
+      of Django, but we believe the usability problems with multiple versions
+      of a document the outweigh the benefits.
+
+    * The `main documentation Web page`_ includes links to documentation for
+      all previous versions.
+
+.. _main documentation Web page: http://www.djangoproject.com/documentation/
diff --git a/docs/faq.txt b/docs/faq.txt
index b9fc282000..3cd7090583 100644
--- a/docs/faq.txt
+++ b/docs/faq.txt
@@ -251,6 +251,16 @@ information than the docs that come with the latest Django release.
 
 .. _stored in revision control: http://code.djangoproject.com/browser/django/trunk/docs
 
+Where can I find Django developers for hire?
+--------------------------------------------
+
+Consult our `developers for hire page`_ for a list of Django developers who
+would be happy to help you.
+
+You might also be interested in posting a job to http://www.gypsyjobs.com/ .
+
+.. _developers for hire page: http://code.djangoproject.com/wiki/DevelopersForHire
+
 Installation questions
 ======================
 
@@ -610,13 +620,10 @@ like to make should be possible by editing the stylesheet. We've got a
 How do I create users without having to edit password hashes?
 -------------------------------------------------------------
 
-We don't recommend you create users via the admin interface, because at the
-moment it requires you to edit password hashes manually. (Passwords are hashed
-using one-way hash algorithms for security; there's currently no Web interface
-for changing passwords by entering the actual password rather than the hash.)
+If you'd like to use the admin site to create users, upgrade to the Django
+development version, where this problem was fixed on Aug. 4, 2006.
 
-To create a user, you'll have to use the Python API. See `creating users`_ for
-full info.
+You can also use the Python API. See `creating users`_ for full info.
 
 .. _creating users: http://www.djangoproject.com/documentation/authentication/#creating-users
 
diff --git a/docs/forms.txt b/docs/forms.txt
index 2fbe373744..67408f3c5d 100644
--- a/docs/forms.txt
+++ b/docs/forms.txt
@@ -404,6 +404,43 @@ Here's a simple function that might drive the above form::
             errors = new_data = {}
         form = forms.FormWrapper(manipulator, new_data, errors)
         return render_to_response('contact_form.html', {'form': form})
+        
+``FileField`` and ``ImageField`` special cases
+==============================================
+
+Dealing with ``FileField`` and ``ImageField`` objects is a little more
+complicated.
+
+First, you'll need to make sure that your ``<form>`` element correctly defines
+the ``enctype`` as ``"multipart/form-data"``, in order to upload files::
+
+  <form enctype="multipart/form-data" method="post" action="/foo/">
+
+Next, you'll need to treat the field in the template slightly differently. A
+``FileField`` or ``ImageField`` is represented by *two* HTML form elements.
+
+For example, given this field in a model::
+
+   photo = model.ImageField('/path/to/upload/location')
+
+You'd need to display two formfields in the template::
+
+   <p><label for="id_photo">Photo:</label> {{ form.photo }}{{ form.photo_file }}</p>
+
+The first bit (``{{ form.photo }}``) displays the currently-selected file,
+while the second (``{{ form.photo_file }}``) actually contains the file upload
+form field. Thus, at the validation layer you need to check the ``photo_file``
+key.
+
+Finally, in your view, make sure to access ``request.FILES``, rather than
+``request.POST``, for the uploaded files. This is necessary because
+``request.POST`` does not contain file-upload data.
+
+For example, following the ``new_data`` convention, you might do something like
+this::
+
+   new_data = request.POST.copy()
+   new_data.update(request.FILES)
 
 Validators
 ==========
diff --git a/docs/generic_views.txt b/docs/generic_views.txt
index aab878467f..fdab97de27 100644
--- a/docs/generic_views.txt
+++ b/docs/generic_views.txt
@@ -127,7 +127,7 @@ If the given URL is ``None``, Django will return an ``HttpResponseGone`` (410).
 This example redirects from ``/foo/<id>/`` to ``/bar/<id>/``::
 
     urlpatterns = patterns('django.views.generic.simple',
-        ('^foo/(?p<id>\d+)/$', 'redirect_to', {'url': '/bar/%(id)s/'}),
+        ('^foo/(?P<id>\d+)/$', 'redirect_to', {'url': '/bar/%(id)s/'}),
     )
 
 This example returns a 410 HTTP error for requests to ``/bar/``::
diff --git a/docs/install.txt b/docs/install.txt
index 800c49b596..fb1bd73122 100644
--- a/docs/install.txt
+++ b/docs/install.txt
@@ -77,9 +77,9 @@ It's easy either way.
 Installing the official version
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-1. Download Django-0.91.tar.gz from our `download page`_.
-2. ``tar xzvf Django-0.91.tar.gz``
-3. ``cd Django-0.91``
+1. Download Django-0.95.tar.gz from our `download page`_.
+2. ``tar xzvf Django-0.95.tar.gz``
+3. ``cd Django-0.95``
 4. ``sudo python setup.py install``
 
 Note that the last command will automatically download and install setuptools_
@@ -89,14 +89,6 @@ connection.
 This will install Django in your Python installation's ``site-packages``
 directory.
 
-.. note::
-
-    Due to recent backwards-incompatible changes, it is strongly recommended
-    that you use the development version (below) for any new applications or
-    if you are just starting to work with Django. The 0.91 release is a
-    dead-end branch that is primarily of use for supporting legacy Django
-    applications.
-
 .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
 
 Installing the development version
diff --git a/docs/model-api.txt b/docs/model-api.txt
index c369508c65..502ceaf7ff 100644
--- a/docs/model-api.txt
+++ b/docs/model-api.txt
@@ -223,6 +223,13 @@ steps:
        the absolute URL to your image in a template with ``{{
        object.get_mug_shot_url }}``.
 
+For example, say your ``MEDIA_ROOT`` is set to ``'/home/media'``, and
+``upload_to`` is set to ``'photos/%Y/%m/%d'``. The ``'%Y/%m/%d'`` part of
+``upload_to`` is strftime formatting; ``'%Y'`` is the four-digit year,
+``'%m'`` is the two-digit month and ``'%d'`` is the two-digit day. If you
+upload a file on Jan. 15, 2007, it will be saved in the directory
+``/home/media/photos/2007/01/15``.
+
 .. _`strftime formatting`: http://docs.python.org/lib/module-time.html#l2h-1941
 
 ``FilePathField``
diff --git a/docs/release_notes_0.95.txt b/docs/release_notes_0.95.txt
new file mode 100644
index 0000000000..e5b89e5a7a
--- /dev/null
+++ b/docs/release_notes_0.95.txt
@@ -0,0 +1,126 @@
+=================================
+Django version 0.95 release notes
+=================================
+
+
+Welcome to the Django 0.95 release.
+
+This represents a significant advance in Django development since the 0.91
+release in January 2006. The details of every change in this release would be
+too extensive to list in full, but a summary is presented below.
+
+Suitability and API stability
+=============================
+
+This release is intended to provide a stable reference point for developers
+wanting to work on production-level applications that use Django.
+
+However, it's not the 1.0 release, and we'll be introducing further changes
+before 1.0. For a clear look at which areas of the framework will change (and
+which ones will *not* change) before 1.0, see the api-stability.txt file, which
+lives in the docs/ directory of the distribution.
+
+You may have a need to use some of the features that are marked as
+"subject to API change" in that document, but that's OK with us as long as it's
+OK with you, and as long as you understand APIs may change in the future.
+
+Fortunately, most of Django's core APIs won't be changing before version 1.0.
+There likely won't be as big of a change between 0.95 and 1.0 versions as there
+was between 0.91 and 0.95.
+
+Changes and new features
+========================
+
+The major changes in this release (for developers currently using the 0.91
+release) are a result of merging the 'magic-removal' branch of development.
+This branch removed a number of constraints in the way Django code had to be
+written that were a consequence of decisions made in the early days of Django,
+prior to its open-source release. It's now possible to write more natural,
+Pythonic code that works as expected, and there's less "black magic" happening
+behind the scenes.
+
+Aside from that, another main theme of this release is a dramatic increase in
+usability. We've made countless improvements in error messages, documentation,
+etc., to improve developers' quality of life.
+
+The new features and changes introduced in 0.95 include:
+
+    * Django now uses a more consistent and natural filtering interface for
+      retrieving objects from the database.
+
+    * User-defined models, functions and constants now appear in the module
+      namespace they were defined in. (Previously everything was magically
+      transferred to the django.models.* namespace.)
+
+    * Some optional applications, such as the FlatPage, Sites and Redirects
+      apps, have been decoupled and moved into django.contrib. If you don't
+      want to use these applications, you no longer have to install their
+      database tables.
+
+    * Django now has support for managing database transactions.
+
+    * We've added the ability to write custom authentication and authorization
+      backends for authenticating users against alternate systems, such as
+      LDAP.
+
+    * We've made it easier to add custom table-level functions to models,
+      through a new "Manager" API.
+
+    * It's now possible to use Django without a database. This simply means
+      that the framework no longer requires you to have a working database set
+      up just to serve dynamic pages. In other words, you can just use
+      URLconfs/views on their own. Previously, the framework required that a
+      database be configured, regardless of whether you actually used it.
+
+    * It's now more explicit and natural to override save() and delete()
+      methods on models, rather than needing to hook into the pre_save() and
+      post_save() method hooks.
+
+    * Individual pieces of the framework now can be configured without
+      requiring the setting of an environment variable. This permits use of,
+      for example, the Django templating system inside other applications.
+
+    * More and more parts of the framework have been internationalized, as
+      we've expanded internationalization (i18n) support. The Django
+      codebase, including code and templates, has now been translated, at least
+      in part, into 31 languages. From Arabic to Chinese to Hungarian to Welsh,
+      it is now possible to use Django's admin site in your native language.
+
+The number of changes required to port from 0.91-compatible code to the 0.95
+code base are significant in some cases. However, they are, for the most part,
+reasonably routine and only need to be done once. A list of the necessary
+changes is described in the `Removing The Magic`_ wiki page. There is also an
+easy checklist_ for reference when undertaking the porting operation.
+
+.. _Removing The Magic: http://code.djangoproject.com/wiki/RemovingTheMagic
+.. _checklist: http://code.djangoproject.com/wiki/MagicRemovalCheatSheet1
+
+Problem reports and getting help
+================================
+
+Need help resolving a problem with Django? The documentation in the
+distribution is also available online_ at the `Django website`_. The FAQ_
+document is especially recommended, as it contains a number of issues that
+come up time and again.
+
+For more personalized help, the `django-users`_ mailing list is a very active
+list, with more than 2,000 subscribers who can help you solve any sort of
+Django problem. We recommend you search the archives first, though, because
+many common questions appear with some regularity, and any particular problem
+may already have been answered.
+
+Finally, for those who prefer the more immediate feedback offered by IRC,
+there's a #django channel or irc.freenode.net that is regularly populated by
+Django users and developers from around the world. Friendly people are usually
+available at any hour of the day -- to help, or just to chat.
+
+.. _online: http://www.djangoproject.com/documentation/
+.. _Django website: http://www.djangoproject.com/
+.. _FAQ: http://www.djangoproject.com/documentation/faq/
+.. _django-users: http://groups.google.com/group/django-users
+
+Thanks for using Django!
+
+The Django Team
+July 2006
+
diff --git a/docs/request_response.txt b/docs/request_response.txt
index 7480a6d3bb..1f3b9d5804 100644
--- a/docs/request_response.txt
+++ b/docs/request_response.txt
@@ -149,7 +149,7 @@ Methods
    Returns the ``path``, plus an appended query string, if applicable.
 
    Example: ``"/music/bands/the_beatles/?print=true"``
-    
+
 ``is_secure()``
    Returns ``True`` if the request is secure; that is, if it was made with
    HTTPS.
@@ -380,10 +380,14 @@ Methods
 
     .. _`cookie Morsel`: http://www.python.org/doc/current/lib/morsel-objects.html
 
-``delete_cookie(key)``
+``delete_cookie(key, path='/', domain=None)``
     Deletes the cookie with the given key. Fails silently if the key doesn't
     exist.
 
+    The ``path`` and ``domain`` arguments are new in the Django development version.
+    Due to the way cookies work, ``path`` and ``domain`` should be the same
+    values you used in ``set_cookie()`` -- otherwise the cookie may not be deleted.
+
 ``content``
     Returns the content as a Python string, encoding it from a Unicode object
     if necessary. Note this is a property, not a method, so use ``r.content``
diff --git a/docs/sessions.txt b/docs/sessions.txt
index c473d0a3db..d39f42c3bf 100644
--- a/docs/sessions.txt
+++ b/docs/sessions.txt
@@ -245,6 +245,17 @@ Default: ``'sessionid'``
 
 The name of the cookie to use for sessions. This can be whatever you want.
 
+SESSION_COOKIE_SECURE
+---------------------
+
+**New in Django development version**
+
+Default: ``False``
+
+Whether to use a secure cookie for the session cookie. If this is set to
+``True``, the cookie will be marked as "secure," which means browsers may
+ensure that the cookie is only sent under an HTTPS connection.
+
 SESSION_EXPIRE_AT_BROWSER_CLOSE
 -------------------------------
 
diff --git a/docs/settings.txt b/docs/settings.txt
index 099196e56e..67e0498e1a 100644
--- a/docs/settings.txt
+++ b/docs/settings.txt
@@ -647,6 +647,18 @@ Default: ``'sessionid'``
 The name of the cookie to use for sessions. This can be whatever you want.
 See the `session docs`_.
 
+SESSION_COOKIE_SECURE
+---------------------
+
+**New in Django development version**
+
+Default: ``False``
+
+Whether to use a secure cookie for the session cookie. If this is set to
+``True``, the cookie will be marked as "secure," which means browsers may
+ensure that the cookie is only sent under an HTTPS connection.
+See the `session docs`_.
+
 SESSION_EXPIRE_AT_BROWSER_CLOSE
 -------------------------------
 
diff --git a/docs/templates.txt b/docs/templates.txt
index 6117bf7b84..49d30018fe 100644
--- a/docs/templates.txt
+++ b/docs/templates.txt
@@ -363,10 +363,15 @@ extends
 
 Signal that this template extends a parent template.
 
-This tag may be used in two ways: ``{% extends "base.html" %}`` (with quotes)
-uses the literal value "base.html" as the name of the parent template to
-extend, or ``{% extends variable %}`` uses the value of ``variable`` as the
-name of the parent template to extend.
+This tag can be used in two ways: 
+
+   * ``{% extends "base.html" %}`` (with quotes) uses the literal value
+     ``"base.html"`` as the name of the parent template to extend.
+
+   * ``{% extends variable %}`` uses the value of ``variable``. If the variable
+     evaluates to a string, Django will use that string as the name of the
+     parent template. If the variable evaluates to a ``Template`` object,
+     Django will use that object as the parent template.
 
 See `Template inheritance`_ for more information.
 
@@ -493,6 +498,11 @@ If you need to combine ``and`` and ``or`` to do advanced logic, just use nested
         {% endif %}
     {% endif %}
 
+Multiple uses of the same logical operator are fine, as long as you use the
+same operator. For example, this is valid::
+
+    {% if athlete_list or coach_list or parent_list or teacher_list %}
+
 ifchanged
 ~~~~~~~~~
 
diff --git a/docs/templates_python.txt b/docs/templates_python.txt
index 8a62ebebad..95ccfb3eab 100644
--- a/docs/templates_python.txt
+++ b/docs/templates_python.txt
@@ -198,21 +198,6 @@ some things to keep in mind:
 How invalid variables are handled
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In Django 0.91, if a variable doesn't exist, the template system fails
-silently. The variable is replaced with an empty string::
-
-    >>> t = Template("My name is {{ my_name }}.")
-    >>> c = Context({"foo": "bar"})
-    >>> t.render(c)
-    "My name is ."
-
-This applies to any level of lookup::
-
-    >>> t = Template("My name is {{ person.fname }} {{ person.lname }}.")
-    >>> c = Context({"person": {"fname": "Stan"}})
-    >>> t.render(c)
-    "My name is Stan ."
-
 If a variable doesn't exist, the template system inserts the value of the
 ``TEMPLATE_STRING_IF_INVALID`` setting, which is set to ``''`` (the empty
 string) by default.
diff --git a/docs/tutorial01.txt b/docs/tutorial01.txt
index 62db8ab842..1113b603da 100644
--- a/docs/tutorial01.txt
+++ b/docs/tutorial01.txt
@@ -81,7 +81,7 @@ the following output on the command line::
     Validating models...
     0 errors found.
 
-    Django version 0.95 (post-magic-removal), using settings 'mysite.settings'
+    Django version 0.95, using settings 'mysite.settings'
     Development server is running at http://127.0.0.1:8000/
     Quit the server with CONTROL-C (Unix) or CTRL-BREAK (Windows).
 
diff --git a/docs/url_dispatch.txt b/docs/url_dispatch.txt
index 498a906d5e..00a7af027a 100644
--- a/docs/url_dispatch.txt
+++ b/docs/url_dispatch.txt
@@ -263,12 +263,12 @@ Here's the example URLconf from the `Django overview`_::
     from django.conf.urls.defaults import *
 
     urlpatterns = patterns('',
-        (r'^articles/(\d{4})/$', 'myproject.news.views.year_archive'),
-        (r'^articles/(\d{4})/(\d{2})/$', 'myproject.news.views.month_archive'),
-        (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'myproject.news.views.article_detail'),
+        (r'^articles/(\d{4})/$', 'mysite.news.views.year_archive'),
+        (r'^articles/(\d{4})/(\d{2})/$', 'mysite.news.views.month_archive'),
+        (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'mysite.news.views.article_detail'),
     )
 
-In this example, each view has a common prefix -- ``'myproject.news.views'``.
+In this example, each view has a common prefix -- ``'mysite.news.views'``.
 Instead of typing that out for each entry in ``urlpatterns``, you can use the
 first argument to the ``patterns()`` function to specify a prefix to apply to
 each view function.
@@ -277,7 +277,7 @@ With this in mind, the above example can be written more concisely as::
 
     from django.conf.urls.defaults import *
 
-    urlpatterns = patterns('myproject.news.views',
+    urlpatterns = patterns('mysite.news.views',
         (r'^articles/(\d{4})/$', 'year_archive'),
         (r'^articles/(\d{4})/(\d{2})/$', 'month_archive'),
         (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'article_detail'),
@@ -389,3 +389,90 @@ to pass metadata and options to views.
 
 .. _generic views: http://www.djangoproject.com/documentation/generic_views/
 .. _syndication framework: http://www.djangoproject.com/documentation/syndication/
+
+Passing extra options to ``include()``
+--------------------------------------
+
+**New in the Django development version.**
+
+Similarly, you can pass extra options to ``include()``. When you pass extra
+options to ``include()``, *each* line in the included URLconf will be passed
+the extra options.
+
+For example, these two URLconf sets are functionally identical:
+
+Set one::
+
+    # main.py
+    urlpatterns = patterns('',
+        (r'^blog/', include('inner'), {'blogid': 3}),
+    )
+
+    # inner.py
+    urlpatterns = patterns('',
+        (r'^archive/$', 'mysite.views.archive'),
+        (r'^about/$', 'mysite.views.about'),
+    )
+
+Set two::
+
+    # main.py
+    urlpatterns = patterns('',
+        (r'^blog/', include('inner')),
+    )
+
+    # inner.py
+    urlpatterns = patterns('',
+        (r'^archive/$', 'mysite.views.archive', {'blogid': 3}),
+        (r'^about/$', 'mysite.views.about', {'blogid': 3}),
+    )
+
+Note that extra options will *always* be passed to *every* line in the included
+URLconf, regardless of whether the line's view actually accepts those options
+as valid. For this reason, this technique is only useful if you're certain that
+every view in the the included URLconf accepts the extra options you're passing.
+
+Passing callable objects instead of strings
+===========================================
+
+**New in the Django development version.**
+
+Some developers find it more natural to pass the actual Python function object
+rather than a string containing the path to its module. This alternative is
+supported -- you can pass any callable object as the view.
+
+For example, given this URLconf in "string" notation::
+
+    urlpatterns = patterns('',
+        (r'^archive/$', 'mysite.views.archive'),
+        (r'^about/$', 'mysite.views.about'),
+        (r'^contact/$', 'mysite.views.contact'),
+    )
+
+You can accomplish the same thing by passing objects rather than strings. Just
+be sure to import the objects::
+
+    from mysite.views import archive, about, contact
+
+    urlpatterns = patterns('',
+        (r'^archive/$', archive),
+        (r'^about/$', about),
+        (r'^contact/$', contact),
+    )
+
+The following example is functionally identical. It's just a bit more compact
+because it imports the module that contains the views, rather than importing
+each view individually::
+
+    from mysite import views
+
+    urlpatterns = patterns('',
+        (r'^archive/$', views.archive),
+        (r'^about/$', views.about),
+        (r'^contact/$', views.contact),
+    )
+
+The style you use is up to you.
+
+Note that if you use this technique -- passing objects rather than strings --
+the view prefix (as explained in "The view prefix" above) will have no effect.