Re: [Django] #8054: Move method properties for admin list customisation to ModelAdmin

[Django]

#8054: Move method properties for admin list customisation to ModelAdmin
+---
  Reporter:  Daniel Pope   | Owner:  
brosner
Status:  assigned   | Milestone:  
1.3
 Component:  django.contrib.admin   |   Version:  
SVN
Resolution: |  Keywords:
 
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by alekam):

  * needs_better_patch:  1 => 0
  * needs_docs:  1 => 0
  * needs_tests:  1 => 0
  * milestone:  => 1.3

Comment:

 Wiki page with this ticket goals and documentation - ListColumns

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14455: [patch] Minor regression test fix

[Django]

#14455: [patch] Minor regression test fix
-+--
  Reporter:  kylefox | Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  django.contrib.localflavor  |   Version:  SVN  

Resolution:  |  Keywords:  localflavor, 
regression, test
 Stage:  Accepted| Has_patch:  1

Needs_docs:  1   |   Needs_tests:  0

Needs_better_patch:  1   |  
-+--
Changes (by russellm):

  * needs_better_patch:  0 => 1
  * needs_docs:  0 => 1

Comment:

 Following discussion on IRC with Karen, Alex, Ramiro, SmileyChris and
 myself:

 There is a backwards compatibility issue here, and we can't ignore it.
 However, by the same token, maintaining displayable lists that contain
 invalid data (i.e., deprecated, renamed and dissolved provinces) is
 equally bad.

 So - here's the plan:
  * We will document our policy that as a project, we will maintain
 alignment with officially gazetted municipality lists. If Indonesia
 deprecates the name, so do we in the next major release, and if an
 official abbreviation has changed, we'll reflect that change too.
  * We *won't* backport any such change to the stable branch. Micro
 releases shouldn't affect display/behavior, or require any data migration.
  * When we introduce such a change, we will include it in the release
 notes as a noteworthy backwards compatibility issue.
  * We will provide a new documentation page that will provide any
 script/SQL/utility/example that might help with migration process.
  * For the affected release, the module in question will raise a Warning.
 This ensures that anyone that uses the module and doesn't read the release
 notes will get notified that there is a problem that needs to be resolved.
  * We will provide a section in the localflavor docs telling people how to
 silence the warning once they've addressed the issue.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11350: Support "local flavor" for Israel

[Django]

#11350: Support "local flavor" for Israel
-+--
  Reporter:  yuval_a | Owner:  yuval_a  
  
Status:  reopened| Milestone:  1.3  
  
 Component:  django.contrib.localflavor  |   Version:  SVN  
  
Resolution:  |  Keywords:  local flavor 
israel
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by Alex):

 Does anyone know where I can find a description of the Israeli ID
 specification, google yields nothing of use.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11754: mod_fastcgi documentation should specify full path to .fcgi script

[Django]

#11754: mod_fastcgi documentation should specify full path to .fcgi script
+---
  Reporter:  joeforker  | Owner:  nobody
Status:  reopened   | Milestone:  1.3   
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:  deployment
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by PaulM):

  * keywords:  => deployment
  * status:  closed => reopened
  * stage:  Unreviewed => Accepted
  * resolution:  duplicate =>
  * milestone:  => 1.3

Comment:

 I'm re-opening this as it does document an apache-specific issue with the
 fastcgi docs. The issue that it is marked as duplicating documents a
 different lighttpd specific issue.

 I'm helping re-work the fastcgi docs and don't want this to get lost in
 the shuffle.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14455: [patch] Minor regression test fix

[Django]

#14455: [patch] Minor regression test fix
-+--
  Reporter:  kylefox | Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  django.contrib.localflavor  |   Version:  SVN  

Resolution:  |  Keywords:  localflavor, 
regression, test
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Comment (by Alex):

 I seem to recall we had this issue before, anyone good at search or
 remember the result?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14213 - django/branches/releases/1.2.X/tests/regressiontests/inline_formsets

[noreply]

Author: Alex
Date: 2010-10-13 20:40:39 -0500 (Wed, 13 Oct 2010)
New Revision: 14213

Modified:
   
django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/models.py
   django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/tests.py
Log:
[1.2.X] Fixed #14456 -- converted inline_formsets tests from doctests to 
unittests.  We have always been at war with doctests.  Thanks to prestontimmons 
for the patch.  Backport of [14212].

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/models.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/models.py  
2010-10-14 01:40:20 UTC (rev 14212)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/models.py  
2010-10-14 01:40:39 UTC (rev 14213)
@@ -1,6 +1,7 @@
 # coding: utf-8
 from django.db import models
 
+
 class School(models.Model):
 name = models.CharField(max_length=100)
 
@@ -25,46 +26,3 @@
 
 def __unicode__(self):
 return self.name
-
-__test__ = {'API_TESTS': """
-
->>> from django.forms.models import inlineformset_factory
-
-
-Child has two ForeignKeys to Parent, so if we don't specify which one to use
-for the inline formset, we should get an exception.
-
->>> ifs = inlineformset_factory(Parent, Child)
-Traceback (most recent call last):
-...
-Exception:  has more 
than 1 ForeignKey to 
-
-
-These two should both work without a problem.
-
->>> ifs = inlineformset_factory(Parent, Child, fk_name='mother')
->>> ifs = inlineformset_factory(Parent, Child, fk_name='father')
-
-
-If we specify fk_name, but it isn't a ForeignKey from the child model to the
-parent model, we should get an exception.
-
->>> ifs = inlineformset_factory(Parent, Child, fk_name='school')
-Traceback (most recent call last):
-...
-Exception: fk_name 'school' is not a ForeignKey to 
-
-
-If the field specified in fk_name is not a ForeignKey, we should get an
-exception.
-
->>> ifs = inlineformset_factory(Parent, Child, fk_name='test')
-Traceback (most recent call last):
-...
-Exception:  has no field 
named 'test'
-
-
-# Regression test for #9171.
->>> ifs = inlineformset_factory(Parent, Child, exclude=('school',), 
fk_name='mother')
-"""
-}

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/tests.py   
2010-10-14 01:40:20 UTC (rev 14212)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/inline_formsets/tests.py   
2010-10-14 01:40:39 UTC (rev 14213)
@@ -2,7 +2,9 @@
 from django.forms.models import inlineformset_factory
 from regressiontests.inline_formsets.models import Poet, Poem, School, Parent, 
Child
 
+
 class DeletionTests(TestCase):
+
 def test_deletion(self):
 PoemFormSet = inlineformset_factory(Poet, Poem, can_delete=True)
 poet = Poet.objects.create(name='test')
@@ -103,3 +105,51 @@
 obj.save()
 self.assertEqual(school.child_set.count(), 1)
 
+
+class InlineFormsetFactoryTest(TestCase):
+def test_inline_formset_factory(self):
+"""
+These should both work without a problem.
+"""
+inlineformset_factory(Parent, Child, fk_name='mother')
+inlineformset_factory(Parent, Child, fk_name='father')
+
+def test_exception_on_unspecified_foreign_key(self):
+"""
+Child has two ForeignKeys to Parent, so if we don't specify which one
+to use for the inline formset, we should get an exception.
+"""
+self.assertRaisesRegexp(Exception,
+" has more 
than 1 ForeignKey to ",
+inlineformset_factory, Parent, Child
+)
+
+def test_fk_name_not_foreign_key_field_from_child(self):
+"""
+If we specify fk_name, but it isn't a ForeignKey from the child model
+to the parent model, we should get an exception.
+"""
+self.assertRaises(Exception,
+"fk_name 'school' is not a ForeignKey to ",
+inlineformset_factory, Parent, Child, fk_name='school'
+)
+
+def test_non_foreign_key_field(self):
+"""
+If the field specified in fk_name is not a ForeignKey, we should get an
+exception.
+"""
+self.assertRaisesRegexp(Exception,
+" has no 
field named 'test'",
+inlineformset_factory, Parent, Child, fk_name='test'
+)
+
+def test_any_iterable_allowed_as_argument_to_exclude(self):
+# Regression test for #9171.
+inlineformset_factory(
+Parent, Child, exclude=['school'], fk_name='mother'
+)
+
+inlineformset_factory(
+Parent, Child, exclude=('school',), fk_name='mother'
+)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates"

[Changeset] r14212 - django/trunk/tests/regressiontests/inline_formsets

[noreply]

Author: Alex
Date: 2010-10-13 20:40:20 -0500 (Wed, 13 Oct 2010)
New Revision: 14212

Modified:
   django/trunk/tests/regressiontests/inline_formsets/models.py
   django/trunk/tests/regressiontests/inline_formsets/tests.py
Log:
Fixed #14456 -- converted inline_formsets tests from doctests to unittests.  We 
have always been at war with doctests.  Thanks to prestontimmons for the patch.

Modified: django/trunk/tests/regressiontests/inline_formsets/models.py
===
--- django/trunk/tests/regressiontests/inline_formsets/models.py
2010-10-14 01:24:55 UTC (rev 14211)
+++ django/trunk/tests/regressiontests/inline_formsets/models.py
2010-10-14 01:40:20 UTC (rev 14212)
@@ -1,6 +1,7 @@
 # coding: utf-8
 from django.db import models
 
+
 class School(models.Model):
 name = models.CharField(max_length=100)
 
@@ -25,46 +26,3 @@
 
 def __unicode__(self):
 return self.name
-
-__test__ = {'API_TESTS': """
-
->>> from django.forms.models import inlineformset_factory
-
-
-Child has two ForeignKeys to Parent, so if we don't specify which one to use
-for the inline formset, we should get an exception.
-
->>> ifs = inlineformset_factory(Parent, Child)
-Traceback (most recent call last):
-...
-Exception:  has more 
than 1 ForeignKey to 
-
-
-These two should both work without a problem.
-
->>> ifs = inlineformset_factory(Parent, Child, fk_name='mother')
->>> ifs = inlineformset_factory(Parent, Child, fk_name='father')
-
-
-If we specify fk_name, but it isn't a ForeignKey from the child model to the
-parent model, we should get an exception.
-
->>> ifs = inlineformset_factory(Parent, Child, fk_name='school')
-Traceback (most recent call last):
-...
-Exception: fk_name 'school' is not a ForeignKey to 
-
-
-If the field specified in fk_name is not a ForeignKey, we should get an
-exception.
-
->>> ifs = inlineformset_factory(Parent, Child, fk_name='test')
-Traceback (most recent call last):
-...
-Exception:  has no field 
named 'test'
-
-
-# Regression test for #9171.
->>> ifs = inlineformset_factory(Parent, Child, exclude=('school',), 
fk_name='mother')
-"""
-}

