Fixed #7830 -- Removed all of the remaining, deprecated, non-oldforms features:

 * Support for representing files as strings was removed. Use `django.core.files.base.ContentFile` instead.
 * Support for representing uploaded files as dictionaries was removed. Use `django.core.files.uploadedfile.SimpleUploadedFile` instead.
 * The `filename`, `file_name`, `file_size`, and `chuck` properties of `UploadedFile` were removed. Use the `name`, `name`, `size`, and `chunks` properties instead, respectively.
 * The `get_FIELD_filename`, `get_FIELD_url`, `get_FIELD_size`, and `save_FIELD_file` methods for Models with `FileField` fields were removed. Instead, use the `path`, `url`, and `size` attributes and `save` method on the field itself, respectively.
 * The `get_FIELD_width` and `get_FIELD_height` methods for Models with `ImageField` fields were removed. Use the `width` and `height` attributes on the field itself instead.
 * The dispatcher `connect`, `disconnect`, `send`, and `sendExact` functions were removed. Use the signal object's own `connect`, `disconnect`, `send`, and `send` methods instead, respectively.
 * The `form_for_model` and `form_for_instance` functions were removed. Use a `ModelForm` subclass instead.
 * Support for importing `django.newforms` was removed. Use `django.forms` instead.
 * Support for importing `django.utils.images` was removed. Use `django.core.files.images` instead.
 * Support for the `follow` argument in the `create_object` and `update_object` generic views was removed. Use the `django.forms` package and the new `form_class` argument instead.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@8291 bcc190cf-cafb-0310-a4f2-bffc1f526a37

5 files changed, 32 insertions, 496 deletions

diff --git a/docs/custom_model_fields.txt b/docs/custom_model_fields.txt
index a45e876fc6..5dec22f6e3 100644
--- a/docs/custom_model_fields.txt
+++ b/docs/custom_model_fields.txt
@@ -483,8 +483,7 @@ accepted lookup types to ``exact`` and ``in``::
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Returns the default form field to use when this field is displayed
-in a model. This method is called by the `helper functions`_
-``form_for_model()`` and ``form_for_instance()``.
+in a model.
 
 All of the ``kwargs`` dictionary is passed directly to the form field's
 ``__init__()`` method. Normally, all you need to do is set up a good default
diff --git a/docs/db-api.txt b/docs/db-api.txt
index bbbe06ea98..b014a70b1e 100644
--- a/docs/db-api.txt
+++ b/docs/db-api.txt
@@ -1418,7 +1418,7 @@ SQL equivalent::
 
 You can also use a queryset to dynamically evaluate the list of values
 instead of providing a list of literal values. The queryset must be
-reduced to a list of individual values using the ``values()`` method, 
+reduced to a list of individual values using the ``values()`` method,
 and then converted into a query using the ``query`` attribute::
 
     Entry.objects.filter(blog__in=Blog.objects.filter(name__contains='Cheddar').values('pk').query)
@@ -2106,7 +2106,7 @@ One-to-one relationships
 ------------------------
 
 One-to-one relationships are very similar to many-to-one relationships.
-If you define a OneToOneField on your model, instances of that model will have 
+If you define a OneToOneField on your model, instances of that model will have
 access to the related object via a simple attribute of the model.
 
 For example::
@@ -2128,9 +2128,9 @@ represents a single object, rather than a collection of objects::
 If no object has been assigned to this relationship, Django will raise
 a ``DoesNotExist`` exception.
 
-Instances can be assigned to the reverse relationship in the same way as 
+Instances can be assigned to the reverse relationship in the same way as
 you would assign the forward relationship::
-    
+
     e.entrydetail = ed
 
 Many-to-many relationships
@@ -2313,37 +2313,6 @@ For a full example, see the `lookup API sample model`_.
 
 .. _lookup API sample model: ../models/lookup/
 
