Fixed #15363 -- Renamed and normalized to `get_queryset` the methods that return a QuerySet.

7 files changed, 56 insertions, 35 deletions

diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt
index 30d452cbe2..1d9a7c7427 100644
--- a/docs/faq/admin.txt
+++ b/docs/faq/admin.txt
@@ -49,7 +49,7 @@ How do I limit admin access so that objects can only be edited by the users who
 The :class:`~django.contrib.admin.ModelAdmin` class also provides customization
 hooks that allow you to control the visibility and editability of objects in the
 admin. Using the same trick of extracting the user from the request, the
-:meth:`~django.contrib.admin.ModelAdmin.queryset` and
+:meth:`~django.contrib.admin.ModelAdmin.get_queryset` and
 :meth:`~django.contrib.admin.ModelAdmin.has_change_permission` can be used to
 control the visibility and editability of objects in the admin.
 
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index 3a9cbd195d..b5173af298 100644
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -341,6 +341,15 @@ these changes.
 
 * The private API ``django.db.close_connection`` will be removed.
 
+* Remove the backward compatible shims introduced to rename ``get_query_set``
+  and similar queryset methods. This affects the following classes:
+  ``BaseModelAdmin``, ``ChangeList``, ``BaseCommentNode``,
+  ``GenericForeignKey``, ``Manager``, ``SingleRelatedObjectDescriptor`` and
+  ``ReverseSingleRelatedObjectDescriptor``.
+
+* Remove the backward compatible shims introduced to rename the attributes
+  ``ChangeList.root_query_set`` and ``ChangeList.query_set``.
+
 2.0
 ---
 
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
index 9a0f3ca7f8..ae2ee44601 100644
--- a/docs/ref/contrib/admin/index.txt
+++ b/docs/ref/contrib/admin/index.txt
@@ -703,7 +703,7 @@ subclass::
                       Only show the lookups if there actually is
                       anyone born in the corresponding decades.
                       """
-                      qs = model_admin.queryset(request)
+                      qs = model_admin.get_queryset(request)
                       if qs.filter(birthday__gte=date(1980, 1, 1),
                                     birthday__lte=date(1989, 12, 31)).exists():
                           yield ('80s', _('in the eighties'))
@@ -1326,20 +1326,23 @@ templates used by the :class:`ModelAdmin` views:
     be interpreted as meaning that the current user is not permitted to delete
     any object of this type).
 
-.. method:: ModelAdmin.queryset(self, request)
+.. method:: ModelAdmin.get_queryset(self, request)
 
-    The ``queryset`` method on a ``ModelAdmin`` returns a
+    The ``get_queryset`` method on a ``ModelAdmin`` returns a
     :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):
-                qs = super(MyModelAdmin, self).queryset(request)
+            def get_queryset(self, request):
+                qs = super(MyModelAdmin, self).get_queryset(request)
                 if request.user.is_superuser:
                     return qs
                 return qs.filter(author=request.user)
 
+    .. versionchanged:: 1.6
+        The ``get_queryset`` method was previously named ``queryset``.
+
 .. method:: ModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False)
 
     Sends a message to the user using the :mod:`django.contrib.messages`
@@ -1549,7 +1552,7 @@ adds some of its own (the shared features are actually defined in the
 - :attr:`~ModelAdmin.filter_vertical`
 - :attr:`~ModelAdmin.ordering`
 - :attr:`~ModelAdmin.prepopulated_fields`
-- :meth:`~ModelAdmin.queryset`
+- :meth:`~ModelAdmin.get_queryset`
 - :attr:`~ModelAdmin.radio_fields`
 - :attr:`~ModelAdmin.readonly_fields`
 - :attr:`~InlineModelAdmin.raw_id_fields`
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index 0fa8b8e361..224c2427b0 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -1586,32 +1586,32 @@ The most efficient method of finding whether a model with a unique field
 (e.g. ``primary_key``) is a member of a :class:`.QuerySet` is::
 
     entry = Entry.objects.get(pk=123)
-    if some_query_set.filter(pk=entry.pk).exists():
+    if some_queryset.filter(pk=entry.pk).exists():
         print("Entry contained in queryset")
 
 Which will be faster than the following which requires evaluating and iterating
 through the entire queryset::
 
-    if entry in some_query_set:
+    if entry in some_queryset:
        print("Entry contained in QuerySet")
 
 And to find whether a queryset contains any items::
 
-    if some_query_set.exists():
-        print("There is at least one object in some_query_set")
+    if some_queryset.exists():
+        print("There is at least one object in some_queryset")
 
 Which will be faster than::
 
-    if some_query_set:
-        print("There is at least one object in some_query_set")
+    if some_queryset:
+        print("There is at least one object in some_queryset")
 
 ... but not by a large degree (hence needing a large queryset for efficiency
 gains).
 
-Additionally, if a ``some_query_set`` has not yet been evaluated, but you know
-that it will be at some point, then using ``some_query_set.exists()`` will do
+Additionally, if a ``some_queryset`` has not yet been evaluated, but you know
+that it will be at some point, then using ``some_queryset.exists()`` will do
 more overall work (one query for the existence check plus an extra one to later
-retrieve the results) than simply using ``bool(some_query_set)``, which
+retrieve the results) than simply using ``bool(some_queryset)``, which
 retrieves the results and then checks if any were returned.
 
 update
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 81b1e48d25..c8012ab7c2 100644
--- a/docs/releases/1.6.txt
+++ b/docs/releases/1.6.txt
@@ -289,3 +289,9 @@ on a widget, you should now define this method on the form field itself.
 
 ``Model._meta.module_name`` was renamed to ``model_name``. Despite being a
 private API, it will go through a regular deprecation path.
+
+``get_query_set`` and similar methods renamed to ``get_queryset``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Methods that return a ``QuerySet`` such as ``Manager.get_query_set`` or
+``ModelAdmin.queryset`` have been renamed to ``get_queryset``.
diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt
index a14616a17c..a8c0d17076 100644
--- a/docs/topics/db/managers.txt
+++ b/docs/topics/db/managers.txt
@@ -108,7 +108,7 @@ example, using this model::
 ...the statement ``Book.objects.all()`` will return all books in the database.
 
 You can override a ``Manager``\'s base ``QuerySet`` by overriding the
-``Manager.get_query_set()`` method. ``get_query_set()`` should return a
+``Manager.get_queryset()`` method. ``get_queryset()`` should return a
 ``QuerySet`` with the properties you require.
 
 For example, the following model has *two* ``Manager``\s -- one that returns
@@ -116,8 +116,8 @@ all objects, and one that returns only the books by Roald Dahl::
 
     # First, define the Manager subclass.
     class DahlBookManager(models.Manager):
-        def get_query_set(self):
-            return super(DahlBookManager, self).get_query_set().filter(author='Roald Dahl')
+        def get_queryset(self):
+            return super(DahlBookManager, self).get_queryset().filter(author='Roald Dahl')
 
     # Then hook it into the Book model explicitly.
     class Book(models.Model):
@@ -131,7 +131,7 @@ With this sample model, ``Book.objects.all()`` will return all books in the
 database, but ``Book.dahl_objects.all()`` will only return the ones written by
 Roald Dahl.
 
-Of course, because ``get_query_set()`` returns a ``QuerySet`` object, you can
+Of course, because ``get_queryset()`` returns a ``QuerySet`` object, you can
 use ``filter()``, ``exclude()`` and all the other ``QuerySet`` methods on it.
 So these statements are all legal::
 
@@ -147,12 +147,12 @@ models.
 For example::
 
     class MaleManager(models.Manager):
-        def get_query_set(self):
-            return super(MaleManager, self).get_query_set().filter(sex='M')
+        def get_queryset(self):
+            return super(MaleManager, self).get_queryset().filter(sex='M')
 
     class FemaleManager(models.Manager):
-        def get_query_set(self):
-            return super(FemaleManager, self).get_query_set().filter(sex='F')
+        def get_queryset(self):
+            return super(FemaleManager, self).get_queryset().filter(sex='F')
 
     class Person(models.Model):
         first_name = models.CharField(max_length=50)
@@ -172,9 +172,12 @@ the "default" ``Manager``, and several parts of Django
 (including :djadmin:`dumpdata`) will use that ``Manager``
 exclusively for that model. As a result, it's a good idea to be careful in
 your choice of default manager in order to avoid a situation where overriding
-``get_query_set()`` results in an inability to retrieve objects you'd like to
+``get_queryset()`` results in an inability to retrieve objects you'd like to
 work with.
 
+.. versionchanged:: 1.6
+    The ``get_queryset`` method was previously named ``get_query_set``.
+
 .. _managers-for-related-objects:
 
 Using managers for related object access
@@ -379,9 +382,9 @@ to from some other model. In those situations, Django has to be able to see
 all the objects for the model it is fetching, so that *anything* which is
 referred to can be retrieved.
 
-If you override the ``get_query_set()`` method and filter out any rows, Django
+If you override the ``get_queryset()`` method and filter out any rows, Django
 will return incorrect results. Don't do that. A manager that filters results
-in ``get_query_set()`` is not appropriate for use as an automatic manager.
+in ``get_queryset()`` is not appropriate for use as an automatic manager.
 
 Set ``use_for_related_fields`` when you define the class
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt
index 8150e498de..ae23c3d9f3 100644
--- a/docs/topics/db/multi-db.txt
+++ b/docs/topics/db/multi-db.txt
@@ -506,19 +506,19 @@ solution is to use ``db_manager()``, like this::
 
 ``db_manager()`` returns a copy of the manager bound to the database you specify.
 
-Using ``get_query_set()`` with multiple databases
+Using ``get_queryset()`` with multiple databases
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you're overriding ``get_query_set()`` on your manager, be sure to
+If you're overriding ``get_queryset()`` on your manager, be sure to
 either call the method on the parent (using ``super()``) or do the
 appropriate handling of the ``_db`` attribute on the manager (a string
 containing the name of the database to use).
 
 For example, if you want to return a custom ``QuerySet`` class from
-the ``get_query_set`` method, you could do this::
+the ``get_queryset`` method, you could do this::
 
     class MyManager(models.Manager):
-        def get_query_set(self):
+        def get_queryset(self):
             qs = CustomQuerySet(self.model)
             if self._db is not None:
                 qs = qs.using(self._db)
@@ -548,9 +548,9 @@ multiple-database support::
             # Tell Django to delete objects from the 'other' database
             obj.delete(using=self.using)
 
-        def queryset(self, request):
+        def get_queryset(self, request):
             # Tell Django to look for objects on the 'other' database.
-            return super(MultiDBModelAdmin, self).queryset(request).using(self.using)
+            return super(MultiDBModelAdmin, self).get_queryset(request).using(self.using)
 
         def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
             # Tell Django to populate ForeignKey widgets using a query
@@ -573,9 +573,9 @@ Inlines can be handled in a similar fashion. They require three customized metho
     class MultiDBTabularInline(admin.TabularInline):
         using = 'other'
 
-        def queryset(self, request):
+        def get_queryset(self, request):
             # Tell Django to look for inline objects on the 'other' database.
-            return super(MultiDBTabularInline, self).queryset(request).using(self.using)
+            return super(MultiDBTabularInline, self).get_queryset(request).using(self.using)
 
         def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
             # Tell Django to populate ForeignKey widgets using a query