Modified: django/trunk/tests/regressiontests/inline_formsets/tests.py
===
--- django/trunk/tests/regressiontests/inline_formsets/tests.py 2010-10-14 
01:24:55 UTC (rev 14211)
+++ django/trunk/tests/regressiontests/inline_formsets/tests.py 2010-10-14 
01:40:20 UTC (rev 14212)
@@ -2,7 +2,9 @@
 from django.forms.models import inlineformset_factory
 from regressiontests.inline_formsets.models import Poet, Poem, School, Parent, 
Child
 
+
 class DeletionTests(TestCase):
+
 def test_deletion(self):
 PoemFormSet = inlineformset_factory(Poet, Poem, can_delete=True)
 poet = Poet.objects.create(name='test')
@@ -103,3 +105,51 @@
 obj.save()
 self.assertEqual(school.child_set.count(), 1)
 
+
+class InlineFormsetFactoryTest(TestCase):
+def test_inline_formset_factory(self):
+"""
+These should both work without a problem.
+"""
+inlineformset_factory(Parent, Child, fk_name='mother')
+inlineformset_factory(Parent, Child, fk_name='father')
+
+def test_exception_on_unspecified_foreign_key(self):
+"""
+Child has two ForeignKeys to Parent, so if we don't specify which one
+to use for the inline formset, we should get an exception.
+"""
+self.assertRaisesRegexp(Exception,
+" has more 
than 1 ForeignKey to ",
+inlineformset_factory, Parent, Child
+)
+
+def test_fk_name_not_foreign_key_field_from_child(self):
+"""
+If we specify fk_name, but it isn't a ForeignKey from the child model
+to the parent model, we should get an exception.
+"""
+self.assertRaises(Exception,
+"fk_name 'school' is not a ForeignKey to ",
+inlineformset_factory, Parent, Child, fk_name='school'
+)
+
+def test_non_foreign_key_field(self):
+"""
+If the field specified in fk_name is not a ForeignKey, we should get an
+exception.
+"""
+self.assertRaisesRegexp(Exception,
+" has no 
field named 'test'",
+inlineformset_factory, Parent, Child, fk_name='test'
+)
+
+def test_any_iterable_allowed_as_argument_to_exclude(self):
+# Regression test for #9171.
+inlineformset_factory(
+Parent, Child, exclude=['school'], fk_name='mother'
+)
+
+inlineformset_factory(
+Parent, Child, exclude=('school',), fk_name='mother'
+)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, vi

[Changeset] r14211 - django/branches/releases/1.2.X/tests/regressiontests/many_to_one_regress

[noreply]

Author: Alex
Date: 2010-10-13 20:24:55 -0500 (Wed, 13 Oct 2010)
New Revision: 14211

Added:
   
django/branches/releases/1.2.X/tests/regressiontests/many_to_one_regress/tests.py
Modified:
   
django/branches/releases/1.2.X/tests/regressiontests/many_to_one_regress/models.py
Log:
[1.2.X] Fixed #14459 -- converted many_to_one_regress tests from doctests to 
unittests.  We have always been at war with doctests.  Patch from Gabriel 
Hurley.  Backport of [14210].

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/many_to_one_regress/models.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/many_to_one_regress/models.py
  2010-10-14 01:24:34 UTC (rev 14210)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/many_to_one_regress/models.py
  2010-10-14 01:24:55 UTC (rev 14211)
@@ -44,133 +44,3 @@
 
 def __unicode__(self):
 return u"%s - %s" % (self.left.category.name, self.right.category.name)
-
-
-__test__ = {'API_TESTS':"""
->>> Third.objects.create(id='3', name='An example')
-
->>> parent = Parent(name = 'fred')
->>> parent.save()
->>> Child.objects.create(name='bam-bam', parent=parent)
-
-
-#
-# Tests of ForeignKey assignment and the related-object cache (see #6886).
-#
->>> p = Parent.objects.create(name="Parent")
->>> c = Child.objects.create(name="Child", parent=p)
-
-# Look up the object again so that we get a "fresh" object.
->>> c = Child.objects.get(name="Child")
->>> p = c.parent
-
-# Accessing the related object again returns the exactly same object.
->>> c.parent is p
-True
-
-# But if we kill the cache, we get a new object.
->>> del c._parent_cache
->>> c.parent is p
-False
-
-# Assigning a new object results in that object getting cached immediately.
->>> p2 = Parent.objects.create(name="Parent 2")
->>> c.parent = p2
->>> c.parent is p2
-True
-
-# Assigning None succeeds if field is null=True.
->>> p.bestchild = None
->>> p.bestchild is None
-True
-
-# bestchild should still be None after saving.
->>> p.save()
->>> p.bestchild is None
-True
-
-# bestchild should still be None after fetching the object again.
->>> p = Parent.objects.get(name="Parent")
->>> p.bestchild is None
-True
-
-# Assigning None fails: Child.parent is null=False.
->>> c.parent = None
-Traceback (most recent call last):
-...
-ValueError: Cannot assign None: "Child.parent" does not allow null values.
-
-# You also can't assign an object of the wrong type here
->>> c.parent = First(id=1, second=1)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign "": "Child.parent" must be a 
"Parent" instance.
-
-# Nor can you explicitly assign None to Child.parent during object creation
-# (regression for #9649).
->>> Child(name='xyzzy', parent=None)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign None: "Child.parent" does not allow null values.
->>> Child.objects.create(name='xyzzy', parent=None)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign None: "Child.parent" does not allow null values.
-
-# Creation using keyword argument should cache the related object.
->>> p = Parent.objects.get(name="Parent")
->>> c = Child(parent=p)
->>> c.parent is p
-True
-
-# Creation using keyword argument and unsaved related instance (#8070).
->>> p = Parent()
->>> c = Child(parent=p)
->>> c.parent is p
-True
-
-# Creation using attname keyword argument and an id will cause the related
-# object to be fetched.
->>> p = Parent.objects.get(name="Parent")
->>> c = Child(parent_id=p.id)
->>> c.parent is p
-False
->>> c.parent == p
-True
-
-
-#
-# Test of multiple ForeignKeys to the same model (bug #7125).
-#
->>> c1 = Category.objects.create(name='First')
->>> c2 = Category.objects.create(name='Second')
->>> c3 = Category.objects.create(name='Third')
->>> r1 = Record.objects.create(category=c1)
->>> r2 = Record.objects.create(category=c1)
->>> r3 = Record.objects.create(category=c2)
->>> r4 = Record.objects.create(category=c2)
->>> r5 = Record.objects.create(category=c3)
->>> r = Relation.objects.create(left=r1, right=r2)
->>> r = Relation.objects.create(left=r3, right=r4)
->>> r = Relation.objects.create(left=r1, right=r3)
->>> r = Relation.objects.create(left=r5, right=r2)
->>> r = Relation.objects.create(left=r3, right=r2)
-
->>> Relation.objects.filter(left__category__name__in=['First'], 
right__category__name__in=['Second'])
-[]
-
->>> 
Category.objects.filter(record__left_set__right__category__name='Second').order_by('name')
-[, ]
-
->>> c2 = Child.objects.create(name="Grandchild", parent=c)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign "": "Child.parent" must be a 
"Parent" instance.
-
-# Regression for #12190 -- Should be able to instantiate a FK
-# outside of a model, and interrogate its related field.
->>> cat = models.ForeignKey(Category)
->>> cat.rel.get_related_field().name
-'id'
-
-"""}

Added: 
django/branches/releases/1.2.X/tests/regressiontes

[Changeset] r14210 - django/trunk/tests/regressiontests/many_to_one_regress

[noreply]

Author: Alex
Date: 2010-10-13 20:24:34 -0500 (Wed, 13 Oct 2010)
New Revision: 14210

Added:
   django/trunk/tests/regressiontests/many_to_one_regress/tests.py
Modified:
   django/trunk/tests/regressiontests/many_to_one_regress/models.py
Log:
Fixed #14459 -- converted many_to_one_regress tests from doctests to unittests. 
 We have always been at war with doctests.  Patch from Gabriel Hurley.

Modified: django/trunk/tests/regressiontests/many_to_one_regress/models.py
===
--- django/trunk/tests/regressiontests/many_to_one_regress/models.py
2010-10-14 01:24:20 UTC (rev 14209)
+++ django/trunk/tests/regressiontests/many_to_one_regress/models.py
2010-10-14 01:24:34 UTC (rev 14210)
@@ -44,133 +44,3 @@
 
 def __unicode__(self):
 return u"%s - %s" % (self.left.category.name, self.right.category.name)