-get_FOO_filename()
-------------------
-
-**Deprecated in Django development version**; use ``object.FOO.name`` instead.
-See `managing files`_ for details.
-
-get_FOO_url()
--------------
-
-**Deprecated in Django development version**; use ``object.FOO.url`` instead.
-See `managing files`_ for details.
-
-get_FOO_size()
---------------
-
-**Deprecated in Django development version**; use ``object.FOO.size`` instead.
-See `managing files`_ for details.
-
-save_FOO_file(filename, raw_contents)
--------------------------------------
-
-**Deprecated in Django development version**; use ``object.FOO.save()`` instead.
-See `managing files`_ for details.
-
-get_FOO_height() and get_FOO_width()
-------------------------------------
-
-**Deprecated in Django development version**; use ``object.FOO.width`` and
-``object.FOO.height`` instead. See `managing files`_ for details.
-
-.. _`managing files`: ../files/
 
 Shortcuts
 =========
diff --git a/docs/form_for_model.txt b/docs/form_for_model.txt
deleted file mode 100644
index a394cd2c54..0000000000
--- a/docs/form_for_model.txt
+++ /dev/null
@@ -1,425 +0,0 @@
-Generating forms for models
-===========================
-
-.. admonition:: Note
-
-    The APIs described in this document have been deprecated. If you're
-    developing new code, use `ModelForms`_ instead.
-
-.. _ModelForms: ../modelforms/
-
-If you're building a database-driven app, chances are you'll have forms that
-map closely to Django models. For instance, you might have a ``BlogComment``
-model, and you want to create a form that lets people submit comments. In this
-case, it would be redundant to define the field types in your form, because
-you've already defined the fields in your model.
-
-For this reason, Django provides a few helper functions that let you create a
-``Form`` class from a Django model.
-
-``form_for_model()``
---------------------
-
-The method ``django.forms.form_for_model()`` creates a form based on the
-definition of a specific model. Pass it the model class, and it will return a
-``Form`` class that contains a form field for each model field.
-
-For example::
-
-    >>> from django.forms import form_for_model
-
-    # Create the form class.
-    >>> ArticleForm = form_for_model(Article)
-
-    # Create an empty form instance.
-    >>> f = ArticleForm()
-
-It bears repeating that ``form_for_model()`` takes the model *class*, not a
-model instance, and it returns a ``Form`` *class*, not a ``Form`` instance.
-
-Field types
-~~~~~~~~~~~
-
-The generated ``Form`` class will have a form field for every model field. Each
-model field has a corresponding default form field. For example, a
-``CharField`` on a model is represented as a ``CharField`` on a form. A
-model ``ManyToManyField`` is represented as a ``MultipleChoiceField``. Here is
-the full list of conversions:
-
-    ===============================  ========================================
-    Model field                      Form field
-    ===============================  ========================================
-    ``AutoField``                    Not represented in the form
-    ``BooleanField``                 ``BooleanField``
-    ``CharField``                    ``CharField`` with ``max_length`` set to
-                                     the model field's ``max_length``
-    ``CommaSeparatedIntegerField``   ``CharField``
-    ``DateField``                    ``DateField``
-    ``DateTimeField``                ``DateTimeField``
-    ``DecimalField``                 ``DecimalField``
-    ``EmailField``                   ``EmailField``
-    ``FileField``                    ``FileField``
-    ``FilePathField``                ``CharField``
-    ``FloatField``                   ``FloatField``
-    ``ForeignKey``                   ``ModelChoiceField`` (see below)
-    ``ImageField``                   ``ImageField``
-    ``IntegerField``                 ``IntegerField``
-    ``IPAddressField``               ``IPAddressField``
-    ``ManyToManyField``              ``ModelMultipleChoiceField`` (see
-                                     below)
-    ``NullBooleanField``             ``CharField``
-    ``PhoneNumberField``             ``USPhoneNumberField``
-                                     (from ``django.contrib.localflavor.us``)
-    ``PositiveIntegerField``         ``IntegerField``
-    ``PositiveSmallIntegerField``    ``IntegerField``
-    ``SlugField``                    ``CharField``
-    ``SmallIntegerField``            ``IntegerField``
-    ``TextField``                    ``CharField`` with ``widget=Textarea``
-    ``TimeField``                    ``TimeField``
-    ``URLField``                     ``URLField`` with ``verify_exists`` set
-                                     to the model field's ``verify_exists``
-    ``USStateField``                 ``CharField`` with
-                                     ``widget=USStateSelect``
-                                     (``USStateSelect`` is from
-                                     ``django.contrib.localflavor.us``)
-    ``XMLField``                     ``CharField`` with ``widget=Textarea``
-    ===============================  ========================================
-
-
-.. note::
-    The ``FloatField`` form field and ``DecimalField`` model and form fields
-    are new in the development version.
-
-As you might expect, the ``ForeignKey`` and ``ManyToManyField`` model field
-types are special cases:
-
-    * ``ForeignKey`` is represented by ``django.forms.ModelChoiceField``,
-      which is a ``ChoiceField`` whose choices are a model ``QuerySet``.
-
-    * ``ManyToManyField`` is represented by
-      ``django.forms.ModelMultipleChoiceField``, which is a
-      ``MultipleChoiceField`` whose choices are a model ``QuerySet``.
-
-In addition, each generated form field has attributes set as follows:
-
-    * If the model field has ``blank=True``, then ``required`` is set to
-      ``False`` on the form field. Otherwise, ``required=True``.
-
-    * The form field's ``label`` is set to the ``verbose_name`` of the model
-      field, with the first character capitalized.
-
-    * The form field's ``help_text`` is set to the ``help_text`` of the model
-      field.
-
-    * If the model field has ``choices`` set, then the form field's ``widget``
-      will be set to ``Select``, with choices coming from the model field's
-      ``choices``. The choices will normally include the blank choice which is
-      selected by default. If the field is required, this forces the user to
-      make a selection. The blank choice will not be included if the model
-      field has ``blank=False`` and an explicit ``default`` value (the
-      ``default`` value will be initially selected instead).
-
-Finally, note that you can override the form field used for a given model
-field. See "Overriding the default field types" below.
-
-A full example
-~~~~~~~~~~~~~~
-
-Consider this set of models::
-
-    from django.db import models
-
-    TITLE_CHOICES = (
-        ('MR', 'Mr.'),
-        ('MRS', 'Mrs.'),
-        ('MS', 'Ms.'),
-    )
-
-    class Author(models.Model):
-        name = models.CharField(max_length=100)
-        title = models.CharField(max_length=3, choices=TITLE_CHOICES)
-        birth_date = models.DateField(blank=True, null=True)
-
-        def __unicode__(self):
-            return self.name
-
-    class Book(models.Model):
-        name = models.CharField(max_length=100)
-        authors = models.ManyToManyField(Author)
-
-With these models, a call to ``form_for_model(Author)`` would return a ``Form``
-class equivalent to this::
-
-    class AuthorForm(forms.Form):
-        name = forms.CharField(max_length=100)
-        title = forms.CharField(max_length=3,
-                    widget=forms.Select(choices=TITLE_CHOICES))
-        birth_date = forms.DateField(required=False)
-
-A call to ``form_for_model(Book)`` would return a ``Form`` class equivalent to
-this::
-
-    class BookForm(forms.Form):
-        name = forms.CharField(max_length=100)
-        authors = forms.ModelMultipleChoiceField(queryset=Author.objects.all())
-
-The ``save()`` method
-~~~~~~~~~~~~~~~~~~~~~
-
-Every form produced by ``form_for_model()`` also has a ``save()`` method. This
-method creates and saves a database object from the data bound to the form. For
-example::
-
-    # Create a form instance from POST data.
-    >>> f = ArticleForm(request.POST)
-
-    # Save a new Article object from the form's data.
-    >>> new_article = f.save()
-
-Note that ``save()`` will raise a ``ValueError`` if the data in the form
-doesn't validate -- i.e., ``if form.errors``.
-
-This ``save()`` method accepts an optional ``commit`` keyword argument, which
-accepts either ``True`` or ``False``. If you call ``save()`` with
-``commit=False``, then it will return an object that hasn't yet been saved to
-the database. In this case, it's up to you to call ``save()`` on the resulting
-model instance. This is useful if you want to do custom processing on the
-object before saving it. ``commit`` is ``True`` by default.
-
-Another side effect of using ``commit=False`` is seen when your model has
-a many-to-many relation with another model. If your model has a many-to-many
-relation and you specify ``commit=False`` when you save a form, Django cannot
-immediately save the form data for the many-to-many relation. This is because
-it isn't possible to save many-to-many data for an instance until the instance
-exists in the database.
-
-To work around this problem, every time you save a form using ``commit=False``,
-Django adds a ``save_m2m()`` method to the form created by ``form_for_model``.
-After you've manually saved the instance produced by the form, you can invoke
-``save_m2m()`` to save the many-to-many form data. For example::
-
-    # Create a form instance with POST data.
-    >>> f = AuthorForm(request.POST)
-
-    # Create, but don't save the new author instance.
-    >>> new_author = f.save(commit=False)
-
-    # Modify the author in some way.
-    >>> new_author.some_field = 'some_value'
-
-    # Save the new instance.
-    >>> new_author.save()
-
-    # Now, save the many-to-many data for the form.
-    >>> f.save_m2m()
-
-Calling ``save_m2m()`` is only required if you use ``save(commit=False)``.
-When you use a simple ``save()`` on a form, all data -- including
-many-to-many data -- is saved without the need for any additional method calls.
-For example::
-
-    # Create a form instance with POST data.
-    >>> f = AuthorForm(request.POST)
-
-    # Create and save the new author instance. There's no need to do anything else.
-    >>> new_author = f.save()
-
-Using an alternate base class
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you want to add custom methods to the form generated by
-``form_for_model()``, write a class that extends ``django.forms.BaseForm``
-and contains your custom methods. Then, use the ``form`` argument to
-``form_for_model()`` to tell it to use your custom form as its base class.
-For example::
-
-    # Create the new base class.
-    >>> class MyBase(BaseForm):
-    ...     def my_method(self):
-    ...         # Do whatever the method does
-
-    # Create the form class with a different base class.
-    >>> ArticleForm = form_for_model(Article, form=MyBase)
-
-    # Instantiate the form.
-    >>> f = ArticleForm()
-
-    # Use the base class method.
-    >>> f.my_method()
-
-Using a subset of fields on the form
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**New in Django development version**
-
-In some cases, you may not want all the model fields to appear on the generated
-form. There are two ways of telling ``form_for_model()`` to use only a subset
-of the model fields:
-
-    1. Set ``editable=False`` on the model field. As a result, *any* form
-       created from the model via ``form_for_model()`` will not include that
-       field.
-
-    2. Use the ``fields`` argument to ``form_for_model()``. This argument, if
-       given, should be a list of field names to include in the form.
-
-       For example, if you want a form for the ``Author`` model (defined above)
-       that includes only the ``name`` and ``title`` fields, you would specify
-       ``fields`` like this::
-
-           PartialArticleForm = form_for_model(Author, fields=('name', 'title'))
-
-.. note::
-
-    If you specify ``fields`` when creating a form with ``form_for_model()``,
-    then the fields that are *not* specified will not be set by the form's
-    ``save()`` method. Django will prevent any attempt to save an incomplete
-    model, so if the model does not allow the missing fields to be empty, and
-    does not provide a default value for the missing fields, any attempt to
-    ``save()`` a ``form_for_model`` with missing fields will fail. To avoid
-    this failure, you must use ``save(commit=False)`` and manually set any
-    extra required fields::
-
-        instance = form.save(commit=False)
-        instance.required_field = 'new value'
-        instance.save()
-
-    See the `section on saving forms`_ for more details on using
-    ``save(commit=False)``.
-
-.. _section on saving forms: `The save() method`_
-
-Overriding the default field types
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The default field types, as described in the "Field types" table above, are
-sensible defaults; if you have a ``DateField`` in your model, chances are you'd
-want that to be represented as a ``DateField`` in your form. But
-``form_for_model()`` gives you the flexibility of changing the form field type
-for a given model field. You do this by specifying a **formfield callback**.
-
-A formfield callback is a function that, when provided with a model field,
-returns a form field instance. When constructing a form, ``form_for_model()``
-asks the formfield callback to provide form field types.
-
-By default, ``form_for_model()`` calls the ``formfield()`` method on the model
-field::
-
-    def default_callback(field, **kwargs):
-        return field.formfield(**kwargs)
-
-The ``kwargs`` are any keyword arguments that might be passed to the form
-field, such as ``required=True`` or ``label='Foo'``.
-
-For example, if you wanted to use ``MyDateFormField`` for any ``DateField``
-field on the model, you could define the callback::
-
-    >>> def my_callback(field, **kwargs):
-    ...     if isinstance(field, models.DateField):
-    ...         return MyDateFormField(**kwargs)
-    ...     else:
-    ...         return field.formfield(**kwargs)
-
-    >>> ArticleForm = form_for_model(Article, formfield_callback=my_callback)
-
-Note that your callback needs to handle *all* possible model field types, not
-just the ones that you want to behave differently to the default. That's why
-this example has an ``else`` clause that implements the default behavior.
-
-.. warning::
-    The field that is passed into the ``formfield_callback`` function in
-    ``form_for_model()`` and ``form_for_instance`` is the field instance from
-    your model's class. You **must not** alter that object at all; treat it
-    as read-only!
-
-    If you make any alterations to that object, it will affect any future
-    users of the model class, because you will have changed the field object
-    used to construct the class. This is almost certainly what you don't want
-    to have happen.
-
-Finding the model associated with a form
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The model class that was used to construct the form is available
-using the ``_model`` property of the generated form::
-
-    >>> ArticleForm = form_for_model(Article)
-    >>> ArticleForm._model
-    <class 'myapp.models.Article'>
-
-``form_for_instance()``
------------------------
-
-``form_for_instance()`` is like ``form_for_model()``, but it takes a model
-instance instead of a model class::
-
-    # Create an Author.
-    >>> a = Author(name='Joe Smith', title='MR', birth_date=None)
-    >>> a.save()
-
-    # Create a form for this particular Author.
-    >>> AuthorForm = form_for_instance(a)
-
-    # Instantiate the form.
-    >>> f = AuthorForm()
-
-When a form created by ``form_for_instance()`` is created, the initial data
-values for the form fields are drawn from the instance. However, this data is
-not bound to the form. You will need to bind data to the form before the form
-can be saved.
-
-Unlike ``form_for_model()``, a choice field in form created by
-``form_for_instance()`` will not include the blank choice if the respective
-model field has ``blank=False``. The initial choice is drawn from the instance.
-
-When you call ``save()`` on a form created by ``form_for_instance()``,
-the database instance will be updated. As in ``form_for_model()``, ``save()``
-will raise ``ValueError`` if the data doesn't validate.
-
-``form_for_instance()`` has ``form``, ``fields`` and ``formfield_callback``
-arguments that behave the same way as they do for ``form_for_model()``.
-
-Let's modify the earlier `contact form`_ view example a little bit. Suppose we
-have a ``Message`` model that holds each contact submission. Something like::
-
-    class Message(models.Model):
-        subject = models.CharField(max_length=100)
-        message = models.TextField()
-        sender = models.EmailField()
-        cc_myself = models.BooleanField(required=False)
-
-You could use this model to create a form (using ``form_for_model()``). You
-could also use existing ``Message`` instances to create a form for editing
-messages. The `simple example view`_ can be changed slightly to accept the ``id`` value
-of an existing ``Message`` and present it for editing::
-
-    def contact_edit(request, msg_id):
-        # Create the form from the message id.
-        message = get_object_or_404(Message, id=msg_id)
-        ContactForm = form_for_instance(message)
-
-        if request.method == 'POST':
-            form = ContactForm(request.POST)
-            if form.is_valid():
-                form.save()
-                return HttpResponseRedirect('/url/on_success/')
-        else:
-            form = ContactForm()
-        return render_to_response('contact.html', {'form': form})
-
-Aside from how we create the ``ContactForm`` class here, the main point to
-note is that the form display in the ``GET`` branch of the function
-will use the values from the ``message`` instance as initial values for the
-form field.
-
-.. _contact form: ../forms/#simple-view-example
-.. _`simple example view`: ../forms/#simple-view-example
-
-When should you use ``form_for_model()`` and ``form_for_instance()``?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The ``form_for_model()`` and ``form_for_instance()`` functions are meant to be
-shortcuts for the common case. If you want to create a form whose fields map to
-more than one model, or a form that contains fields that *aren't* on a model,
-you shouldn't use these shortcuts. Creating a ``Form`` class the "long" way
-isn't that difficult, after all.
diff --git a/docs/forms.txt b/docs/forms.txt
index 547323d103..b43c7c01f8 100644
--- a/docs/forms.txt
+++ b/docs/forms.txt
@@ -1828,11 +1828,7 @@ Generating forms for models
 The prefered way of generating forms that work with models is explained in the
 `ModelForms documentation`_.
 
