Fixed doc references to `django.db.models.query.QuerySet` and converted some tabs that were introduced in r16699 to spaces.

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

docs/intro/tutorial03.txt

@@ -321,9 +321,9 @@ will get you started for now.
 A shortcut: get_object_or_404()
 -------------------------------
 
-It's a very common idiom to use :meth:`~django.db.models.QuerySet.get` and raise
-:exc:`~django.http.Http404` if the object doesn't exist. Django provides a
-shortcut. Here's the ``detail()`` view, rewritten::
+It's a very common idiom to use :meth:`~django.db.models.query.QuerySet.get`
+and raise :exc:`~django.http.Http404` if the object doesn't exist. Django
+provides a shortcut. Here's the ``detail()`` view, rewritten::
 
     from django.shortcuts import render_to_response, get_object_or_404
     # ...
@@ -333,8 +333,8 @@ shortcut. Here's the ``detail()`` view, rewritten::
 
 The :func:`~django.shortcuts.get_object_or_404` function takes a Django model
 as its first argument and an arbitrary number of keyword arguments, which it
-passes to the module's :meth:`~django.db.models.QuerySet.get` function. It
-raises :exc:`~django.http.Http404` if the object doesn't exist.
+passes to the module's :meth:`~django.db.models.query.QuerySet.get` function.
+It raises :exc:`~django.http.Http404` if the object doesn't exist.
 
 .. admonition:: Philosophy
 
@@ -349,9 +349,9 @@ raises :exc:`~django.http.Http404` if the object doesn't exist.
 
 There's also a :func:`~django.shortcuts.get_list_or_404` function, which works
 just as :func:`~django.shortcuts.get_object_or_404` -- except using
-:meth:`~django.db.models.QuerySet.filter` instead of
-:meth:`~django.db.models.QuerySet.get`. It raises :exc:`~django.http.Http404` if
-the list is empty.
+:meth:`~django.db.models.query.QuerySet.filter` instead of
+:meth:`~django.db.models.query.QuerySet.get`. It raises
+:exc:`~django.http.Http404` if the list is empty.
 
 Write a 404 (page not found) view
 =================================

docs/ref/class-based-views.txt

@@ -388,7 +388,7 @@ MultipleObjectTemplateResponseMixin
     that operate upon a list of object instances. Requires that the view it is
     mixed with provides ``self.object_list``, the list of object instances that
     the view is operating on. ``self.object_list`` may be, but is not required
-    to be, a :class:`~django.db.models.Queryset`.
+    to be, a :class:`~django.db.models.query.QuerySet`.
 
     **Extends**
 
@@ -814,7 +814,7 @@ BaseDateListView
         Returns the list of dates of type ``date_type`` for which
         ``queryset`` contains entries. For example, ``get_date_list(qs,
         'year')`` will return the list of years for which ``qs`` has entries.
-        See :meth:`~django.db.models.QuerySet.dates()` for the
+        See :meth:`~django.db.models.query.QuerySet.dates()` for the
         ways that the ``date_type`` argument can be used.
 
 

docs/ref/contrib/admin/actions.txt