-
-
-__test__ = {'API_TESTS':"""
->>> Third.objects.create(id='3', name='An example')
-
->>> parent = Parent(name = 'fred')
->>> parent.save()
->>> Child.objects.create(name='bam-bam', parent=parent)
-
-
-#
-# Tests of ForeignKey assignment and the related-object cache (see #6886).
-#
->>> p = Parent.objects.create(name="Parent")
->>> c = Child.objects.create(name="Child", parent=p)
-
-# Look up the object again so that we get a "fresh" object.
->>> c = Child.objects.get(name="Child")
->>> p = c.parent
-
-# Accessing the related object again returns the exactly same object.
->>> c.parent is p
-True
-
-# But if we kill the cache, we get a new object.
->>> del c._parent_cache
->>> c.parent is p
-False
-
-# Assigning a new object results in that object getting cached immediately.
->>> p2 = Parent.objects.create(name="Parent 2")
->>> c.parent = p2
->>> c.parent is p2
-True
-
-# Assigning None succeeds if field is null=True.
->>> p.bestchild = None
->>> p.bestchild is None
-True
-
-# bestchild should still be None after saving.
->>> p.save()
->>> p.bestchild is None
-True
-
-# bestchild should still be None after fetching the object again.
->>> p = Parent.objects.get(name="Parent")
->>> p.bestchild is None
-True
-
-# Assigning None fails: Child.parent is null=False.
->>> c.parent = None
-Traceback (most recent call last):
-...
-ValueError: Cannot assign None: "Child.parent" does not allow null values.
-
-# You also can't assign an object of the wrong type here
->>> c.parent = First(id=1, second=1)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign "": "Child.parent" must be a 
"Parent" instance.
-
-# Nor can you explicitly assign None to Child.parent during object creation
-# (regression for #9649).
->>> Child(name='xyzzy', parent=None)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign None: "Child.parent" does not allow null values.
->>> Child.objects.create(name='xyzzy', parent=None)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign None: "Child.parent" does not allow null values.
-
-# Creation using keyword argument should cache the related object.
->>> p = Parent.objects.get(name="Parent")
->>> c = Child(parent=p)
->>> c.parent is p
-True
-
-# Creation using keyword argument and unsaved related instance (#8070).
->>> p = Parent()
->>> c = Child(parent=p)
->>> c.parent is p
-True
-
-# Creation using attname keyword argument and an id will cause the related
-# object to be fetched.
->>> p = Parent.objects.get(name="Parent")
->>> c = Child(parent_id=p.id)
->>> c.parent is p
-False
->>> c.parent == p
-True
-
-
-#
-# Test of multiple ForeignKeys to the same model (bug #7125).
-#
->>> c1 = Category.objects.create(name='First')
->>> c2 = Category.objects.create(name='Second')
->>> c3 = Category.objects.create(name='Third')
->>> r1 = Record.objects.create(category=c1)
->>> r2 = Record.objects.create(category=c1)
->>> r3 = Record.objects.create(category=c2)
->>> r4 = Record.objects.create(category=c2)
->>> r5 = Record.objects.create(category=c3)
->>> r = Relation.objects.create(left=r1, right=r2)
->>> r = Relation.objects.create(left=r3, right=r4)
->>> r = Relation.objects.create(left=r1, right=r3)
->>> r = Relation.objects.create(left=r5, right=r2)
->>> r = Relation.objects.create(left=r3, right=r2)
-
->>> Relation.objects.filter(left__category__name__in=['First'], 
right__category__name__in=['Second'])
-[]
-
->>> 
Category.objects.filter(record__left_set__right__category__name='Second').order_by('name')
-[, ]
-
->>> c2 = Child.objects.create(name="Grandchild", parent=c)
-Traceback (most recent call last):
-...
-ValueError: Cannot assign "": "Child.parent" must be a 
"Parent" instance.
-
-# Regression for #12190 -- Should be able to instantiate a FK
-# outside of a model, and interrogate its related field.
->>> cat = models.ForeignKey(Category)
->>> cat.rel.get_related_field().name
-'id'
-
-"""}

Added: django/trunk/tests/regressiontests/many_to_one_regress/tests.py
===
--- django/trunk/tests/regressiontests/ma

[Changeset] r14209 - django/trunk/django/contrib/admin

[noreply]

Author: lukeplant
Date: 2010-10-13 20:24:20 -0500 (Wed, 13 Oct 2010)
New Revision: 14209

Modified:
   django/trunk/django/contrib/admin/sites.py
Log:
Fixed reference to removed function root() in AdminSite docstring.

Modified: django/trunk/django/contrib/admin/sites.py
===
--- django/trunk/django/contrib/admin/sites.py  2010-10-14 01:17:32 UTC (rev 
14208)
+++ django/trunk/django/contrib/admin/sites.py  2010-10-14 01:24:20 UTC (rev 
14209)
@@ -28,8 +28,9 @@
 """
 An AdminSite object encapsulates an instance of the Django admin 
application, ready
 to be hooked in to your URLconf. Models are registered with the AdminSite 
using the
-register() method, and the root() method can then be used as a Django view 
function
-that presents a full admin interface for the collection of registered 
models.
+register() method, and the get_urls() method can then be used to access 
Django view
+functions that present a full admin interface for the collection of 
registered
+models.
 """
 
 index_template = None

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14208 - django/branches/releases/1.2.X/tests/regressiontests/managers_regress

[noreply]

Author: Alex
Date: 2010-10-13 20:17:32 -0500 (Wed, 13 Oct 2010)
New Revision: 14208

Added:
   
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/tests.py
Modified:
   
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/models.py
Log:
[1.2.X] Fixed #14460 -- converted managers_regress tests from doctests to 
unittests.  We have always been at war with doctests.  Patch from Gabriel 
Hurley.  Backport of [14207].

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/models.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/models.py 
2010-10-14 01:17:14 UTC (rev 14207)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/models.py 
2010-10-14 01:17:32 UTC (rev 14208)
@@ -98,56 +98,3 @@
 # Will not inherit default manager from parent.
 class Child7(Parent):
 pass
-
-__test__ = {"API_TESTS": """
->>> a1 = Child1.objects.create(name='fred', data='a1')
->>> a2 = Child1.objects.create(name='barney', data='a2')
->>> b1 = Child2.objects.create(name='fred', data='b1', value=1)
->>> b2 = Child2.objects.create(name='barney', data='b2', value=42)
->>> c1 = Child3.objects.create(name='fred', data='c1', comment='yes')
->>> c2 = Child3.objects.create(name='barney', data='c2', comment='no')
->>> d1 = Child4.objects.create(name='fred', data='d1')
->>> d2 = Child4.objects.create(name='barney', data='d2')
->>> e1 = Child5.objects.create(name='fred', comment='yes')
->>> e2 = Child5.objects.create(name='barney', comment='no')
->>> f1 = Child6.objects.create(name='fred', data='f1', value=42)
->>> f2 = Child6.objects.create(name='barney', data='f2', value=42)
->>> g1 = Child7.objects.create(name='fred')
->>> g2 = Child7.objects.create(name='barney')
-
->>> Child1.manager1.all()
-[]
->>> Child1.manager2.all()
-[]
->>> Child1._default_manager.all()
-[]
-
->>> Child2._default_manager.all()
-[]
->>> Child2.restricted.all()
-[]
-
->>> Child3._default_manager.all()
-[]
->>> Child3.manager1.all()
-[]
->>> Child3.manager2.all()
-[]
-
-# Since Child6 inherits from Child4, the corresponding rows from f1 and f2 also
-# appear here. This is the expected result.
->>> Child4._default_manager.order_by('data')
-[, , , ]
->>> Child4.manager1.all()
-[, ]
-
->>> Child5._default_manager.all()
-[]
-
->>> Child6._default_manager.all()
-[]
-
->>> Child7._default_manager.order_by('name')
-[, ]
-
-"""}

Added: 
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/tests.py  
(rev 0)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/managers_regress/tests.py  
2010-10-14 01:17:32 UTC (rev 14208)
@@ -0,0 +1,54 @@
+from django.test import TestCase
+
+from models import Child1, Child2, Child3, Child4, Child5, Child6, Child7
+
+
+class ManagersRegressionTests(TestCase):
+def test_managers(self):
+a1 = Child1.objects.create(name='fred', data='a1')
+a2 = Child1.objects.create(name='barney', data='a2')
+b1 = Child2.objects.create(name='fred', data='b1', value=1)
+b2 = Child2.objects.create(name='barney', data='b2', value=42)
+c1 = Child3.objects.create(name='fred', data='c1', comment='yes')
+c2 = Child3.objects.create(name='barney', data='c2', comment='no')
+d1 = Child4.objects.create(name='fred', data='d1')
+d2 = Child4.objects.create(name='barney', data='d2')
+e1 = Child5.objects.create(name='fred', comment='yes')
+e2 = Child5.objects.create(name='barney', comment='no')
+f1 = Child6.objects.create(name='fred', data='f1', value=42)
+f2 = Child6.objects.create(name='barney', data='f2', value=42)
+g1 = Child7.objects.create(name='fred')
+g2 = Child7.objects.create(name='barney')
+
+self.assertQuerysetEqual(Child1.manager1.all(), [""])
+self.assertQuerysetEqual(Child1.manager2.all(), [""])
+self.assertQuerysetEqual(Child1._default_manager.all(), [""])
+
+self.assertQuerysetEqual(Child2._default_manager.all(), [""])
+self.assertQuerysetEqual(Child2.restricted.all(), [""])
+
+self.assertQuerysetEqual(Child3._default_manager.all(), [""])
+self.assertQuerysetEqual(Child3.manager1.all(), [""])
+self.assertQuerysetEqual(Child3.manager2.all(), [""])
+
+# Since Child6 inherits from Child4, the corresponding rows from f1 and
+# f2 also appear here. This is the expected result.
+self.assertQuerysetEqual(Child4._default_manager.order_by('data'), [
+"",
+"",
+"",
+""
+]
+)
+self.assertQuerysetEqual(Child4.manager1.all(), [
+"",
+""
+]
+)

[Changeset] r14207 - django/trunk/tests/regressiontests/managers_regress

[noreply]

Author: Alex
Date: 2010-10-13 20:17:14 -0500 (Wed, 13 Oct 2010)
New Revision: 14207

Added:
   django/trunk/tests/regressiontests/managers_regress/tests.py
Modified:
   django/trunk/tests/regressiontests/managers_regress/models.py
Log:
Fixed #14460 -- converted managers_regress tests from doctests to unittests.  
We have always been at war with doctests.  Patch from Gabriel Hurley.

Modified: django/trunk/tests/regressiontests/managers_regress/models.py
===
--- django/trunk/tests/regressiontests/managers_regress/models.py   
2010-10-14 01:11:22 UTC (rev 14206)
+++ django/trunk/tests/regressiontests/managers_regress/models.py   
2010-10-14 01:17:14 UTC (rev 14207)
@@ -98,56 +98,3 @@
 # Will not inherit default manager from parent.
 class Child7(Parent):
 pass