-Looking for the ``form_for_model`` and ``form_for_instance`` documentation?
-They've been deprecated, but you can still `view the documentation`_.
-
 .. _ModelForms documentation: ../modelforms/
-.. _view the documentation: ../form_for_model/
 
 Media
 =====
diff --git a/docs/model-api.txt b/docs/model-api.txt
index da5584e2bc..8001b1cee9 100644
--- a/docs/model-api.txt
+++ b/docs/model-api.txt
@@ -308,12 +308,11 @@ For example, say your ``MEDIA_ROOT`` is set to ``'/home/media'``, and
 upload a file on Jan. 15, 2007, it will be saved in the directory
 ``/home/media/photos/2007/01/15``.
 
-If you want to retrieve the upload file's on-disk filename, or a URL that
-refers to that file, or the file's size, you can use the
-``get_FOO_filename()``, ``get_FOO_url()`` and ``get_FOO_size()`` methods.
-They are all documented here__.
+Information about the uploaded ``File`` object, such as its on-disk filename,
+its size, or its URL, is available via attributes on the object itself. See the
+`managing files`__ documentation for more information about ``File`` objects.
 
-__ ../db-api/#get-foo-filename
+__ ../files/
 
 Note that whenever you deal with uploaded files, you should pay close attention
 to where you're uploading them and what type of files they are, to avoid