@@ -23,8 +23,9 @@ models. For example, here's the user module from Django's built-in
 .. warning::
 
     The "delete selected objects" action uses :meth:`QuerySet.delete()
-    <django.db.models.QuerySet.delete>` for efficiency reasons, which has an
-    important caveat: your model's ``delete()`` method will not be called.
+    <django.db.models.query.QuerySet.delete>` for efficiency reasons, which
+    has an important caveat: your model's ``delete()`` method will not be
+    called.
 
     If you wish to override this behavior, simply write a custom action which
     accomplishes deletion in your preferred manner -- for example, by calling
@@ -74,8 +75,8 @@ three arguments:
 
     * The current :class:`ModelAdmin`
     * An :class:`~django.http.HttpRequest` representing the current request,
-    * A :class:`~django.db.models.QuerySet` containing the set of objects
-      selected by the user.
+    * A :class:`~django.db.models.query.QuerySet` containing the set of
+      objects selected by the user.
 
 Our publish-these-articles function won't need the :class:`ModelAdmin` or the
 request object, but we will use the queryset::

docs/ref/contrib/admin/index.txt

@@ -713,13 +713,14 @@ subclass::
 .. attribute:: ModelAdmin.list_select_related
 
     Set ``list_select_related`` to tell Django to use
-    :meth:`~django.db.models.QuerySet.select_related` in retrieving the list of
-    objects on the admin change list page. This can save you a bunch of
-    database queries.
+    :meth:`~django.db.models.query.QuerySet.select_related` in retrieving
+    the list of objects on the admin change list page. This can save you a
+    bunch of database queries.
 
     The value should be either ``True`` or ``False``. Default is ``False``.
 
-    Note that Django will use :meth:`~django.db.models.QuerySet.select_related`,
+    Note that Django will use
+    :meth:`~django.db.models.query.QuerySet.select_related`,
     regardless of this setting if one of the ``list_display`` fields is a
     ``ForeignKey``.
 
@@ -1182,9 +1183,9 @@ templates used by the :class:`ModelAdmin` views:
 .. method:: ModelAdmin.queryset(self, request)
 
     The ``queryset`` method on a ``ModelAdmin`` returns a
-    :class:`~django.db.models.QuerySet` of all model instances that can be
-    edited by the admin site. One use case for overriding this method is
-    to show objects owned by the logged-in user::
+    :class:`~django.db.models.query.QuerySet` of all model instances that
+    can be edited by the admin site. One use case for overriding this method
+    is to show objects owned by the logged-in user::
 
         class MyModelAdmin(admin.ModelAdmin):
             def queryset(self, request):

docs/ref/contrib/contenttypes.txt

@@ -116,7 +116,8 @@ model it represents, or to retrieve objects from that model:
 
     Takes a set of valid :ref:`lookup arguments <field-lookups-intro>` for the
     model the :class:`~django.contrib.contenttypes.models.ContentType`
-    represents, and does :meth:`a get() lookup <django.db.models.QuerySet.get>`
+    represents, and does
+    :meth:`a get() lookup <django.db.models.query.QuerySet.get>`
     on that model, returning the corresponding object.
 
 .. method:: ContentType.model_class()
@@ -416,9 +417,9 @@ might be tempted to try something like::
 
 This will not work correctly, however. The generic relation adds extra filters
 to the queryset to ensure the correct content type, but the
-:meth:`~django.db.models.QuerySet.aggregate` method doesn't take them into
-account. For now, if you need aggregates on generic relations, you'll need
-to calculate them without using the aggregation API.
+:meth:`~django.db.models.query.QuerySet.aggregate` method doesn't take them
+into account. For now, if you need aggregates on generic relations, you'll
+need to calculate them without using the aggregation API.
 
 Generic relations in forms and admin
 ------------------------------------

docs/ref/contrib/gis/db-api.txt

@@ -119,7 +119,7 @@ A complete reference can be found in the :ref:`spatial lookup reference
 .. note::
 
     GeoDjango constructs spatial SQL with the :class:`GeoQuerySet`, a
-    subclass of :class:`~django.db.models.QuerySet`.  The
+    subclass of :class:`~django.db.models.query.QuerySet`.  The
     :class:`GeoManager` instance attached to your model is what
     enables use of :class:`GeoQuerySet`.
 

docs/ref/models/options.txt

@@ -89,7 +89,7 @@ Django quotes column and table names behind the scenes.
 
         get_latest_by = "order_date"
 
-    See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
+    See the docs for :meth:`~django.db.models.query.QuerySet.latest` for more.
 
 ``managed``
 -----------

docs/ref/models/querysets.txt

@@ -106,11 +106,11 @@ described here.
 
 .. admonition:: You can't share pickles between versions
 