-
-__test__ = {"API_TESTS": """
->>> a1 = Child1.objects.create(name='fred', data='a1')
->>> a2 = Child1.objects.create(name='barney', data='a2')
->>> b1 = Child2.objects.create(name='fred', data='b1', value=1)
->>> b2 = Child2.objects.create(name='barney', data='b2', value=42)
->>> c1 = Child3.objects.create(name='fred', data='c1', comment='yes')
->>> c2 = Child3.objects.create(name='barney', data='c2', comment='no')
->>> d1 = Child4.objects.create(name='fred', data='d1')
->>> d2 = Child4.objects.create(name='barney', data='d2')
->>> e1 = Child5.objects.create(name='fred', comment='yes')
->>> e2 = Child5.objects.create(name='barney', comment='no')
->>> f1 = Child6.objects.create(name='fred', data='f1', value=42)
->>> f2 = Child6.objects.create(name='barney', data='f2', value=42)
->>> g1 = Child7.objects.create(name='fred')
->>> g2 = Child7.objects.create(name='barney')
-
->>> Child1.manager1.all()
-[]
->>> Child1.manager2.all()
-[]
->>> Child1._default_manager.all()
-[]
-
->>> Child2._default_manager.all()
-[]
->>> Child2.restricted.all()
-[]
-
->>> Child3._default_manager.all()
-[]
->>> Child3.manager1.all()
-[]
->>> Child3.manager2.all()
-[]
-
-# Since Child6 inherits from Child4, the corresponding rows from f1 and f2 also
-# appear here. This is the expected result.
->>> Child4._default_manager.order_by('data')
-[, , , ]
->>> Child4.manager1.all()
-[, ]
-
->>> Child5._default_manager.all()
-[]
-
->>> Child6._default_manager.all()
-[]
-
->>> Child7._default_manager.order_by('name')
-[, ]
-
-"""}

Added: django/trunk/tests/regressiontests/managers_regress/tests.py
===
--- django/trunk/tests/regressiontests/managers_regress/tests.py
(rev 0)
+++ django/trunk/tests/regressiontests/managers_regress/tests.py
2010-10-14 01:17:14 UTC (rev 14207)
@@ -0,0 +1,54 @@
+from django.test import TestCase
+
+from models import Child1, Child2, Child3, Child4, Child5, Child6, Child7
+
+
+class ManagersRegressionTests(TestCase):
+def test_managers(self):
+a1 = Child1.objects.create(name='fred', data='a1')
+a2 = Child1.objects.create(name='barney', data='a2')
+b1 = Child2.objects.create(name='fred', data='b1', value=1)
+b2 = Child2.objects.create(name='barney', data='b2', value=42)
+c1 = Child3.objects.create(name='fred', data='c1', comment='yes')
+c2 = Child3.objects.create(name='barney', data='c2', comment='no')
+d1 = Child4.objects.create(name='fred', data='d1')
+d2 = Child4.objects.create(name='barney', data='d2')
+e1 = Child5.objects.create(name='fred', comment='yes')
+e2 = Child5.objects.create(name='barney', comment='no')
+f1 = Child6.objects.create(name='fred', data='f1', value=42)
+f2 = Child6.objects.create(name='barney', data='f2', value=42)
+g1 = Child7.objects.create(name='fred')
+g2 = Child7.objects.create(name='barney')
+
+self.assertQuerysetEqual(Child1.manager1.all(), [""])
+self.assertQuerysetEqual(Child1.manager2.all(), [""])
+self.assertQuerysetEqual(Child1._default_manager.all(), [""])
+
+self.assertQuerysetEqual(Child2._default_manager.all(), [""])
+self.assertQuerysetEqual(Child2.restricted.all(), [""])
+
+self.assertQuerysetEqual(Child3._default_manager.all(), [""])
+self.assertQuerysetEqual(Child3.manager1.all(), [""])
+self.assertQuerysetEqual(Child3.manager2.all(), [""])
+
+# Since Child6 inherits from Child4, the corresponding rows from f1 and
+# f2 also appear here. This is the expected result.
+self.assertQuerysetEqual(Child4._default_manager.order_by('data'), [
+"",
+"",
+"",
+""
+]
+)
+self.assertQuerysetEqual(Child4.manager1.all(), [
+"",
+""
+]
+)
+self.assertQuerysetEqual(Child5._default_manager.all(), [""])
+self.assertQuerysetEqual(Child6._default_manager.all(), [""])
+self.assertQuerysetEqual

[Changeset] r14206 - django/branches/releases/1.2.X/tests/regressiontests/m2m_regress

[noreply]

Author: Alex
Date: 2010-10-13 20:11:22 -0500 (Wed, 13 Oct 2010)
New Revision: 14206

Added:
   django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/tests.py
Modified:
   django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/models.py
Log:
[1.2.X] Fixed #14458 -- converted m2m_regress tests from doctests to unittests. 
 We have always been at war with doctests.  Thanks to Gabriel Hurley for the 
patch.  Backport of [14205].

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/models.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/models.py  
2010-10-14 01:10:57 UTC (rev 14205)
+++ django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/models.py  
2010-10-14 01:11:22 UTC (rev 14206)
@@ -56,70 +56,3 @@
 class User(models.Model):
 name = models.CharField(max_length=30)
 friends = models.ManyToManyField(auth.User)
-
-__test__ = {"regressions": """
-# Multiple m2m references to the same model or a different model must be
-# distinguished when accessing the relations through an instance attribute.
-
->>> s1 = SelfRefer.objects.create(name='s1')
->>> s2 = SelfRefer.objects.create(name='s2')
->>> s3 = SelfRefer.objects.create(name='s3')
->>> s1.references.add(s2)
->>> s1.related.add(s3)
-
->>> e1 = Entry.objects.create(name='e1')
->>> t1 = Tag.objects.create(name='t1')
->>> t2 = Tag.objects.create(name='t2')
->>> e1.topics.add(t1)
->>> e1.related.add(t2)
-
->>> s1.references.all()
-[]
->>> s1.related.all()
-[]
-
->>> e1.topics.all()
-[]
->>> e1.related.all()
-[]
-
-# The secret internal related names for self-referential many-to-many fields
-# shouldn't appear in the list when an error is made.
->>> SelfRefer.objects.filter(porcupine='fred')
-Traceback (most recent call last):
-...
-FieldError: Cannot resolve keyword 'porcupine' into field. Choices are: id, 
name, references, related, selfreferchild, selfreferchildsibling
-
-# Test to ensure that the relationship between two inherited models
-# with a self-referential m2m field maintains symmetry
->>> sr_child = SelfReferChild(name="Hanna")
->>> sr_child.save()
-
->>> sr_sibling = SelfReferChildSibling(name="Beth")
->>> sr_sibling.save()
->>> sr_child.related.add(sr_sibling)
->>> sr_child.related.all()
-[]
->>> sr_sibling.related.all()
-[]
-
-# Regression for #11311 - The primary key for models in a m2m relation
-# doesn't have to be an AutoField
->>> w = Worksheet(id='abc')
->>> w.save()
->>> w.delete()
-
-# Regression for #11956 -- You can add an object to a m2m with the
-# base class without causing integrity errors
->>> c1 = TagCollection.objects.create(name='c1')
->>> c1.tags = [t1,t2]
-
->>> c1 = TagCollection.objects.get(name='c1')
->>> c1.tags.all()
-[, ]
-
->>> t1.tag_collections.all()
-[]
-
-"""
-}

