queryset-refactor: Merged from trunk up to [7122].

git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7124 bcc190cf-cafb-0310-a4f2-bffc1f526a37

3 files changed, 46 insertions, 12 deletions

diff --git a/tests/modeltests/model_forms/models.py b/tests/modeltests/model_forms/models.py
index f1fed8f1e1..c480899f84 100644
--- a/tests/modeltests/model_forms/models.py
+++ b/tests/modeltests/model_forms/models.py
@@ -64,11 +64,11 @@ class TextFile(models.Model):
 
     def __unicode__(self):
         return self.description
-        
+
 class ImageFile(models.Model):
     description = models.CharField(max_length=20)
     image = models.FileField(upload_to=tempfile.gettempdir())
-    
+
     def __unicode__(self):
         return self.description
 
@@ -155,29 +155,52 @@ familiar with the mechanics.
 ...     class Meta:
 ...         model = Category
 
->>> class BadForm(CategoryForm):
+>>> class OddForm(CategoryForm):
 ...     class Meta:
 ...         model = Article
-Traceback (most recent call last):
-...
-ImproperlyConfigured: BadForm defines a different model than its parent.
+
+OddForm is now an Article-related thing, because BadForm.Meta overrides
+CategoryForm.Meta.
+>>> OddForm.base_fields.keys()
+['headline', 'slug', 'pub_date', 'writer', 'article', 'status', 'categories']
 
 >>> class ArticleForm(ModelForm):
 ...     class Meta:
 ...         model = Article
 
+First class with a Meta class wins.
+
 >>> class BadForm(ArticleForm, CategoryForm):
 ...     pass
-Traceback (most recent call last):
-...
-ImproperlyConfigured: BadForm's base classes define more than one model.
+>>> OddForm.base_fields.keys()
+['headline', 'slug', 'pub_date', 'writer', 'article', 'status', 'categories']
 
-This one is OK since the subclass specifies the same model as the parent.
+Subclassing without specifying a Meta on the class will use the parent's Meta
+(or the first parent in the MRO if there are multiple parent classes).
 
+>>> class CategoryForm(ModelForm):
+...     class Meta:
+...         model = Category
 >>> class SubCategoryForm(CategoryForm):
+...     pass
+>>> SubCategoryForm.base_fields.keys()
+['name', 'slug', 'url']
+
+We can also subclass the Meta inner class to change the fields list.
+
+>>> class CategoryForm(ModelForm):
+...     checkbox = forms.BooleanField()
+...
 ...     class Meta:
 ...         model = Category
+>>> class SubCategoryForm(CategoryForm):
+...     class Meta(CategoryForm.Meta):
+...         exclude = ['url']
 
+>>> print SubCategoryForm()
+<tr><th><label for="id_name">Name:</label></th><td><input id="id_name" type="text" name="name" maxlength="20" /></td></tr>
+<tr><th><label for="id_slug">Slug:</label></th><td><input id="id_slug" type="text" name="slug" maxlength="20" /></td></tr>
+<tr><th><label for="id_checkbox">Checkbox:</label></th><td><input type="checkbox" name="checkbox" id="id_checkbox" /></td></tr>
 
 # Old form_for_x tests #######################################################
 
diff --git a/tests/modeltests/ordering/models.py b/tests/modeltests/ordering/models.py
index d3eb7f0dc0..5f1c3c3b81 100644
--- a/tests/modeltests/ordering/models.py
+++ b/tests/modeltests/ordering/models.py
@@ -2,8 +2,8 @@
 6. Specifying ordering
 
 Specify default ordering for a model using the ``ordering`` attribute, which
-should be a list or tuple of field names. This tells Django how to order the
-results of ``get_list()`` and other similar functions.
+should be a list or tuple of field names. This tells Django how to order
+queryset results.
 
 If a field name in ``ordering`` starts with a hyphen, that field will be
 ordered in descending order. Otherwise, it'll be ordered in ascending order.
diff --git a/tests/regressiontests/i18n/misc.py b/tests/regressiontests/i18n/misc.py
index eb64263799..6ed8afaee3 100644
--- a/tests/regressiontests/i18n/misc.py
+++ b/tests/regressiontests/i18n/misc.py
@@ -1,3 +1,5 @@
+import sys
+
 tests = """
 >>> from django.utils.translation.trans_real import parse_accept_lang_header
 >>> p = parse_accept_lang_header
@@ -83,7 +85,14 @@ source tree.
 >>> r.META = {'HTTP_ACCEPT_LANGUAGE': 'es-ar,de'}
 >>> g(r)
 'es-ar'
+"""
 
+# Python 2.3 returns slightly different results for completely bogus locales,
+# so we omit this test for that anything below 2.4. It's relatively harmless in
+# any cases (GIGO). This also means this won't be executed on Jython currently,
+# but life's like that sometimes.
+if sys.version_info >= (2, 4):
+    tests += """
 This test assumes there won't be a Django translation to a US variation
 of the Spanish language, a safe assumption. When the user sets it
 as the preferred language, the main 'es' translation should be selected
@@ -91,7 +100,9 @@ instead.
 >>> r.META = {'HTTP_ACCEPT_LANGUAGE': 'es-us'}
 >>> g(r)
 'es'
+"""
 
+tests += """
 This tests the following scenario: there isn't a main language (zh)
 translation of Django but there is a translation to variation (zh_CN)
 the user sets zh-cn as the preferred language, it should be selected by