@@ -392,19 +391,17 @@ image. Has two extra optional arguments, ``height_field`` and
 ``width_field``, which, if set, will be auto-populated with the height and
 width of the image each time a model instance is saved.
 
-In addition to the special ``get_FOO_*`` methods that are available for
-``FileField``, an ``ImageField`` also has ``get_FOO_height()`` and
-``get_FOO_width()`` methods. These are documented elsewhere_.
+In addition to the `standard attributes and methods`_ that are available for
+``FileField``, an ``ImageField`` also has ``width`` and ``height`` attributes.
 
 Requires the `Python Imaging Library`_.
 
-.. _Python Imaging Library: http://www.pythonware.com/products/pil/
-.. _elsewhere: ../db-api/#get-foo-height-and-get-foo-width
-
 **New in development version:**  By default, ``ImageField`` instances are
 created as ``varchar(100)`` columns in your database. As with other fields, you
 can change the maximum length using the ``max_length`` argument.
 
+.. _standard attributes and methods: ../files/#file-attributes-and-methods
+.. _Python Imaging Library: http://www.pythonware.com/products/pil/
 
 ``IntegerField``
 ~~~~~~~~~~~~~~~~
@@ -605,10 +602,10 @@ be used for organizational purposes::
         ('unknown', 'Unknown'),
     )
 