Added: django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/tests.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/tests.py   
(rev 0)
+++ django/branches/releases/1.2.X/tests/regressiontests/m2m_regress/tests.py   
2010-10-14 01:11:22 UTC (rev 14206)
@@ -0,0 +1,75 @@
+from django.core.exceptions import FieldError
+from django.test import TestCase
+
+from models import (SelfRefer, Tag, TagCollection, Entry, SelfReferChild,
+SelfReferChildSibling, Worksheet)
+
+
+class M2MRegressionTests(TestCase):
+def test_multiple_m2m(self):
+# Multiple m2m references to model must be distinguished when
+# accessing the relations through an instance attribute.
+
+s1 = SelfRefer.objects.create(name='s1')
+s2 = SelfRefer.objects.create(name='s2')
+s3 = SelfRefer.objects.create(name='s3')
+s1.references.add(s2)
+s1.related.add(s3)
+
+e1 = Entry.objects.create(name='e1')
+t1 = Tag.objects.create(name='t1')
+t2 = Tag.objects.create(name='t2')
+
+e1.topics.add(t1)
+e1.related.add(t2)
+
+self.assertQuerysetEqual(s1.references.all(), [""])
+self.assertQuerysetEqual(s1.related.all(), [""])
+
+self.assertQuerysetEqual(e1.topics.all(), [""])
+self.assertQuerysetEqual(e1.related.all(), [""])
+
+def test_internal_related_name_not_in_error_msg(self):
+# The secret internal related names for self-referential many-to-many
+# fields shouldn't appear in the list when an error is made.
+
+self.assertRaisesRegexp(FieldError,
+"Choices are: id, name, references, related, selfreferchild, 
selfreferchildsibling$",
+lambda: SelfRefer.objects.filter(porcupine='fred')
+)
+
+def test_m2m_inheritance_symmetry(self):
+# Test to ensure that the relationship between two inherited models
+# with a self-referential m2m field maintains symmetry
+
+sr_child = SelfReferChild(name="Hanna")
+sr_child.save(

[Changeset] r14205 - django/trunk/tests/regressiontests/m2m_regress

[noreply]

Author: Alex
Date: 2010-10-13 20:10:57 -0500 (Wed, 13 Oct 2010)
New Revision: 14205

Added:
   django/trunk/tests/regressiontests/m2m_regress/tests.py
Modified:
   django/trunk/tests/regressiontests/m2m_regress/models.py
Log:
Fixed #14458 -- converted m2m_regress tests from doctests to unittests.  We 
have always been at war with doctests.  Thanks to Gabriel Hurley for the patch.

Modified: django/trunk/tests/regressiontests/m2m_regress/models.py
===
--- django/trunk/tests/regressiontests/m2m_regress/models.py2010-10-13 
23:36:16 UTC (rev 14204)
+++ django/trunk/tests/regressiontests/m2m_regress/models.py2010-10-14 
01:10:57 UTC (rev 14205)
@@ -56,70 +56,3 @@
 class User(models.Model):
 name = models.CharField(max_length=30)
 friends = models.ManyToManyField(auth.User)
-
-__test__ = {"regressions": """
-# Multiple m2m references to the same model or a different model must be
-# distinguished when accessing the relations through an instance attribute.
-
->>> s1 = SelfRefer.objects.create(name='s1')
->>> s2 = SelfRefer.objects.create(name='s2')
->>> s3 = SelfRefer.objects.create(name='s3')
->>> s1.references.add(s2)
->>> s1.related.add(s3)
-
->>> e1 = Entry.objects.create(name='e1')
->>> t1 = Tag.objects.create(name='t1')
->>> t2 = Tag.objects.create(name='t2')
->>> e1.topics.add(t1)
->>> e1.related.add(t2)
-
->>> s1.references.all()
-[]
->>> s1.related.all()
-[]
-
->>> e1.topics.all()
-[]
->>> e1.related.all()
-[]
-
-# The secret internal related names for self-referential many-to-many fields
-# shouldn't appear in the list when an error is made.
->>> SelfRefer.objects.filter(porcupine='fred')
-Traceback (most recent call last):
-...
-FieldError: Cannot resolve keyword 'porcupine' into field. Choices are: id, 
name, references, related, selfreferchild, selfreferchildsibling
-
-# Test to ensure that the relationship between two inherited models
-# with a self-referential m2m field maintains symmetry
->>> sr_child = SelfReferChild(name="Hanna")
->>> sr_child.save()
-
->>> sr_sibling = SelfReferChildSibling(name="Beth")
->>> sr_sibling.save()
->>> sr_child.related.add(sr_sibling)
->>> sr_child.related.all()
-[]
->>> sr_sibling.related.all()
-[]
-
-# Regression for #11311 - The primary key for models in a m2m relation
-# doesn't have to be an AutoField
->>> w = Worksheet(id='abc')
->>> w.save()
->>> w.delete()
-
-# Regression for #11956 -- You can add an object to a m2m with the
-# base class without causing integrity errors
->>> c1 = TagCollection.objects.create(name='c1')
->>> c1.tags = [t1,t2]
-
->>> c1 = TagCollection.objects.get(name='c1')
->>> c1.tags.all()
-[, ]
-
->>> t1.tag_collections.all()
-[]
-
-"""
-}

Added: django/trunk/tests/regressiontests/m2m_regress/tests.py
===
--- django/trunk/tests/regressiontests/m2m_regress/tests.py 
(rev 0)
+++ django/trunk/tests/regressiontests/m2m_regress/tests.py 2010-10-14 
01:10:57 UTC (rev 14205)
@@ -0,0 +1,75 @@
+from django.core.exceptions import FieldError
+from django.test import TestCase
+
+from models import (SelfRefer, Tag, TagCollection, Entry, SelfReferChild,
+SelfReferChildSibling, Worksheet)
+
+
+class M2MRegressionTests(TestCase):
+def test_multiple_m2m(self):
+# Multiple m2m references to model must be distinguished when
+# accessing the relations through an instance attribute.
+
+s1 = SelfRefer.objects.create(name='s1')
+s2 = SelfRefer.objects.create(name='s2')
+s3 = SelfRefer.objects.create(name='s3')
+s1.references.add(s2)
+s1.related.add(s3)
+
+e1 = Entry.objects.create(name='e1')
+t1 = Tag.objects.create(name='t1')
+t2 = Tag.objects.create(name='t2')
+
+e1.topics.add(t1)
+e1.related.add(t2)
+
+self.assertQuerysetEqual(s1.references.all(), [""])
+self.assertQuerysetEqual(s1.related.all(), [""])
+
+self.assertQuerysetEqual(e1.topics.all(), [""])
+self.assertQuerysetEqual(e1.related.all(), [""])
+
+def test_internal_related_name_not_in_error_msg(self):
+# The secret internal related names for self-referential many-to-many
+# fields shouldn't appear in the list when an error is made.
+
+self.assertRaisesRegexp(FieldError,
+"Choices are: id, name, references, related, selfreferchild, 
selfreferchildsibling$",
+lambda: SelfRefer.objects.filter(porcupine='fred')
+)
+
+def test_m2m_inheritance_symmetry(self):
+# Test to ensure that the relationship between two inherited models
+# with a self-referential m2m field maintains symmetry
+
+sr_child = SelfReferChild(name="Hanna")
+sr_child.save()
+
+sr_sibling = SelfReferChildSibling(name="Beth")
+sr_sibling.save()
+sr_child.related.add(sr_sibling)
+
+self.assertQuerysetEqual(sr

Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  brunobraga
Status:  assigned  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by brunobraga):

 Additionally, the newest django 1.2.3 (which has been put to the official
 Ubuntu repository 10.10) requires modification in the patch in order to
 work properly. As soon as we receive a positive message from committers,
 we can work on updating it to add to the main stream code.

 Thank you,

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  brunobraga
Status:  assigned  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by brunobraga):

 * cc: ftmo (added)

Comment:

 We have worked with [ftmo] to update previous patches according to newest
 releases, but I see it is pointless to keep doing that every time...
 Instead, we should push this to the main stream, but I don't know what
 still needs to be done for it to be properly accepted.

 I would like to flag this for review by the committers (forward to "ready
 for checkin"), and if there is anything missing, let us know, so we can
 work on it and finalize this.

 For reference, we are using the latest 1.2.0 patch in production
 environment for almost 6 months now, without any problems.

 Thanks in advance,

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  brunobraga
Status:  assigned  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by brunobraga):

  * owner:  anonymous => brunobraga
  * status:  new => assigned

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14464: Docs should advise people to use the docs for their version

[Django]

#14464: Docs should advise people to use the docs for their version
---+
 Reporter:  PaulM  |   Owner:  gabrielhurley
   Status:  new|   Milestone:  1.3  
Component:  Documentation  | Version:  1.2  
 Keywords: |   Stage:  Unreviewed   
Has_patch:  0  |  
---+
 http://docs.djangoproject.com/en/dev/intro/install/

 At the end, it warns people about using the dev docs against a stable
 release. We should keep this warning (at least in the dev copy of the
 docs) but should probably more forcefully direct people to the correct
 version of the docs. We link to the stable docs by default on the site, so
 we should include a link to them from there if people happen to be viewing
 the dev docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14204 - in django/trunk: django/db/backends/oracle django/db/models/sql tests/regressiontests/queries

[noreply]

Author: ramiro
Date: 2010-10-13 18:36:16 -0500 (Wed, 13 Oct 2010)
New Revision: 14204

Modified:
   django/trunk/django/db/backends/oracle/compiler.py
   django/trunk/django/db/models/sql/compiler.py
   django/trunk/tests/regressiontests/queries/tests.py
Log:
Fixed #12192 -- Don't execute any DB query when the QS slicing being performed
will result in use of LIMIT 0. Thanks Suor for the report.

Modified: django/trunk/django/db/backends/oracle/compiler.py
===
--- django/trunk/django/db/backends/oracle/compiler.py  2010-10-13 12:07:27 UTC 
(rev 14203)
+++ django/trunk/django/db/backends/oracle/compiler.py  2010-10-13 23:36:16 UTC 
(rev 14204)
@@ -27,6 +27,8 @@
 If 'with_limits' is False, any limit/offset information is not
 included in the query.
 """
+if with_limits and self.query.low_mark == self.query.high_mark:
+return '', ()
 
 # The `do_offset` flag indicates whether we need to construct
 # the SQL needed to use limit/offset with Oracle.

Modified: django/trunk/django/db/models/sql/compiler.py
===
--- django/trunk/django/db/models/sql/compiler.py   2010-10-13 12:07:27 UTC 
(rev 14203)
+++ django/trunk/django/db/models/sql/compiler.py   2010-10-13 23:36:16 UTC 
(rev 14204)
@@ -52,6 +52,9 @@
 If 'with_limits' is False, any limit/offset information is not included
 in the query.
 """
+if with_limits and self.query.low_mark == self.query.high_mark:
+return '', ()
+
 self.pre_sql_setup()
 out_cols = self.get_columns(with_col_aliases)
 ordering, ordering_group_by = self.get_ordering()

Modified: django/trunk/tests/regressiontests/queries/tests.py
===
--- django/trunk/tests/regressiontests/queries/tests.py 2010-10-13 12:07:27 UTC 
(rev 14203)
+++ django/trunk/tests/regressiontests/queries/tests.py 2010-10-13 23:36:16 UTC 
(rev 14204)
@@ -86,8 +86,18 @@
 def test_emptyqueryset_values(self):
 "#14366 -- calling .values() on an EmptyQuerySet and then cloning that 
should not cause an error"
 
self.assertEqual(list(Number.objects.none().values('num').order_by('num')), [])
-
+
 def test_values_subquery(self):
 self.assertQuerysetEqual(
 Number.objects.filter(pk__in=Number.objects.none().values("pk")), 
[]
 )
+
+
+class WeirdQuerySetSlicing(TestCase):
+def setUp(self):
+Number.objects.create(num=1)
+Number.objects.create(num=2)
+
+def test_empty_resultset_sql(self):
+# ticket #12192
+self.assertNumQueries(0, lambda: list(Number.objects.all()[1:1]))

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14463: "See allowed date format strings" Is not linked

[Django]

#14463: "See allowed date format strings" Is not linked
+---
  Reporter:  epicserve  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14463: "See allowed date format strings" Is not linked

[Django]

#14463: "See allowed date format strings" Is not linked
---+
 Reporter:  epicserve  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 On the settings page, http://docs.djangoproject.com/en/dev/ref/settings/,
 all instances where the phrase, "allowed date format strings" appear are
 not linked to
 http://docs.djangoproject.com/en/1.2/ref/templates/builtins/#date like
 they should be.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12789: ConditionalGetMiddleware behavior improvement.

[Django]

#12789: ConditionalGetMiddleware behavior improvement.
---+
  Reporter:  penzoil   | Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  Cache system  |   Version:  SVN
   
Resolution:|  Keywords:  ETag, 
ConditionalGetMiddleware, patch_response_headers
 Stage:  Unreviewed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  1  
   
Needs_better_patch:  0 |  
---+
Changes (by Honza_Kral):

  * needs_tests:  0 => 1

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14082: modelform_factory should use the form's metaclass

[Django]

#14082: modelform_factory should use the form's metaclass
---+
  Reporter:  jspiros   | Owner:  Honza_Kral 
 
Status:  assigned  | Milestone: 
 
 Component:  Forms |   Version:  SVN
 
Resolution:|  Keywords:  ModelForm, ModelFormMetaclass, 
modelform_factory
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by Honza_Kral):

  * owner:  nobody => Honza_Kral
  * status:  new => assigned
  * stage:  Unreviewed => Accepted

Comment:

 We still need some tests to verify the fix, but the issue is valid

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14379: formset.is_bound returns False for ModelFormsets created with queryset as argument

[Django]