-	Pickles of QuerySets are only valid for the version of Django that
-	was used to generate them. If you generate a pickle using Django
-	version N, there is no guarantee that pickle will be readable with
-	Django version N+1. Pickles should not be used as part of a long-term
-	archival strategy.
+    Pickles of QuerySets are only valid for the version of Django that
+    was used to generate them. If you generate a pickle using Django
+    version N, there is no guarantee that pickle will be readable with
+    Django version N+1. Pickles should not be used as part of a long-term
+    archival strategy.
 
 .. _queryset-api:
 
@@ -133,9 +133,9 @@ Though you usually won't create one manually — you'll go through a
 
     .. attribute:: ordered
 
-	``True`` if the ``QuerySet`` is ordered — i.e. has an
-	:meth:`order_by()` clause or a default ordering on the model.
-	``False`` otherwise.
+        ``True`` if the ``QuerySet`` is ordered — i.e. has an
+        :meth:`order_by()` clause or a default ordering on the model.
+        ``False`` otherwise.
 
     .. attribute:: db
 
@@ -468,8 +468,8 @@ This restriction has been lifted, and you can now also refer to fields on
 related models with reverse relations through ``OneToOneField``, ``ForeignKey``
 and ``ManyToManyField`` attributes::
 
-	Blog.objects.values('name', 'entry__headline')
-	[{'name': 'My blog', 'entry__headline': 'An entry'},
+    Blog.objects.values('name', 'entry__headline')
+    [{'name': 'My blog', 'entry__headline': 'An entry'},
          {'name': 'My blog', 'entry__headline': 'Another entry'}, ...]
 
 .. warning::
@@ -788,62 +788,64 @@ of the arguments is required, but you should use at least one of them.
 
             SELECT * FROM blog_entry WHERE id IN (3, 4, 5, 20);
 
-	Be careful when using the ``tables`` parameter if you're specifying
-	tables that are already used in the query. When you add extra tables
-	via the ``tables`` parameter, Django assumes you want that table
-	included an extra time, if it is already included. That creates a
-	problem, since the table name will then be given an alias. If a table
-	appears multiple times in an SQL statement, the second and subsequent
-	occurrences must use aliases so the database can tell them apart. If
-	you're referring to the extra table you added in the extra ``where``
-	parameter this is going to cause errors.
+        Be careful when using the ``tables`` parameter if you're specifying
+        tables that are already used in the query. When you add extra tables
+        via the ``tables`` parameter, Django assumes you want that table
+        included an extra time, if it is already included. That creates a
+        problem, since the table name will then be given an alias. If a table
+        appears multiple times in an SQL statement, the second and subsequent
+        occurrences must use aliases so the database can tell them apart. If
+        you're referring to the extra table you added in the extra ``where``
+        parameter this is going to cause errors.
 
-	Normally you'll only be adding extra tables that don't already appear
-	in the query. However, if the case outlined above does occur, there are
-	a few solutions. First, see if you can get by without including the
-	extra table and use the one already in the query. If that isn't
-	possible, put your ``extra()`` call at the front of the queryset
-	construction so that your table is the first use of that table.
-	Finally, if all else fails, look at the query produced and rewrite your
-	``where`` addition to use the alias given to your extra table. The
-	alias will be the same each time you construct the queryset in the same
-	way, so you can rely upon the alias name to not change.
+        Normally you'll only be adding extra tables that don't already appear
+        in the query. However, if the case outlined above does occur, there are
+        a few solutions. First, see if you can get by without including the
+        extra table and use the one already in the query. If that isn't
+        possible, put your ``extra()`` call at the front of the queryset
+        construction so that your table is the first use of that table.
+        Finally, if all else fails, look at the query produced and rewrite your
+        ``where`` addition to use the alias given to your extra table. The
+        alias will be the same each time you construct the queryset in the same
+        way, so you can rely upon the alias name to not change.
 
     * ``order_by``
-	If you need to order the resulting queryset using some of the new
-	fields or tables you have included via ``extra()`` use the ``order_by``
-	parameter to ``extra()`` and pass in a sequence of strings. These
-	strings should either be model fields (as in the normal
-	:meth:`order_by()` method on querysets), of the form
-	``table_name.column_name`` or an alias for a column that you specified
-	in the ``select`` parameter to ``extra()``.
+
+        If you need to order the resulting queryset using some of the new
+        fields or tables you have included via ``extra()`` use the ``order_by``
+        parameter to ``extra()`` and pass in a sequence of strings. These
+        strings should either be model fields (as in the normal
+        :meth:`order_by()` method on querysets), of the form
+        ``table_name.column_name`` or an alias for a column that you specified
+        in the ``select`` parameter to ``extra()``.
 
         For example::
 
             q = Entry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"})
             q = q.extra(order_by = ['-is_recent'])
 
-	This would sort all the items for which ``is_recent`` is true to the
-	front of the result set (``True`` sorts before ``False`` in a
-	descending ordering).
+        This would sort all the items for which ``is_recent`` is true to the
+        front of the result set (``True`` sorts before ``False`` in a
+        descending ordering).
 
-	This shows, by the way, that you can make multiple calls to ``extra()``
-	and it will behave as you expect (adding new constraints each time).
+        This shows, by the way, that you can make multiple calls to ``extra()``
+        and it will behave as you expect (adding new constraints each time).
 
     * ``params``
-	The ``where`` parameter described above may use standard Python
-	database string placeholders — ``'%s'`` to indicate parameters the
-	database engine should automatically quote. The ``params`` argument is
-	a list of any extra parameters to be substituted.
+
+        The ``where`` parameter described above may use standard Python
+        database string placeholders — ``'%s'`` to indicate parameters the
+        database engine should automatically quote. The ``params`` argument is
+        a list of any extra parameters to be substituted.
 
         Example::
 
             Entry.objects.extra(where=['headline=%s'], params=['Lennon'])
 
-	Always use ``params`` instead of embedding values directly into
-	``where`` because ``params`` will ensure values are quoted correctly
-	according to your particular backend. For example, quotes will be
-	escaped correctly.
+        Always use ``params`` instead of embedding values directly into
+        ``where`` because ``params`` will ensure values are quoted correctly
+        according to your particular backend. For example, quotes will be
+        escaped correctly.
 
         Bad::
 

docs/releases/1.1-beta-1.txt

@@ -70,8 +70,8 @@ particular fields, you can now tell Django not to retrieve them from the
 database.
 
 You'll do this with the new queryset methods
-:meth:`~django.db.models.QuerySet.defer` and
-:meth:`~django.db.models.QuerySet.only`.
+:meth:`~django.db.models.query.QuerySet.defer` and
+:meth:`~django.db.models.query.QuerySet.only`.
 
 New admin features
 ------------------

docs/releases/1.1.txt

@@ -257,8 +257,8 @@ particular fields, you can now tell Django not to retrieve them from the
 database.
 
 You'll do this with the new queryset methods
-:meth:`~django.db.models.QuerySet.defer` and
-:meth:`~django.db.models.QuerySet.only`.
+:meth:`~django.db.models.query.QuerySet.defer` and
+:meth:`~django.db.models.query.QuerySet.only`.
 
 Testing improvements
 --------------------

docs/topics/db/aggregation.txt

@@ -349,10 +349,10 @@ without any harmful effects, since that is already playing a role in the
 query.
 
 This behavior is the same as that noted in the queryset documentation for
-:meth:`~django.db.models.QuerySet.distinct` and the general rule is the same:
-normally you won't want extra columns playing a part in the result, so clear
-out the ordering, or at least make sure it's restricted only to those fields
-you also select in a ``values()`` call.
+:meth:`~django.db.models.query.QuerySet.distinct` and the general rule is the
+same: normally you won't want extra columns playing a part in the result, so
+clear out the ordering, or at least make sure it's restricted only to those
+fields you also select in a ``values()`` call.
 
 .. note::
     You might reasonably ask why Django doesn't remove the extraneous columns

docs/topics/db/optimization.txt

@@ -101,7 +101,7 @@ Use ``iterator()``
 
 When you have a lot of objects, the caching behavior of the ``QuerySet`` can
 cause a large amount of memory to be used. In this case,
-:meth:`~django.db.models.QuerySet.iterator()` may help.
+:meth:`~django.db.models.query.QuerySet.iterator()` may help.
 
 Do database work in the database rather than in Python
 ======================================================
@@ -122,7 +122,7 @@ Use ``QuerySet.extra()``
 ------------------------
 
 A less portable but more powerful method is
-:meth:`~django.db.models.QuerySet.extra()`, which allows some SQL to be
+:meth:`~django.db.models.query.QuerySet.extra()`, which allows some SQL to be
 explicitly added to the query. If that still isn't powerful enough:
 
 Use raw SQL
@@ -159,7 +159,8 @@ Use ``QuerySet.values()`` and ``values_list()``
 -----------------------------------------------
 
 When you just want a ``dict`` or ``list`` of values, and don't need ORM model
-objects, make appropriate usage of :meth:`~django.db.models.QuerySet.values()`.
+objects, make appropriate usage of
+:meth:`~django.db.models.query.QuerySet.values()`.
 These can be useful for replacing model objects in template code - as long as
 the dicts you supply have the same attributes as those used in the template,
 you are fine.
@@ -167,9 +168,9 @@ you are fine.
 Use ``QuerySet.defer()`` and ``only()``
 ---------------------------------------
 
-Use :meth:`~django.db.models.QuerySet.defer()` and
-:meth:`~django.db.models.QuerySet.only()` if there are database columns you
-know that you won't need (or won't need in most cases) to avoid loading
+Use :meth:`~django.db.models.query.QuerySet.defer()` and
+:meth:`~django.db.models.query.QuerySet.only()` if there are database columns
+you know that you won't need (or won't need in most cases) to avoid loading
 them. Note that if you *do* use them, the ORM will have to go and get them in
 a separate query, making this a pessimization if you use it inappropriately.
 