-The first element in each tuple is the name to apply to the group. The 
+The first element in each tuple is the name to apply to the group. The
 second element is an iterable of 2-tuples, with each 2-tuple containing
-a value and a human-readable name for an option. Grouped options may be 
-combined with ungrouped options within a single list (such as the 
+a value and a human-readable name for an option. Grouped options may be
+combined with ungrouped options within a single list (such as the
 `unknown` option in this example).
 
 For each model field that has ``choices`` set, Django will add a method to
@@ -981,12 +978,12 @@ the relationship should work. All are optional:
 Extra fields on many-to-many relationships
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-**New in Django development version** 
+**New in Django development version**
 
 When you're only dealing with simple many-to-many relationships such as
 mixing and matching pizzas and toppings, a standard ``ManyToManyField``
 is all you need. However, sometimes you may need to associate data with the
-relationship between two models. 
+relationship between two models.
 
 For example, consider the case of an application tracking the musical groups
 which musicians belong to. There is a many-to-many relationship between a person
@@ -1021,7 +1018,7 @@ something like this::
         date_joined = models.DateField()
         invite_reason = models.CharField(max_length=64)
 
-When you set up the intermediary model, you explicitly specify foreign 
+When you set up the intermediary model, you explicitly specify foreign
 keys to the models that are involved in the ManyToMany relation. This
 explicit declaration defines how the two models are related.
 
@@ -1030,8 +1027,8 @@ There are a few restrictions on the intermediate model:
     * Your intermediate model must contain one - and *only* one - foreign key
       on the target model (this would be ``Person`` in our example). If you
       have more than one foreign key, a validation error will be raised.
-  
-    * Your intermediate model must contain one - and *only* one - foreign key 
+
+    * Your intermediate model must contain one - and *only* one - foreign key
       on the source model (this would be ``Group`` in our example). If you
       have more than one foreign key, a validation error will be raised.
 
@@ -1040,22 +1037,22 @@ There are a few restrictions on the intermediate model:
       case, two foreign keys to the same model are permitted, but they
       will be treated as the two (different) sides of the many-to-many
       relation.
-    
+
     * When defining a many-to-many relationship from a model to
       itself, using an intermediary model, you *must* use
       ``symmetrical=False`` (see the documentation for
       ``ManyToManyField`` above).
 
-Now that you have set up your ``ManyToManyField`` to use your intermediary 
+Now that you have set up your ``ManyToManyField`` to use your intermediary
 model (Membership, in this case), you're ready to start creating some
 many-to-many relationships. You do this by creating instances of the
 intermediate model::
-    
+
     >>> ringo = Person.objects.create(name="Ringo Starr")
     >>> paul = Person.objects.create(name="Paul McCartney")
     >>> beatles = Group.objects.create(name="The Beatles")
     >>> m1 = Membership(person=ringo, group=beatles,
-    ...     date_joined=date(1962, 8, 16), 
+    ...     date_joined=date(1962, 8, 16),
     ...     invite_reason= "Needed a new drummer.")
     >>> m1.save()
     >>> beatles.members.all()
@@ -1063,7 +1060,7 @@ intermediate model::
     >>> ringo.group_set.all()
     [<Group: The Beatles>]
     >>> m2 = Membership.objects.create(person=paul, group=beatles,
-    ...     date_joined=date(1960, 8, 1), 
+    ...     date_joined=date(1960, 8, 1),
     ...     invite_reason= "Wanted to form a band.")
     >>> beatles.members.all()
     [<Person: Ringo Starr>, <Person: Paul McCartney>]
@@ -1077,7 +1074,7 @@ or assignment (i.e., ``beatles.members = [...]``) to create relationships::
     >>> beatles.members.create(name="George Harrison")
     # AND NEITHER WILL THIS
     >>> beatles.members = [john, paul, ringo, george]
-    
+
 Why? You can't just create a relationship between a Person and a Group - you
 need to specify all the detail for the relationship required by the
 Membership table. The simple ``add``, ``create`` and assignment calls
@@ -1094,15 +1091,15 @@ for an instance::
     >>> beatles.members.clear()
 
 Once you have established the many-to-many relationships by creating instances
-of your intermediate model, you can issue queries. Just as with normal 
-many-to-many relationships, you can query using the attributes of the 
+of your intermediate model, you can issue queries. Just as with normal
+many-to-many relationships, you can query using the attributes of the
 many-to-many-related model::
 
     # Find all the groups with a member whose name starts with 'Paul'
     >>> Groups.objects.filter(person__name__startswith='Paul')
     [<Group: The Beatles>]
 
-As you are using an intermediate table, you can also query on the attributes 
+As you are using an intermediate table, you can also query on the attributes
 of the intermediate model::
 
     # Find all the members of the Beatles that joined after 1 Jan 1961
@@ -1110,7 +1107,7 @@ of the intermediate model::
     ...     group__name='The Beatles',
     ...     membership__date_joined__gt=date(1961,1,1))
     [<Person: Ringo Starr]
-    
+
 One-to-one relationships
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1555,7 +1552,7 @@ attributes by giving it a ``use_for_related_fields`` property::
 
     class MyManager(models.Manager)::
         use_for_related_fields = True
-        
+
         ...
 
 Model methods