#14379: formset.is_bound returns False for ModelFormsets created with queryset 
as
argument
-+--
  Reporter:  jnns| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  invalid |  Keywords:  modelformset bound
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Honza_Kral):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This is correct behavior - instantiating {{{ ModelFormSet }}} with a
 queryset is the equivalent of supplying {{{ initial }}} to a {{{ Form }}}
 which also isn't bound in that case.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14461: Allow to use other translation languages than just the ones available in Django

[Django]

#14461: Allow to use other translation languages than just the ones available in
Django
---+
  Reporter:  diegobz   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Internationalization  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * status:  closed => reopened
  * resolution:  wontfix =>

Comment:

 After further discussion with Jannis on IRC, actually this could be an old
 restriction that might be worth reviewing and possibly removing provided
 no existing behavior is affected and all the necessary pieces of the user
 locale language preferences selection are modified accordingly so the
 translations added using this mechanism are effectively made available.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14462: Aggregates default to the database type instead of the field type

[Django]

#14462: Aggregates default to the database type instead of the field type
---+
 Reporter:  WoLpH  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Database layer (models, ORM)   | Version:  1.2   
 Keywords:  aggregate, annotate, type, coerce  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 First a little background information, I've got a couple of custom field
 types which get cast right after loading the model.
 So instead of a Decimal I get a Euro object with added features like
 formatting and stuff like that.

 However, it seems that the aggregate/annotate queries in Django do not
 respect the `to_python()` method but simply cast to the type specified by
 the database backend.
 This can easily be fixed by modifying `convert_values()` so it returns
 this:
 {{{
 #!python
 return field.to_python(connection.ops.convert_values(value, field))
 }}}

 instead of
 {{{
 #!python
 return connection.ops.convert_values(value, field)
 }}}

 The `convert_values()` function:
 
http://code.djangoproject.com/browser/django/trunk/django/db/models/sql/query.py#L298


 Would this be the proper location to fix this? Either way, it has to be a
 bug that the `max()` of a value returns a different type.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14461: Allow to use other translation languages than just the ones available in Django

[Django]

#14461: Allow to use other translation languages than just the ones available in
Django
---+
  Reporter:  diegobz   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Internationalization  |   Version:  1.2   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 I know this is a design decision, and has been like this for a long time.
 This ticket certainly made me ask myself what would be the reason for such
 a decision. Fortunately the answer is in the docs:
 http://docs.djangoproject.com/en/1.2/topics/i18n/localization/#how-to-
 create-language-files (''Locale restrictions'' box).

 I will close the ticket for now. Were a patch like this to be accepted it
 would need to update the documentation and add tests. Also, it seems to me
 it need to deal with updating the LANGUAGES setting esomehow because
 adding the translation path to the path search list isn't enough.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14461: Allow to use other translation languages than just the ones available in Django

[Django]

#14461: Allow to use other translation languages than just the ones available in
Django
---+
  Reporter:  diegobz   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by diegobz):

  * needs_better_patch:  => 0
  * summary:  Accept to use more languages than just the ones available in
  Django => Allow to use other translation
  languages than just the ones available in
  Django
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10936: Detailed instructions for getting Django and MySQL and MySQLdb working on various OS X versions

[Django]

#10936: Detailed instructions for getting Django and MySQL and MySQLdb working 
on
various OS X versions
+---
  Reporter:  simon  | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  mysqldb
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * stage:  Design decision needed => Accepted

Comment:

 After reading the various comments and doing a bit of discussion, I've got
 three actionable recommendations here:

  1. Add a note to the quick install docs and the topics/installation docs
 that notes something along these lines: "It is a very common practice to
 use sqlite3 in a desktop development environment. Unless you need database
 feature-parity between your desktop development environment and your
 deployment environment, using sqlite3 for development is generally a much
 simpler option."

  2. Add a link to the [http://code.djangoproject.com/wiki/Distributions
 Distributions wiki page] from the installation docs that says something
 like "Further installation guides may be available on the Distributions
 page in the wiki."

  3. Add any relevant information regarding Django/MySQL installation and
 setup on Mac OS X (as requested by this ticket) to the wiki.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14461: Accept to use more languages than just the ones available in Django

[Django]

#14461: Accept to use more languages than just the ones available in Django
--+-
 Reporter:  diegobz   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Internationalization  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Django doen't allow to activate a language available in a project, but
 that it is not present in the django/conf/locale/.

 I've noticed it's because of the
 
[http://code.djangoproject.com/browser/django/trunk/django/utils/translation/trans_real.py?rev=14138#L316
 check_for_language] function.

 Not sure if it's the best way to fix it, but I'm providing a patch that
 can resolve the issue.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10464: Django Lighttpd Deployment Addition

[Django]

#10464: Django Lighttpd Deployment Addition
+---
  Reporter:  dgt84  | Owner:  gabrielhurley
Status:  assigned   | Milestone:   
 Component:  Documentation  |   Version:  1.0  
Resolution: |  Keywords:  deployment   
 Stage:  Accepted   | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * owner:  nobody => gabrielhurley
  * status:  new => assigned
  * stage:  Design decision needed => Accepted

Comment:

 I'll incorporate this into an overall lighttpd deployment review/overhaul.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11273: Tutorial - Part 2 should note the first appearance of curly brackets

[Django]

#11273: Tutorial - Part 2 should note the first appearance of curly brackets
-+--
  Reporter:  thiggins| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Documentation   |   Version:  1.0   
Resolution:  wontfix |  Keywords:  curly brackets
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by gabrielhurley):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 The first appearance of the curly brackets is their use in some `dict`s
 during the admin setup examples. I'm assuming the ticket was actually more
 interested in where they're first used regarding templates, however.

 The first time they're used/mentioned is the line "This template file
 contains lots of text like `{% block branding %}` and `{{ title }}`." I
 think that calls attention to them pretty adequately. It specifically
 points out this syntax as something you should notice.

 Moreover, if you mistake a curly bracket for a parenthesis in a template,
 you're going to know you've made a mistake pretty much immediately. And if
 you're copying and pasting code (as many people do with the tutorial),
 then you should be able to distinguish the curly bracket in your text-
 editor of choice.

 Thereby, I'm going to close this one wontfix. Thank you to thiggins for
 the suggestion, however.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14460: Convert managers_regress doctests to unit tests

[Django]

#14460: Convert managers_regress doctests to unit tests
+---
  Reporter:  gabrielhurley  | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.3  
 Component:  Testing framework  |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14460: Convert managers_regress doctests to unit tests

[Django]

#14460: Convert managers_regress doctests to unit tests
---+
 Reporter:  gabrielhurley  |   Owner:  gabrielhurley
   Status:  new|   Milestone:  1.3  
Component:  Testing framework  | Version:  1.2  
 Keywords: |   Stage:  Unreviewed   
Has_patch:  1  |  
---+
 Patch attached

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14459: Convert many_to_one_regress test to unit tests

[Django]

#14459: Convert many_to_one_regress test to unit tests
+---
  Reporter:  gabrielhurley  | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.3  
 Component:  Testing framework  |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14459: Convert many_to_one_regress test to unit tests

[Django]

#14459: Convert many_to_one_regress test to unit tests
---+
 Reporter:  gabrielhurley  |   Owner:  gabrielhurley
   Status:  new|   Milestone:  1.3  
Component:  Testing framework  | Version:  1.2  
 Keywords: |   Stage:  Unreviewed   
Has_patch:  1  |  
---+
 Patch attached

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14458: Convert m2m_regress doctests to unit tests

[Django]

#14458: Convert m2m_regress doctests to unit tests
+---
  Reporter:  gabrielhurley  | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.3  
 Component:  Testing framework  |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14458: Convert m2m_regress doctests to unit tests

[Django]

#14458: Convert m2m_regress doctests to unit tests
---+
 Reporter:  gabrielhurley  |   Owner:  gabrielhurley
   Status:  new|   Milestone:  1.3  
Component:  Testing framework  | Version:  1.2  
 Keywords: |   Stage:  Unreviewed   
Has_patch:  1  |  
---+
 Patch attached.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14390: set_password functionality outside of the User model

[Django]

#14390: set_password functionality outside of the User model
--+-
  Reporter:  k...@lysator.liu.se  | Owner:  lrekucki
Status:  new  | Milestone:  
 Component:  Authentication   |   Version:  1.2 
Resolution:   |  Keywords:  
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by subsume):

  * owner:  subsume => lrekucki
  * status:  assigned => new

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14390: set_password functionality outside of the User model

[Django]

#14390: set_password functionality outside of the User model
--+-
  Reporter:  k...@lysator.liu.se  | Owner:  subsume
Status:  assigned | Milestone: 
 Component:  Authentication   |   Version:  1.2
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by subsume):

  * owner:  lrekucki => subsume
  * status:  new => assigned
  * has_patch:  0 => 1

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14126: blocktrans count is parsing incorrectly

[Django]

#14126: blocktrans count is parsing incorrectly
-+--
  Reporter:  mark0978| Owner:  ramiro   
Status:  new | Milestone:   
 Component:  Translations|   Version:  1.2  
Resolution:  |  Keywords:  blocktrans plural
 Stage:  Design decision needed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by svetlyak40wt):

 @ramiro, you was right, translation is correct. Please, look at the new
 patch which fixes blocktrans' code.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13933: add ModelBackend inheritence to custom auth backend doc to enable Permissions

[Django]

#13933: add ModelBackend inheritence to custom auth backend doc to enable
Permissions
+---
  Reporter:  mbg| Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * stage:  Design decision needed => Accepted

Comment:

 Amusingly, I agree with both Ramiro '''and''' with the reporter (mbg). The
 current docs cover the intended usage and duck-typing strategy very well,
 as they should.

 However, I don't think it serves the greater good to simply omit
 `ModelBackend` from that section of the docs. Adding a few sentences
 describing how Django uses `ModelBackend` should be enough to point people
 in the right direction should they want to go that route without
 explicitly recommending it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10093: Table of Contents should show two levels

[Django]

#10093: Table of Contents should show two levels
-+--
  Reporter:  adrian_nye  | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Documentation   |   Version:  1.0  
Resolution:  wontfix |  Keywords:  Table of contents
 Stage:  Design decision needed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by gabrielhurley):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 For the sake of comparison I just tried building the docs with the TOC
 `:maxdepth:` value increased to show the added level.

 Quite honestly, it made the page excessively long (nearly 10 printed
 pages) and made it much harder to actually find what you were looking for
 without doing a `find` command on the page.

 It also ruined what I consider to be one of the best features of the TOC:
 it shows you the organization of the docs at a glance.

 While it may be the standard for printed technical manuals, I feel this
 change would be detrimental to the overall usability of the TOC page.

 Thank you for the suggestion, though. It was an interesting experiment.
 I'm sorry no one dealt with this previously!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9353: Django documentation bundles on download page