docs/topics/db/queries.txt

@@ -346,7 +346,7 @@ This is roughly equivalent to::
 
 Note, however, that the first of these will raise ``IndexError`` while the
 second will raise ``DoesNotExist`` if no objects match the given criteria. See
-:meth:`~django.db.models.QuerySet.get` for more details.
+:meth:`~django.db.models.query.QuerySet.get` for more details.
 
 .. _field-lookups-intro:
 

docs/topics/db/sql.txt

@@ -124,8 +124,8 @@ Fields may also be left out::
     >>> people = Person.objects.raw('SELECT id, first_name FROM myapp_person')
 
 The ``Person`` objects returned by this query will be deferred model instances
-(see :meth:`~django.db.models.QuerySet.defer()`). This means that the fields
-that are omitted from the query will be loaded on demand. For example::
+(see :meth:`~django.db.models.query.QuerySet.defer()`). This means that the
+fields that are omitted from the query will be loaded on demand. For example::
 
     >>> for p in Person.objects.raw('SELECT id, first_name FROM myapp_person'):
     ...     print p.first_name, # This will be retrieved by the original query

docs/topics/serialization.txt

@@ -21,9 +21,10 @@ At the highest level, serializing data is a very simple operation::
     data = serializers.serialize("xml", SomeModel.objects.all())
 
 The arguments to the ``serialize`` function are the format to serialize the data
-to (see `Serialization formats`_) and a :class:`~django.db.models.QuerySet` to
-serialize. (Actually, the second argument can be any iterator that yields Django
-objects, but it'll almost always be a QuerySet).
+to (see `Serialization formats`_) and a
+:class:`~django.db.models.query.QuerySet` to serialize. (Actually, the second
+argument can be any iterator that yields Django objects, but it'll almost
+always be a QuerySet).
 
 You can also use a serializer object directly::
 

tests/regressiontests/queries/models.py

@@ -334,7 +334,7 @@ class CategoryItem(models.Model):
     category = models.ForeignKey(SimpleCategory)
 
     def __unicode__(self):
- 	    return "category item: " + str(self.category)
+        return "category item: " + str(self.category)
 
 class OneToOneCategory(models.Model):
     new_name = models.CharField(max_length=15)