[Django]

#9353: Django documentation bundles on download page
-+--
  Reporter:  Tome   | Owner:  nobody  
Status:  new | Milestone:  
 Component:  Django Web site |   Version:  SVN 
Resolution:  |  Keywords:  download
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by gabrielhurley):

  * component:  Documentation => Django Web site

Comment:

 This is an issue about the website itself, not about the docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8711: Add documentation about deploying Django under SCGI and AJP

[Django]

#8711: Add documentation about deploying Django under SCGI and AJP
+---
  Reporter:  vizualbod  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution:  wontfix|  Keywords:  deployment
 Stage:  Someday/Maybe  | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 It suddenly strikes me that requesting a guide for a specific deployment
 strategy is much like requesting a translation, and Jacob's answer would
 be every bit as true if he were talking about the local dialect rather
 than server technologies.

 Thereby it seems reasonable to hold a similar policy: tickets should be
 opened when a deployment guide is provided, not when one is requested (see
 Russ' succinct answer on #13286).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7968: ImageField/FileField behaviour on ModelForms

[Django]

#7968: ImageField/FileField behaviour on ModelForms
+---
  Reporter:  sime   | Owner:  gabrielhurley
Status:  assigned   | Milestone:   
 Component:  Documentation  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  1  |  
+---
Changes (by gabrielhurley):

  * owner:  nobody => gabrielhurley
  * needs_better_patch:  0 => 1
  * status:  new => assigned
  * stage:  Design decision needed => Accepted

Comment:

 Adding a note about this in the documentation is fine. Adding a
 `remove_image` field to `ModelForm` is a completely different issue and
 should be its own ticket, so I'm disregarding that comment.

 The patch language needs a little work, but I'll have to think on the
 right direction for improvement. I'll add this ticket to my list to finish
 off.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7808: Form Preview does not work with file uploads

[Django]

#7808: Form Preview does not work with file uploads
+---
  Reporter:  ian_brasil | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * stage:  Design decision needed => Accepted

Old description:

> There seems to be no way to bind a form to a Form Preview (using
> request.FILES)...
> i tried ignoring the specific warning not to override in preview.py and
> tried to override the preview_post() method but this did not work.
>
> Additionally this is '''not''' documented on
> [http://www.djangoproject.com/documentation/form_preview]

New description:

 There seems to be no way to bind a form to a Form Preview (using
 request.FILES)...
 i tried ignoring the specific warning not to override in preview.py and
 tried to override the preview_post() method but this did not work.

 Additionally this is '''not''' documented on
 [http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-preview/]

Comment:

 My this is an old ticket. I had to update the link to the docs in the
 ticket description, it was that old.

 Anyhow, It seems like a reasonable admonition to add to the Form Preview
 docs as suggested by anonymous.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14203 - django/trunk/docs/releases

[noreply]

Author: russellm
Date: 2010-10-13 07:07:27 -0500 (Wed, 13 Oct 2010)
New Revision: 14203

Modified:
   django/trunk/docs/releases/1.3.txt
Log:
Added a skeleton for 'little features' in the 1.3 release notes.

Modified: django/trunk/docs/releases/1.3.txt
===
--- django/trunk/docs/releases/1.3.txt  2010-10-13 11:29:18 UTC (rev 14202)
+++ django/trunk/docs/releases/1.3.txt  2010-10-13 12:07:27 UTC (rev 14203)
@@ -56,6 +56,29 @@
 
 .. _unittest2: http://pypi.python.org/pypi/unittest2
 
+Everything else
+~~~
+
+Django :doc:`1.1 <1.1>` and :doc:`1.2 <1.2>` added
+lots of big ticket items to Django, like multiple-database support,
+model validation, and a session-based messages framework. However,
+this focus on big features came at the cost of lots of smaller
+features.
+
+To compensate for this, the focus of the Django 1.3 development
+process has been on adding lots of smaller, long standing feature
+requests. These include:
+
+* Improved tools for accessing and manipulating the current Site.
+
+* A :class:`~django.test.client.RequestFactory` for mocking
+  requests in tests.
+
+* A new test assertion --
+  :meth:`~django.test.client.Client.assertNumQueries` -- making it
+  easier to test the database activity associated with a view.
+
+
 .. _backwards-incompatible-changes-1.3:
 
 Backwards-incompatible changes in 1.3

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13586: Improvements in Signals.m2m_changed documentation

[Django]

#13586: Improvements in Signals.m2m_changed documentation
+---
  Reporter:  david  | Owner:  nobody 
Status:  reopened   | Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  signals
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_docs:  1 => 0
  * stage:  Unreviewed => Accepted
  * milestone:  1.3 =>

Comment:

 An improved example certainly couldn't hurt. Perhaps adding some more
 obvious language about `through` is possible (I'd have to see a patch).

 However, most of what jonathanmorgan suggests is covered elsewhere in the
 signals documentation (sender being the class you wish to receive signals
 from), or is inherent in Python (re: importing or defining the model you
 wish to reference). The last two items may be valid (I haven't looked for
 existing docs for either), but they're separate issues and don't belong in
 this ticket. If you want to open separate tickets for them you may.

 I'll mark the ticket as accepted but strike the milestone until someone
 provides a patch that offers concrete improvement.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13909: Info on using "bare" json module in "Serializing Django Objects"

[Django]

#13909: Info on using "bare" json module in "Serializing Django Objects"
--+-
  Reporter:  JonathanHayward  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Documentation|   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * summary:  [Enhancement] Cross-reference to "bare" json module suggested
  for "Serializing Django Objects" => Info on
  using "bare" json module in "Serializing Django
  Objects"
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

Old description:

> http://docs.djangoproject.com/en/dev/topics/serialization/ covers how to
> serialize certain data, namely QuerySets and other model-based data, but
> it does not appear to contain or cross-reference how one would use the
> "bare" json module and json.dumps (not
> serializers.get_serializer('json')()-created objects) to serialize a
> basic concoction of one or more strings, numbers, hashes, and lists.
>
> In terms of "information scent", the page is a natural search result for
> [http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=django+serialization
> django serialization] which people could find if they are looking how to
> serialize JSON-like data for Ajax use. Ideally that page should cross-
> reference, or possibly contain, how to do basic serialization to JSON for
> constructions from strings/numbers/hashes/lists, particularly as what you
> get from serializers.get_serializer('json')() has an allergic response to
> being asked to serialize non-iterable data.
>
> Jonathan
> http://JonathansCorner.com/

New description:

 http://docs.djangoproject.com/en/dev/topics/serialization/ covers how to
 serialize certain data, namely QuerySets and other model-based data, but
 it does not appear to contain or cross-reference how one would use the
 "bare" json module and json.dumps (not
 serializers.get_serializer('json')()-created objects) to serialize a basic
 concoction of one or more strings, numbers, hashes, and lists.

 In terms of "information scent", the page is a natural search result for
 [http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=django+serialization
 django serialization] which people could find if they are looking how to
 serialize JSON-like data for Ajax use. Ideally that page should cross-
 reference, or possibly contain, how to do basic serialization to JSON for
 constructions from strings/numbers/hashes/lists, particularly as what you
 get from serializers.get_serializer('json')() has an allergic response to
 being asked to serialize non-iterable data.

Comment:

 A brief explanation and an example would be helpful, since this is a
 natural place for people to look for this type of information.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14241: instructions for creating spatial database template differ on fedora 13 (64 bit)

[Django]

#14241: instructions for creating spatial database template differ on fedora 13 
(64
bit)
+---
  Reporter:  josdekloe  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 It seems like the most useful thing here would be to distill out the core
 of what's *different* about the process for Fedora 13 64-bit and explain
 that rather than simply pasting a separate script.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14009: custom formset validation documentation is incomplete

[Django]

#14009: custom formset validation documentation is incomplete
-+--
  Reporter:  splatEric   | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Documentation   |   Version:  1.2  
 
Resolution:  |  Keywords:  formset 
validation
 Stage:  Accepted| Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * has_patch:  1 => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Accepted. For future reference, the file in question is
 `docs/topics/forms/formsets/`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13949: readonly fields can't be modified via cleaned_data in forms

[Django]

#13949: readonly fields can't be modified via cleaned_data in forms
+---
  Reporter:  alk| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> if you make a model with a readonly fields, the value of that field can't
> be set in a clean() validator in that model's form - this isn't mentioned
> in the documentation anywhere as far as I can see, should be added I
> think

New description:

 if you make a model with readonly fields, the value of that field can't be
 set in a clean() validator in that model's form - this isn't mentioned in
 the documentation anywhere as far as I can see, should be added I think

Comment:

 It's true that the data for read-only fields are not available in
 cleaned_data. This is because read-only fields are displayed as text
 rather than as input elements, and thus are not posted back to the server,
 and so are not in the data that gets cleaned.

 Mentioning this fact couldn't hurt.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14202 - django/trunk/docs/topics

[noreply]

Author: gabrielhurley
Date: 2010-10-13 06:29:18 -0500 (Wed, 13 Oct 2010)
New Revision: 14202

Modified:
   django/trunk/docs/topics/testing.txt
Log:
Correcting a typo and a copy/paste problem in the RequestFactory docs from 
[14192].

Modified: django/trunk/docs/topics/testing.txt
===
--- django/trunk/docs/topics/testing.txt2010-10-13 07:02:43 UTC (rev 
14201)
+++ django/trunk/docs/topics/testing.txt2010-10-13 11:29:18 UTC (rev 
14202)
@@ -1050,11 +1050,11 @@
 
 class SimpleTest(unittest.TestCase):
 def setUp(self):
-# Every test needs a client.
+# Every test needs access to the request factory.
 self.factory = RequestFactory()
 
 def test_details(self):
-# Create a in instance of a GET request.
+# Create an instance of a GET request.
 request = self.factory.get('/customer/details')
 
 # Test my_view() as if it were deployed at /customer/details

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14403: Missing/incomplete documentation for FloatField?

[Django]

#14403: Missing/incomplete documentation for FloatField?
--+-
  Reporter:  typeshige   | Owner:  nobody
Status:  closed   | Milestone:  1.3   
 Component:  Documentation|   Version:  1.2   
Resolution:  wontfix  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by gabrielhurley):

  * status:  reopened => closed
  * resolution:  => wontfix

Comment:

 The field classes in that document are listed in alphabetical order rather
 than by type or similarity. This issue has actually come up before though
 I can't find the ticket currently. The core of the decision is that things
 in the Reference section of the docs are meant to be comprehensive
 listings (which should be ordered alphabetically) rather than guided
 overviews (which would be better grouped by topic, and hence are in the
 Topics section).

 While I realize that many people come to the Reference section without
 realizing what they're looking at, without a major reorganization and
 restructuring of the docs, this isn't an issue which will be fixed.

 Ultimately, `DecimalField` and `FloatField` aren't actually that related
 from a Python standpoint. To us mere humans they both store numbers with
 decimal points in them, but to computers they're very different.

 I hope that all makes sense, and thanks for the report!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14457: Possible error in settings.py description

[Django]

#14457: Possible error in settings.py description
+---
  Reporter:  zsoltbot   | Owner:  nobody  
Status:  closed | Milestone:  
 Component:  Documentation  |   Version:  1.2 
Resolution:  invalid|  Keywords:  tutorial
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * status:  new => closed
  * resolution:  => invalid

Old description:

> On this page
> http://docs.djangoproject.com/en/1.2/intro/tutorial01/
>
> I'm pretty sure:
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'polls'
> )
>
> should really be
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'mysite.polls'
> )

New description:

 On this page
 http://docs.djangoproject.com/en/1.2/intro/tutorial01/

 I'm pretty sure:
 {{{
 INSTALLED_APPS = (
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'polls'
 )
 }}}
 should really be
 {{{
 INSTALLED_APPS = (
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'mysite.polls'
 )}}}

Comment:

 As lrekucki said, the removal of "mysite" was intentional; that particular
 instance was removed in #14255, and the rest are set to be removed by
 #14426.

 The bottom line is that the "mysite.myapp" convention is not what we want
 to be encouraging people to do. It goes against the idea of reusable apps,
 and obfuscates the fact that Django apps are truly just Python packages
 and can be imported from anywhere on the PYTHONPATH.

 Thanks for the report though, zsoltbot.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13830: Change one of province name in Indonesian localflavour

[Django]

#13830: Change one of province name in Indonesian localflavour
-+--
  Reporter:  rodin   | Owner:  anonymous
Status:  closed  | Milestone:   
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  fixed   |  Keywords:   
 Stage:  Ready for checkin   | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

  * status:  reopened => closed
  * resolution:  => fixed

Comment:

 Re-closing in favor of #14455.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14455: [patch] Minor regression test fix

[Django]

#14455: [patch] Minor regression test fix
-+--
  Reporter:  kylefox | Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  django.contrib.localflavor  |   Version:  SVN  

Resolution:  |  Keywords:  localflavor, 
regression, test
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 See comment at the end of
 http://code.djangoproject.com/ticket/13830#comment:4. I don't think
 changing the 3-letter code is safe at this point. I think the correct fix
 here is to restore the old 3-letter code and fix the test to recognize the
 new human-readable name only.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13830: Change one of province name in Indonesian localflavour

[Django]

#13830: Change one of province name in Indonesian localflavour
-+--
  Reporter:  rodin   | Owner:  anonymous
Status:  reopened| Milestone:   
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  |  Keywords:   
 Stage:  Ready for checkin   | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 This change has introduced a test failure:

 {{{
 ==
 FAIL: localflavor_id_tests (regressiontests.forms.tests.__test__)
 Doctest: regressiontests.forms.tests.__test__.localflavor_id_tests
 --
 Traceback (most recent call last):
   File "/home/kmtracey/django/trunk/django/test/_doctest.py", line 2180,
 in runTest
 raise self.failureException(self.format_failure(new.getvalue()))
 AssertionError: Failed doctest test for
 regressiontests.forms.tests.__test__.localflavor_id_tests
   File "/home/kmtracey/django/trunk/tests/regressiontests/forms/tests.py",
 line unknown line number, in localflavor_id_tests

 --
 File "/home/kmtracey/django/trunk/tests/regressiontests/forms/tests.py",
 line ?, in regressiontests.forms.tests.__test__.localflavor_id_tests
 Failed example:
 s.render('provinces', 'LPG')
 Expected:
 u'\nBali\nBanten\nBengkulu\nYogyakarta\nJakarta\nGorontalo\nJambi\nJawa
 Barat\nJawa Tengah\nJawa Timur\nKalimantan
 Barat\nKalimantan Selatan\nKalimantan Tengah\nKalimantan
 Timur\nKepulauan Bangka-
 Belitung\nKepulauan Riau\nLampung\nMaluku\nMaluku
 Utara\nNanggroe Aceh
 Darussalam\nNusa Tenggara
 Barat\nNusa Tenggara Timur\nPapua\nPapua
 Barat\nRiau\nSulawesi Barat\nSulawesi
 Selatan\nSulawesi Tengah\nSulawesi Tenggara\nSulawesi
 Utara\nSumatera Barat\nSumatera Selatan\nSumatera
 Utara\n'
 Got:
 u'\nAceh\nBali\nBanten\nBengkulu\nYogyakarta\nJakarta\nGorontalo\nJambi\nJawa
 Barat\nJawa Tengah\nJawa Timur\nKalimantan
 Barat\nKalimantan Selatan\nKalimantan Tengah\nKalimantan
 Timur\nKepulauan Bangka-
 Belitung\nKepulauan Riau\nLampung\nMaluku\nMaluku
 Utara\nNusa Tenggara Barat\nNusa Tenggara Timur\nPapua\nPapua
 Barat\nRiau\nSulawesi Barat\nSulawesi
 Selatan\nSulawesi Tengah\nSulawesi Tenggara\nSulawesi
 Utara\nSumatera Barat\nSumatera Selatan\nSumatera
 Utara\n'

 }}}

 Easy enough to fix, but I don't think we can change the 3-letter code at
 this point -- does that not introduce a problem for anyone who has used
 the old list as the `choices` value for a model field? If they've got the
 old 3-letter value in the DB and we change it, we've made their current DB
 data invalid instead of just changing the province name that appears in
 the list.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14301: django crashes on email address that passed validate_email() (utf8-tld)

[Django]

#14301: django crashes on email address that passed validate_email()  (utf8-tld)
---+
  Reporter:  harm  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.core.mail  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by SmileyChris):

 Is the try/except even needed? If the name gets always encoded to str
 using the charset, why not just assume we should do this for the email
 address to?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14455: [patch] Minor regression test fix

[Django]

#14455: [patch] Minor regression test fix
-+--
  Reporter:  kylefox | Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  django.contrib.localflavor  |   Version:  SVN  

Resolution:  |  Keywords:  localflavor, 
regression, test
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Changes (by jezdez):

  * milestone:  => 1.3

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14455: [patch] Minor regression test fix

[Django]

#14455: [patch] Minor regression test fix
-+--
  Reporter:  kylefox | Owner:  nobody   

Status:  new | Milestone:   

 Component:  django.contrib.localflavor  |   Version:  SVN  

Resolution:  |  Keywords:  localflavor, 
regression, test
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Changes (by jezdez):

  * stage:  Unreviewed => Accepted

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14456: Convert inline_formsets doctests to unit tests

[Django]

#14456: Convert inline_formsets doctests to unit tests
+---
  Reporter:  prestontimmons | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:  tests 
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * stage:  Accepted => Ready for checkin

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14456: Convert inline_formsets doctests to unit tests

[Django]

#14456: Convert inline_formsets doctests to unit tests
+---
  Reporter:  prestontimmons | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:  tests 
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6388: as_p produce invalid HTML for RadioSelect

[Django]

#6388: as_p produce invalid HTML for RadioSelect
-+--
  Reporter:  batiste | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Changes (by simonluijk):

 * cc: simonlu...@gmail.com (added)
  * stage:  Accepted => Design decision needed

Comment:

 A decision needs to be made in regards to backwards compatibility. So
 moving to DDN.

 I am new to this so if this is wrong please slap me gently!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14457: Possible error in settings.py description

[Django]

#14457: Possible error in settings.py description
+---
  Reporter:  zsoltbot   | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.2 
Resolution: |  Keywords:  tutorial
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by lrekucki):

 Grr... I swear I double checked the ticket number - it should be #14255,
 not 14067.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14457: Possible error in settings.py description

[Django]

#14457: Possible error in settings.py description
+---
  Reporter:  zsoltbot   | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.2 
Resolution: |  Keywords:  tutorial
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by lrekucki):

  * keywords:  => tutorial
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This ticket is kind of interesting, because we just removed "mysite" from
 tutorial (see #14067) to meet a very popular demand #14216 (at least
 partially).

 The trick here is that writing "from mysite.polls import ..." artificially
 ties the Polls application to your project. This  is discouraged. But to
 make things work properly, the "polls" module must be imported everywhere
 using the same name (otherwise you will have two different modules:
 "mysite.polls" and "polls"). That includes imports made by Django itself,
 so the module name in INSTALLED_APPS had to be changed.

 In simpler terms: if your application is named "polls" it seems reasonable
 to use "polls" in the INSTALLED_APPS. I don't see nothing in new version
 of the tutorial that would suggest using "mysite.polls".

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14201 - django/branches/releases/1.2.X/docs/internals

[noreply]

Author: SmileyChris
Date: 2010-10-13 02:02:43 -0500 (Wed, 13 Oct 2010)
New Revision: 14201

Modified:
   django/branches/releases/1.2.X/docs/internals/committers.txt
Log:
[1.2.X] Fix a typo in my bio. Backport of [14200]

Modified: django/branches/releases/1.2.X/docs/internals/committers.txt
===
--- django/branches/releases/1.2.X/docs/internals/committers.txt
2010-10-13 06:59:45 UTC (rev 14200)
+++ django/branches/releases/1.2.X/docs/internals/committers.txt
2010-10-13 07:02:43 UTC (rev 14201)
@@ -258,7 +258,7 @@
 
 `Chris Beaven`_
 Chris has been submitting patches and suggesting crazy ideas for Django
-since early 2006. An advocate for community involement and a long-term
+since early 2006. An advocate for community involvement and a long-term
 triager, he is still often found answering questions in the #django IRC
 channel.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.