Re: [Django] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
+
 Reporter:  brutasse|Owner:  brutasse
 Type:  New feature |   Status:  new
Component:  Forms   |  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by mitar):

 * cc: mmitar@… (added)


-- 
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-updates@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] #15244: Documentation needed for RadioFieldRenderer

[Django]

#15244: Documentation needed for RadioFieldRenderer
-+
 Reporter:  SmileyChris  |Owner:  lkeijser
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  renderer widget  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by mitar):

 * cc: mmitar@… (added)


-- 
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-updates@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] #18093: AnonymousUser should have a 'pk' attribute (was: AnonymousUser should have a 'pk' element)

[Django]

#18093: AnonymousUser should have a 'pk' attribute
--+
 Reporter:  lamby |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by ptone):

 * component:  Uncategorized => contrib.auth
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 While from a purity point of view - "primary key" pk implies a database
 persistence, the truth is that in Django models, pk is more removed from
 the actual db column than id is.

 However I can't imagine any major negative impacts from also setting
 pk=None in AnonymousUser

-- 
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-updates@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] #18096: Overiding delete permissions in the Admin

[Django]

#18096: Overiding delete permissions in the Admin
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ptone):

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


Comment:

 I think you may be confusing get_delete_permission - which is an
 undocumented accessor that can return the permission label from models,
 with ModelAdmin.has_delete_permission which does the permission checking
 for the admin, and is what you would override in a ModelAdmin subclass

 
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_delete_permission

 If this was a typo - and in fact you are saying has_delete_permission is
 not behaving as documented - please feel free to reopen.

-- 
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-updates@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] #17644: Use namedtuples in Query.alias_map to make debugging easier

[Django]

#17644: Use namedtuples in Query.alias_map to make debugging easier
-+-
 Reporter:  lrekucki |Owner:  lrekucki
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 The attached patch converts alias_map values from ordinary tuples to
 namedtuples. All tests passed (although I can't test geodjango currently).
 No speed regressions spotted using djangobench. The first attached patch
 contains some comments which would be useful to consolidate into this
 patch.

-- 
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-updates@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] #18102: fr localflavor : force min and max length

[Django]

#18102: fr localflavor : force min and max length
--+
 Reporter:  mothsART  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.localflavor   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  fr localflavor| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by mothsART):

 charettes (Simon) : html5 minLength provides the input argument.
 While Django does used it yet, i feel good to make explicit...not
 necessarily required.

 In my patch, i think the key element is to use CharField instead of Field
 for at least benefit from "max" and "min_length".

 Ergonomically, I think that a user always prefers a frame imposed as a
 false freedom.
 In our case, if the validator strength size, why would it be possible to
 have a longer field?

-- 
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-updates@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] #17957: If engine for default DB alias has interprets_empty_strings_as_nulls (i.e. Oracle) it affects DDL SQL for model fields null=False in other DBs

[Django]

#17957: If engine for default DB alias has interprets_empty_strings_as_nulls 
(i.e.
Oracle) it affects DDL SQL for model fields null=False in other DBs
-+-
 Reporter:  bhuztez  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  oracle   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Accepted => Ready for checkin


Comment:

 The patch looks good to me. It doesn't look like any additional tests are
 needed, the test suite fails pretty spectacularly if you accidentally have
 char fields as NOT NULL on Oracle.

-- 
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-updates@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] #17957: If engine for default DB alias has interprets_empty_strings_as_nulls (i.e. Oracle) it affects DDL SQL for model fields null=False in other DBs

[Django]

#17957: If engine for default DB alias has interprets_empty_strings_as_nulls 
(i.e.
Oracle) it affects DDL SQL for model fields null=False in other DBs
-+-
 Reporter:  bhuztez  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ikelly):

 * keywords:   => oracle


-- 
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-updates@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] #18108: Where are translations for docs

[Django]

#18108: Where are translations for docs
-+-
 Reporter:  survaes@…|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  documentation|  Unreviewed
  translation|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_docs:   => 0
 * severity:  Release blocker => Normal
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Technically this isn't a release blocker. It sounds more like a social
 issue that a code issue, too.

-- 
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-updates@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] #18108: Where are translations for docs

[Django]

#18108: Where are translations for docs
-+-
 Reporter:  survaes@…|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Djangoproject.com|Version:
  Web site   |   Keywords:  documentation
 Severity:  Release blocker  |  translation
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 In the docs, the''' url is prefixed by en/version''', if i change to
 another language i found 404 pages.

 I think this point is important and that '''many tranlators have stopped
 theirs job because they are not published''' (if you show this page
 [https://code.djangoproject.com/wiki/DjangoResources#Resourcesinotherlanguages
 wiki1] and this other
 [https://code.djangoproject.com/wiki/TranslateDocumentation wiki2]), you
 can see that many efforts have been made.

 I take this report as blocked, because i think that '''for too much
 developpers, don't to read docs in theirs language is blocking'''. For me
 even if i can read and write english, i read and write slowly than in my
 mother language. For coding this is a little problem (signs are near math
 formulas), for docs, this is a strong problem, as you read many sentences
 in shorts times.


 To conclude my questions are :
  - Is it possible with actual system to publish translation.
  - If yes :
 - when django will permit to send translations and to publish
 them?
 - where? (svn, git, a special django system...)
 - what will be the translation process? acceptance -
 failover...

 If this is possible, i will participates and many others. Be sure that
 this interessests many people.

 Whatever your answer, '''thanks for your works''', this site is so clear
 and django is a powerfull framework.

 Best Regard,

 Nicolas

-- 
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-updates@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] #18107: Usage of deprecated import in GeoIP docs

[Django]

#18107: Usage of deprecated import in GeoIP docs
-+-
 Reporter:  jonash   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * 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-updates@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] r17902 - django/trunk/docs/ref/contrib/gis

[noreply]

Author: claudep
Date: 2012-04-11 14:35:08 -0700 (Wed, 11 Apr 2012)
New Revision: 17902

Modified:
   django/trunk/docs/ref/contrib/gis/geoip.txt
Log:
Fixed #18107 -- Replaced a deprecated import path for GeoIP in docs. Thanks 
jonash for the report.


Modified: django/trunk/docs/ref/contrib/gis/geoip.txt
===
--- django/trunk/docs/ref/contrib/gis/geoip.txt 2012-04-11 21:27:18 UTC (rev 
17901)
+++ django/trunk/docs/ref/contrib/gis/geoip.txt 2012-04-11 21:35:08 UTC (rev 
17902)
@@ -40,7 +40,7 @@
 Assuming you have the GeoIP C library installed, here is an example of its
 usage::
 
- >>> from django.contrib.gis.utils import GeoIP
+ >>> from django.contrib.gis.geoip import GeoIP
  >>> g = GeoIP()
  >>> g.country('google.com')
  {'country_code': 'US', 'country_name': 'United States'}

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #18107: Usage of deprecated import in GeoIP docs

[Django]

#18107: Usage of deprecated import in GeoIP docs
---+
 Reporter:  jonash |  Owner:  nobody
 Type:  Uncategorized  | Status:  closed
Component:  Documentation  |Version:  1.4
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+
Changes (by claudep):

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


Comment:

 In [17902]:
 {{{
 #!CommitTicketReference repository="" revision="17902"
 Fixed #18107 -- Replaced a deprecated import path for GeoIP in docs.
 Thanks jonash 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-updates@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] r17901 - django/branches/releases/1.4.X/tests/regressiontests/test_utils

[noreply]

Author: claudep
Date: 2012-04-11 14:27:18 -0700 (Wed, 11 Apr 2012)
New Revision: 17901

Modified:
   django/branches/releases/1.4.X/tests/regressiontests/test_utils/tests.py
Log:
[1.4.X] Fixed #18027 -- Removed an HTMLParser test that doesn't raise any more 
in recent Python versions. Thanks Arfever and Anssi Kaariainen for the report 
and the patch.

Backport of r17900 from trunk.


Modified: 
django/branches/releases/1.4.X/tests/regressiontests/test_utils/tests.py
===
--- django/branches/releases/1.4.X/tests/regressiontests/test_utils/tests.py
2012-04-11 21:25:22 UTC (rev 17900)
+++ django/branches/releases/1.4.X/tests/regressiontests/test_utils/tests.py
2012-04-11 21:27:18 UTC (rev 17901)
@@ -422,8 +422,6 @@
 self.assertHTMLEqual('', '')
 with self.assertRaises(HTMLParseError):
 parse_html('')
-with self.assertRaises(HTMLParseError):
-parse_html('

Re: [Django] #18027: regressiontests.test_utils.tests.HTMLEqualTests.test_parsing_errors() fails with Python >=2.7.3

[Django]

#18027: regressiontests.test_utils.tests.HTMLEqualTests.test_parsing_errors() 
fails
with Python >=2.7.3
-+-
 Reporter:  Arfrever |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by claudep):

 In [17901]:
 {{{
 #!CommitTicketReference repository="" revision="17901"
 [1.4.X] Fixed #18027 -- Removed an HTMLParser test that doesn't raise any
 more in recent Python versions. Thanks Arfever and Anssi Kaariainen for
 the report and the patch.

 Backport of r17900 from trunk.
 }}}

-- 
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-updates@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] r17900 - django/trunk/tests/regressiontests/test_utils

[noreply]

Author: claudep
Date: 2012-04-11 14:25:22 -0700 (Wed, 11 Apr 2012)
New Revision: 17900

Modified:
   django/trunk/tests/regressiontests/test_utils/tests.py
Log:
Fixed #18027 -- Removed an HTMLParser test that doesn't raise any more in 
recent Python versions. Thanks Arfever and Anssi Kaariainen for the report and 
the patch.


Modified: django/trunk/tests/regressiontests/test_utils/tests.py
===
--- django/trunk/tests/regressiontests/test_utils/tests.py  2012-04-11 
21:11:22 UTC (rev 17899)
+++ django/trunk/tests/regressiontests/test_utils/tests.py  2012-04-11 
21:25:22 UTC (rev 17900)
@@ -422,8 +422,6 @@
 self.assertHTMLEqual('', '')
 with self.assertRaises(HTMLParseError):
 parse_html('')
-with self.assertRaises(HTMLParseError):
-parse_html('

Re: [Django] #18027: regressiontests.test_utils.tests.HTMLEqualTests.test_parsing_errors() fails with Python >=2.7.3

[Django]

#18027: regressiontests.test_utils.tests.HTMLEqualTests.test_parsing_errors() 
fails
with Python >=2.7.3
-+-
 Reporter:  Arfrever |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 In [17900]:
 {{{
 #!CommitTicketReference repository="" revision="17900"
 Fixed #18027 -- Removed an HTMLParser test that doesn't raise any more in
 recent Python versions. Thanks Arfever and Anssi Kaariainen for the report
 and the patch.
 }}}

-- 
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-updates@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] r17899 - in django/trunk: django/db/models tests/modeltests/prefetch_related

[noreply]

Author: aaugustin
Date: 2012-04-11 14:11:22 -0700 (Wed, 11 Apr 2012)
New Revision: 17899

Modified:
   django/trunk/django/db/models/query.py
   django/trunk/tests/modeltests/prefetch_related/tests.py
Log:
Fixed #17439 -- Prevented spurious queries for missing objects after 
prefetch_related has run.

That affects nullable foreign key, nullable one-to-one, and reverse one-to-one 
relations.


Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2012-04-11 17:49:22 UTC (rev 
17898)
+++ django/trunk/django/db/models/query.py  2012-04-11 21:11:22 UTC (rev 
17899)
@@ -6,6 +6,7 @@
 import itertools
 import sys
 
+from django.core import exceptions
 from django.db import connections, router, transaction, IntegrityError
 from django.db.models.fields import AutoField
 from django.db.models.query_utils import (Q, select_related_descend,
@@ -1677,14 +1678,21 @@
 # (e.g. via select_related), or hopefully some other property
 # that doesn't support prefetching but needs to be traversed.
 
-# We replace the current list of parent objects with that list.
-obj_list = [getattr(obj, attr) for obj in obj_list]
+# We replace the current list of parent objects with the list
+# of related objects, filtering out empty or missing values so
+# that we can continue with nullable or reverse relations.
+new_obj_list = []
+for obj in obj_list:
+try:
+new_obj = getattr(obj, attr)
+except exceptions.ObjectDoesNotExist:
+continue
+if new_obj is None:
+continue
+new_obj_list.append(new_obj)
+obj_list = new_obj_list
 
-# Filter out 'None' so that we can continue with nullable
-# relations.
-obj_list = [obj for obj in obj_list if obj is not None]
 
-
 def get_prefetcher(instance, attr):
 """
 For the attribute 'attr' on the given instance, finds
@@ -1778,8 +1786,7 @@
 vals = rel_obj_cache.get(instance_attr_val, [])
 if single:
 # Need to assign to single cache on instance
-if vals:
-setattr(obj, cache_name, vals[0])
+setattr(obj, cache_name, vals[0] if vals else None)
 else:
 # Multi, attribute represents a manager with an .all() method that
 # returns a QuerySet

Modified: django/trunk/tests/modeltests/prefetch_related/tests.py
===
--- django/trunk/tests/modeltests/prefetch_related/tests.py 2012-04-11 
17:49:22 UTC (rev 17898)
+++ django/trunk/tests/modeltests/prefetch_related/tests.py 2012-04-11 
21:11:22 UTC (rev 17899)
@@ -68,6 +68,14 @@
 
 self.assertQuerysetEqual(self.book2.authors.all(), [u""])
 
+def test_onetoone_reverse_no_match(self):
+# Regression for #17439
+with self.assertNumQueries(2):
+book = Book.objects.prefetch_related('bookwithyear').all()[0]
+with self.assertNumQueries(0):
+with self.assertRaises(BookWithYear.DoesNotExist):
+book.bookwithyear
+
 def test_survives_clone(self):
 with self.assertNumQueries(2):
 lists = [list(b.first_time_authors.all())

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #17439: prefetch_related issues extra queries for optional OneToOneFields

[Django]

#17439: prefetch_related issues extra queries for optional OneToOneFields
-+-
 Reporter:  gwahl@…  |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17899]:
 {{{
 #!CommitTicketReference repository="" revision="17899"
 Fixed #17439 -- Prevented spurious queries for missing objects after
 prefetch_related has run.

 That affects nullable foreign key, nullable one-to-one, and reverse one-
 to-one relations.
 }}}

-- 
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-updates@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] #18107: Usage of deprecated import in GeoIP docs

[Django]

#18107: Usage of deprecated import in GeoIP docs
---+
 Reporter:  jonash |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 `>>> from django.contrib.gis.utils import GeoIP`

 should be

 `>>> from django.contrib.gis.geoip import GeoIP`

 in `ref/contrib/gis/geoip/`

-- 
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-updates@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] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+-
 Reporter:  pixelcort|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  1
-+-

Comment (by anonymous):

 I have losting the form validation, someone can help-me?

 when i submit a invalid email
 i have:
 Caught KeyError while rendering: "Key 'processo' not found in Form"

 but if a submit the same field by other user which not see the inline
 nested, the form show the validation message.

-- 
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-updates@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] #17439: prefetch_related issues extra queries for optional OneToOneFields

[Django]

#17439: prefetch_related issues extra queries for optional OneToOneFields
-+-
 Reporter:  gwahl@…  |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 In fact, since r17890, prefetch_related can die with an exception on
 missing reverse-related objects -- it relied on a bug.

-- 
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-updates@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] #18102: fr localflavor : force min and max length

[Django]

#18102: fr localflavor : force min and max length
--+
 Reporter:  mothsART  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.localflavor   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  fr localflavor| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

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


Comment:

 No Simon, you are not wrong. So let's accept it on the base that
 max_length might be useful for constructing the widget.

-- 
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-updates@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] #12656: QuerySet.defer in default Manager breaks batch update (w/mysql?)

[Django]

#12656: QuerySet.defer in default Manager breaks batch update (w/mysql?)
-+-
 Reporter:  bjj  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  defer| Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 The way I workarounded this bug:

 #In the action function
 def do_something(self, request, queryset):
 id_list = list(queryset.values_list('id', flat=True))
 rows_updated = MyModel.objects.filter(id__in=id_list)
 #Your update goes here
 rows_updated = rows_updated.update(field=True)

-- 
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-updates@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] #18102: fr localflavor : force min and max length

[Django]

#18102: fr localflavor : force min and max length
-+-
 Reporter:  mothsART |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  contrib.localflavor  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  fr localflavor   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Correct me if I'm wrong but I think setting the `max_length` option adds
 an html `maxlength` attribute to the field which might be interesting but
 specifying `min_length` doesn't add anything useful here.

-- 
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-updates@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] #18071: urlize is case-sensitive

[Django]

#18071: urlize is case-sensitive
---+
 Reporter:  luke@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  fixed
 Keywords:  urlize | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by claudep):

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


Comment:

 In [17898]:
 {{{
 #!CommitTicketReference repository="" revision="17898"
 Fixed #18071 -- Ignored case sensitivity in urlize utility. Thanks
 l...@creaturecreative.com and adamzap for the report and the patch.
 }}}

-- 
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-updates@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] r17898 - in django/trunk: django/utils tests/regressiontests/defaultfilters

[noreply]

Author: claudep
Date: 2012-04-11 10:49:22 -0700 (Wed, 11 Apr 2012)
New Revision: 17898

Modified:
   django/trunk/django/utils/html.py
   django/trunk/tests/regressiontests/defaultfilters/tests.py
Log:
Fixed #18071 -- Ignored case sensitivity in urlize utility. Thanks 
l...@creaturecreative.com and adamzap for the report and the patch.


Modified: django/trunk/django/utils/html.py
===
--- django/trunk/django/utils/html.py   2012-04-11 17:20:59 UTC (rev 17897)
+++ django/trunk/django/utils/html.py   2012-04-11 17:49:22 UTC (rev 17898)
@@ -20,8 +20,8 @@
 unencoded_ampersands_re = re.compile(r'&(?!(\w+|#\d+);)')
 unquoted_percents_re = re.compile(r'%(?![0-9A-Fa-f]{2})')
 word_split_re = re.compile(r'(\s+)')
-simple_url_re = re.compile(r'^https?://\w')
-simple_url_2_re = 
re.compile(r'^www\.|^(?!http)\w[^@]+\.(com|edu|gov|int|mil|net|org)$')
+simple_url_re = re.compile(r'^https?://\w', re.IGNORECASE)
+simple_url_2_re = 
re.compile(r'^www\.|^(?!http)\w[^@]+\.(com|edu|gov|int|mil|net|org)$', 
re.IGNORECASE)
 simple_email_re = re.compile(r'^\S+@\S+\.\S+$')
 link_target_attribute_re = re.compile(r'(]*?)target=[^\s>]+')
 html_gunk_re = re.compile(r'(?:|<\/i>|<\/b>|<\/em>|<\/strong>|<\/?smallcaps>|<\/?uppercase>)',
 re.IGNORECASE)

Modified: django/trunk/tests/regressiontests/defaultfilters/tests.py
===
--- django/trunk/tests/regressiontests/defaultfilters/tests.py  2012-04-11 
17:20:59 UTC (rev 17897)
+++ django/trunk/tests/regressiontests/defaultfilters/tests.py  2012-04-11 
17:49:22 UTC (rev 17898)
@@ -292,6 +292,10 @@
 self.assertEqual(urlize('em...@.stream.ru'),
 u'em...@.stream.ru')
 
+# Check urlize accepts uppercased URL schemes - see #18071
+self.assertEqual(urlize('HTTPS://github.com/'),
+u'https://github.com/"; 
rel="nofollow">HTTPS://github.com/')
+
 def test_wordcount(self):
 self.assertEqual(wordcount(''), 0)
 self.assertEqual(wordcount(u'oneword'), 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-updates@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] #18102: fr localflavor : force min and max length

[Django]

#18102: fr localflavor : force min and max length
-+-
 Reporter:  mothsART |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  contrib.localflavor  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  fr localflavor   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Why do you think it would be better? The validators for these fields
 already enforce the length.

-- 
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-updates@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] #18104: python_markdown_deprecation incorrectly formed

[Django]

#18104: python_markdown_deprecation incorrectly formed
+
 Reporter:  RoySmith|Owner:  claudep
 Type:  Bug |   Status:  closed
Component:  contrib.markup  |  Version:  1.4
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+

Comment (by claudep):

 I didn't touch the code in trunk, as it will be removed (see #18041).

-- 
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-updates@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] #18104: python_markdown_deprecation incorrectly formed

[Django]

#18104: python_markdown_deprecation incorrectly formed
+
 Reporter:  RoySmith|Owner:  claudep
 Type:  Bug |   Status:  closed
Component:  contrib.markup  |  Version:  1.4
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by claudep):

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


Comment:

 In [17897]:
 {{{
 #!CommitTicketReference repository="" revision="17897"
 [1.4.X] Fixed #18104 -- Added missing parentheses around two-lines
 deprecation string. Thanks Roy Smith 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-updates@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] r17897 - django/branches/releases/1.4.X/django/contrib/markup/templatetags

[noreply]

Author: claudep
Date: 2012-04-11 10:20:59 -0700 (Wed, 11 Apr 2012)
New Revision: 17897

Modified:
   django/branches/releases/1.4.X/django/contrib/markup/templatetags/markup.py
Log:
[1.4.X] Fixed #18104 -- Added missing parentheses around two-lines deprecation 
string. Thanks Roy Smith for the report.


Modified: 
django/branches/releases/1.4.X/django/contrib/markup/templatetags/markup.py
===
--- django/branches/releases/1.4.X/django/contrib/markup/templatetags/markup.py 
2012-04-11 13:00:38 UTC (rev 17896)
+++ django/branches/releases/1.4.X/django/contrib/markup/templatetags/markup.py 
2012-04-11 17:20:59 UTC (rev 17897)
@@ -65,8 +65,8 @@
 safe_mode = True
 else:
 safe_mode = False
-python_markdown_deprecation = "The use of Python-Markdown "
-"< 2.1 in Django is deprecated; please update to the current 
version"
+python_markdown_deprecation = ("The use of Python-Markdown "
+"< 2.1 in Django is deprecated; please update to the current 
version")
 # Unicode support only in markdown v1.7 or above. Version_info
 # exist only in markdown v1.6.2rc-2 or above.
 markdown_vers = getattr(markdown, "version_info", 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-updates@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] #18104: python_markdown_deprecation incorrectly formed

[Django]

#18104: python_markdown_deprecation incorrectly formed
+
 Reporter:  RoySmith|Owner:  claudep
 Type:  Bug |   Status:  assigned
Component:  contrib.markup  |  Version:  1.4
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by sage):

 * 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-updates@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] #18104: python_markdown_deprecation incorrectly formed

[Django]

#18104: python_markdown_deprecation incorrectly formed
+
 Reporter:  RoySmith|Owner:  claudep
 Type:  Bug |   Status:  assigned
Component:  contrib.markup  |  Version:  1.4
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by claudep):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => claudep
 * needs_docs:   => 0
 * 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-updates@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] #18105: Investigate possible misuse of Context

[Django]

#18105: Investigate possible misuse of Context
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I have separated in two distinct patches the problematic uses of Context
 initialization from a context instance in Django code.

 At this point and considering the correction you committed in r17896, it's
 still possible to intialize a Context from another Context, even with
 these patches.

-- 
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-updates@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] #18097: __contains__ on an incompletely evaluated QuerySet can incorrectly return False

[Django]

#18097: __contains__ on an incompletely evaluated QuerySet can incorrectly 
return
False
-+-
 Reporter:  kmichel_wgs  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ogier):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 1
 * 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-updates@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] #17341: Model.save() commits transactions after every parent class save

[Django]

#17341: Model.save() commits transactions after every parent class save
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by charettes):

 * cc: charette.s@… (added)


-- 
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-updates@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] #18106: documents error on topic pagination

[Django]

#18106: documents error on topic pagination
---+--
 Reporter:  zenglu.liu@…   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  pagination | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by zenglu.liu@…):

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


Comment:

 Replying to [ticket:18106 zenglu.liu@…]:
 > {% for contact in contacts %}
 >
 > should be
 >
 > {% for contact in contacts.object_list %}

 the document is here:

 https://docs.djangoproject.com/en/1.4/topics/pagination/

-- 
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-updates@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] #18106: documents error on topic pagination

[Django]

#18106: documents error on topic pagination
---+
 Reporter:  zenglu.liu@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:  pagination
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 {% for contact in contacts %}

 should be

 {% for contact in contacts.object_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-updates@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] #18092: Composite indexes

[Django]

#18092: Composite indexes
-+-
 Reporter:  ivan_virabyan|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ivan_virabyan):

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


Comment:

 Just thought that index_together might be a better name, for consistency
 with unique_together

-- 
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-updates@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] #17998: database threading issue with dev server and sqlite

[Django]

#17998: database threading issue with dev server and sqlite
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by akaariai):

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


Comment:

 I can't reproduce this and I haven't seen other complaints about this.
 Closing this as worksforme.

-- 
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-updates@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] #18093: AnonymousUser should have a 'pk' element

[Django]

#18093: AnonymousUser should have a 'pk' element
---+--
 Reporter:  lamby  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by guettli):

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


Comment:

 If the patch is trivial, please add it to this ticket. I remove "has
 patch".

-- 
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-updates@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] #18063: repr() should count only ascii, not unicode

[Django]

#18063: repr() should count only ascii, not unicode
---+--
 Reporter:  guettli|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by guettli):

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


Comment:

 Reference to the Python Doc:
 http://docs.python.org/reference/datamodel.html?highlight=repr#object.__repr__


 {{{
 The return value must be a string object
 }}}
 It must not be a unicode object in Python 2.x

-- 
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-updates@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] #18105: Investigate possible misuse of Context

[Django]

#18105: Investigate possible misuse of Context
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 I think we need a deprecation path, but I'm in favor of this change.

-- 
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-updates@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] #18103: Change to _reset_dicts causes wholesale failure

[Django]

#18103: Change to _reset_dicts causes wholesale failure
-+-
 Reporter:  vsajip   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17896]:
 {{{
 #!CommitTicketReference repository="" revision="17896"
 Fixed #18103 -- Regression introduced in r17895.
 }}}

-- 
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-updates@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] r17896 - django/trunk/django/template

[noreply]

Author: aaugustin
Date: 2012-04-11 06:00:38 -0700 (Wed, 11 Apr 2012)
New Revision: 17896

Modified:
   django/trunk/django/template/context.py
Log:
Fixed #18103 -- Regression introduced in r17895.


Modified: django/trunk/django/template/context.py
===
--- django/trunk/django/template/context.py 2012-04-11 02:03:59 UTC (rev 
17895)
+++ django/trunk/django/template/context.py 2012-04-11 13:00:38 UTC (rev 
17896)
@@ -19,9 +19,9 @@
 
 def _reset_dicts(self, value=None):
 builtins = {'True': True, 'False': False, 'None': None}
-if value:
-builtins.update(value)
 self.dicts = [builtins]
+if value is not None:
+self.dicts.append(value)
 
 def __copy__(self):
 duplicate = copy(super(BaseContext, self))

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #18105: Investigate possible misuse of Context

[Django]

#18105: Investigate possible misuse of Context
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * component:  Uncategorized => Template system
 * type:  Uncategorized => Cleanup/optimization


Comment:

 After re-reading the docs about Context, I think things are clear: Context
 takes a dict as optional init parameter. So for me, passing a Context to
 another Context init is a mistake and should be fixed (see my patch on
 #18103).

-- 
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-updates@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] #17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python objects

[Django]

#17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python 
objects
-+-
 Reporter:  anatoly techtonik|Owner:  aaugustin
|   Status:  closed
 Type:  New feature  |  Version:  1.2
Component:  Template system  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by aaugustin):

 Replying to [comment:20 claudep]:
 > Changeset r17894 produced several errors in the Django test suite. In
 fact, it reveals issues where Context instances are initialized with a
 Context argument instead of a simple dict.

 Claude, I've moved this to its own ticket (#18105) because I'd like to fix
 the regression ASAP, but keep track of your suggestion.

-- 
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-updates@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] #18105: Investigate possible misuse of Context

[Django]

#18105: Investigate possible misuse of Context
-+
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.4
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 This was reported [https://code.djangoproject.com/ticket/17229#comment:20
 in the comments of #17229], but I'm moving it to its own ticket for
 clarity.

 

 Changeset r17894 produced several errors in the Django test suite. In
 fact, it reveals issues where Context instances are initialized with a
 Context argument instead of a simple dict.[[BR]]
 Examples:
  * In browser:django/trunk/django/contrib/auth/tests/urls.py, several
 render_to_response calls have the Context instance as second argument,
 which seems to be plain bugs (uncaught until now)
  * In
 browser:django/trunk/django/contrib/admin/templatetags/admin_modify.py,
 the prepopulated_fields_js inclusion tag returns a Context instance
 instead of a dict.

 The question is now whether Context initialization should accept other
 Context instance as the `__init__` dict_ parameter (and then this
 changeset should be fixed) or if we should enforce dict_ as a dict and fix
 places in Django code when it is not the case. I'd be in favour of the
 latter, but this might need some more investigation.

-- 
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-updates@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] #18103: Change to _reset_dicts causes wholesale failure

[Django]

#18103: Change to _reset_dicts causes wholesale failure
-+-
 Reporter:  vsajip   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 It might fix the test suite, but is it the right fix? With your solution,
 when a Context is initialized with another Context param, the resulting
 structure in context.dicts is a list of lists of dicts, instead of a list
 of dicts. I admit I'm not familiar enough with Context handling to know
 whether it is damageable or not, but another approach would be to prevent
 passing a Context instance to the Context `__init__`. This is my approach
 with the following patch.

-- 
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-updates@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] #18103: Change to _reset_dicts causes wholesale failure

[Django]

#18103: Change to _reset_dicts causes wholesale failure
-+-
 Reporter:  vsajip   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * 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-updates@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] #17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python objects

[Django]

#17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python 
objects
-+-
 Reporter:  anatoly techtonik|Owner:  aaugustin
|   Status:  closed
 Type:  New feature  |  Version:  1.2
Component:  Template system  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


Comment:

 The regression is tracked in #18103.

-- 
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-updates@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] #18104: python_markdown_deprecation incorrectly formed

[Django]

#18104: python_markdown_deprecation incorrectly formed
+
 Reporter:  RoySmith|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  contrib.markup  |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  1   |  UI/UX:  0
+
 In /contrib/markup/templatetags/markup.py, this code is incorrect:


 {{{
 python_markdown_deprecation = "The use of Python-Markdown "
 "< 2.1 in Django is deprecated; please update to the current
 version"
 }}}


 I suspect you were attempting to use string concatenation, but what you've
 got is two statements, one assigning a string, the next consisting of just
 a string.  This results in:


 {{{
 [...]/markup.py:83: DeprecationWarning: The use of Python-Markdown
   warnings.warn(python_markdown_deprecation, DeprecationWarning)
 }}}

-- 
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-updates@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] #18103: Change to _reset_dicts causes wholesale failure

[Django]

#18103: Change to _reset_dicts causes wholesale failure
-+--
 Reporter:  vsajip   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by lrekucki):

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


Old description:

> On updating to r17895, lots of tests appear to have stopped working.
> Here's the tail end of the test run:
>
> ==
> ERROR: test_user_permission_performance
> (regressiontests.admin_views.tests.UserAdminTest)
> --
> Traceback (most recent call last):
>   File "/home/vinay/projects/django/tests/regressiontests/admin_views/
> tests.py", line 3244, in test_user_permission_performance
> response = self.client.get('/test_admin/admin/auth/user/%s/' %
> u.pk)
>   File "/home/vinay/projects/django/django/test/client.py", line 427,
> in get
> response = super(Client, self).get(path, data=data, **extra)
>   File "/home/vinay/projects/django/django/test/client.py", line 243,
> in get
> return self.request(**r)
>   File "/home/vinay/projects/django/django/core/handlers/base.py",
> line 136, in get_response
> response = response.render()
>   File "/home/vinay/projects/django/django/template/response.py", line
> 104, in render
> self._set_content(self.rendered_content)
>   File "/home/vinay/projects/django/django/template/response.py", line
> 81, in rendered_content
> content = template.render(context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 140, in render
> return self._render(context)
>   File "/home/vinay/projects/django/django/test/utils.py", line 60, in
> instrumented_test_render
> return self.nodelist.render(context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 823, in render
> bit = self.render_node(node, context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 837, in render_node
> return node.render(context)
>   File "/home/vinay/projects/django/django/template/loader_tags.py",
> line 123, in render
> return compiled_parent._render(context)
>   File "/home/vinay/projects/django/django/test/utils.py", line 60, in
> instrumented_test_render
> return self.nodelist.render(context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 823, in render
> bit = self.render_node(node, context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 837, in render_node
> return node.render(context)
>   File "/home/vinay/projects/django/django/template/loader_tags.py",
> line 123, in render
> return compiled_parent._render(context)
>   File "/home/vinay/projects/django/django/test/utils.py", line 60, in
> instrumented_test_render
> return self.nodelist.render(context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 823, in render
> bit = self.render_node(node, context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 837, in render_node
> return node.render(context)
>   File "/home/vinay/projects/django/django/template/loader_tags.py",
> line 62, in render
> result = block.nodelist.render(context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 823, in render
> bit = self.render_node(node, context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 837, in render_node
> return node.render(context)
>   File "/home/vinay/projects/django/django/template/base.py", line
> 1193, in render
> 'use_tz': context.use_tz,
>   File "/home/vinay/projects/django/django/template/context.py", line
> 96, in __init__
> super(Context, self).__init__(dict_)
>   File "/home/vinay/projects/django/django/template/context.py", line
> 18, in __init__
> self._reset_dicts(dict_)
>   File "/home/vinay/projects/django/django/template/context.py", line
> 23, in _reset_dicts
> builtins.update(value)
> ValueError: dictionary update sequence element #0 has length 1; 2 is
> required
>
> --
> Ran 4698 tests in 956.978s
>
> FAILED (errors=166, skipped=109, expected failures=2)
> Destroying test database for alias 'default'...
> Destroying test database for alias 'other'...
> vinay@eta-oneiric64:~/projects/django/tests$
>
> All the 

[Django] #18103: Change to _reset_dicts causes wholesale failure

[Django]

#18103: Change to _reset_dicts causes wholesale failure
-+
 Reporter:  vsajip   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  SVN
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 On updating to r17895, lots of tests appear to have stopped working.
 Here's the tail end of the test run:

 ==
 ERROR: test_user_permission_performance
 (regressiontests.admin_views.tests.UserAdminTest)
 --
 Traceback (most recent call last):
   File "/home/vinay/projects/django/tests/regressiontests/admin_views/
 tests.py", line 3244, in test_user_permission_performance
 response = self.client.get('/test_admin/admin/auth/user/%s/' %
 u.pk)
   File "/home/vinay/projects/django/django/test/client.py", line 427,
 in get
 response = super(Client, self).get(path, data=data, **extra)
   File "/home/vinay/projects/django/django/test/client.py", line 243,
 in get
 return self.request(**r)
   File "/home/vinay/projects/django/django/core/handlers/base.py",
 line 136, in get_response
 response = response.render()
   File "/home/vinay/projects/django/django/template/response.py", line
 104, in render
 self._set_content(self.rendered_content)
   File "/home/vinay/projects/django/django/template/response.py", line
 81, in rendered_content
 content = template.render(context)
   File "/home/vinay/projects/django/django/template/base.py", line
 140, in render
 return self._render(context)
   File "/home/vinay/projects/django/django/test/utils.py", line 60, in
 instrumented_test_render
 return self.nodelist.render(context)
   File "/home/vinay/projects/django/django/template/base.py", line
 823, in render
 bit = self.render_node(node, context)
   File "/home/vinay/projects/django/django/template/base.py", line
 837, in render_node
 return node.render(context)
   File "/home/vinay/projects/django/django/template/loader_tags.py",
 line 123, in render
 return compiled_parent._render(context)
   File "/home/vinay/projects/django/django/test/utils.py", line 60, in
 instrumented_test_render
 return self.nodelist.render(context)
   File "/home/vinay/projects/django/django/template/base.py", line
 823, in render
 bit = self.render_node(node, context)
   File "/home/vinay/projects/django/django/template/base.py", line
 837, in render_node
 return node.render(context)
   File "/home/vinay/projects/django/django/template/loader_tags.py",
 line 123, in render
 return compiled_parent._render(context)
   File "/home/vinay/projects/django/django/test/utils.py", line 60, in
 instrumented_test_render
 return self.nodelist.render(context)
   File "/home/vinay/projects/django/django/template/base.py", line
 823, in render
 bit = self.render_node(node, context)
   File "/home/vinay/projects/django/django/template/base.py", line
 837, in render_node
 return node.render(context)
   File "/home/vinay/projects/django/django/template/loader_tags.py",
 line 62, in render
 result = block.nodelist.render(context)
   File "/home/vinay/projects/django/django/template/base.py", line
 823, in render
 bit = self.render_node(node, context)
   File "/home/vinay/projects/django/django/template/base.py", line
 837, in render_node
 return node.render(context)
   File "/home/vinay/projects/django/django/template/base.py", line
 1193, in render
 'use_tz': context.use_tz,
   File "/home/vinay/projects/django/django/template/context.py", line
 96, in __init__
 super(Context, self).__init__(dict_)
   File "/home/vinay/projects/django/django/template/context.py", line
 18, in __init__
 self._reset_dicts(dict_)
   File "/home/vinay/projects/django/django/template/context.py", line
 23, in _reset_dicts
 builtins.update(value)
 ValueError: dictionary update sequence element #0 has length 1; 2 is
 required

 --
 Ran 4698 tests in 956.978s

 FAILED (errors=166, skipped=109, expected failures=2)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 vinay@eta-oneiric64:~/projects/django/tests$

 All the errors appear to have the same root cause. I'm testing with
 Python 2.7.2+ (default, Oct  4 2011, 20:06:09)  on Ubuntu Oneiric 64-
 bit. The tests were run using

 PYTHONPATH=.. python runtests.py --settings test_sqlite

 in the tests subdirectory.

 The errors seem to be related to Aymeric's change in r17894. If I change

 def _reset_dicts(self, value=None):
 builtins = {'True': True, 'False': False, 'None': None}
 if value:
 builtins.

Re: [Django] #18094: `pre_delete` and `post_delete` signals are not correctly sent in inheritance scenarios involving proxy models

[Django]

#18094: `pre_delete` and `post_delete` signals are not correctly sent in
inheritance scenarios involving proxy models
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  model proxy multi-   |  Unreviewed
  table inheritance signals delete   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Making init signals consistent isn't likely for performance reasons - in
 fact it might make sense to replace them with init hooks. That would fit
 the use case of the signals, and currently the init signals can make model
 init around 2x slower in the not so uncommon case that model init signals
 are defined for some __other__ model in the project - not necessarily the
 one being initialized.

 Altering save signals to fire for each parent class (proxy or not) would
 make sense. Assuming Foo and !FooBar(Foo) models, it is more than likely
 that if you have a signal for Foo that then you have attached the same
 signal for !FooBar too. Because you want to catch "Foo saved" when !FooBar
 is saved - the exact issue we are trying to fix here. So, fixing the
 signals in the way suggested in this ticket removes the need of attaching
 the same signal multiple times but at same time __is__ going to break
 existing usage. For how many users is a different question.

 I am not sure if the above backwards compatibility issue is meaningful for
 delete signals, so if consistency is not possible then fixing just delete
 signals makes sense.

 All in all, maybe the consistency issue should be discussed at django-
 developers?

-- 
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-updates@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] #18100: Deleting model instances with deferred fields don't trigger deletion signals

[Django]

#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  deferred delete  |  Needs documentation:  0
  signals|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Accepted


Comment:

 Deferred model signals is a general problem - not only for delete (see
 #16679 for example - warning: a good old brain-dump ticket). However, I
 think fixing it just for delete does make sense: other signals are not as
 likely to cause problems. Syncdb isn't valid, init is seldom used and if
 you save deferred models you are going to fetch all the fields one at a
 time from the DB, so you are in for an interesting ride anyways.

 Still, .save() should be fixed with something similar. Restructuring the
 whole save_base() might make sense. It is a bit strangely set up currently
 and it is hard to see what exactly is happening in there. (#17341 for one
 approach).

-- 
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-updates@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] #9205: Add savepoint protection to Model.save()

[Django]

#9205: Add savepoint protection to Model.save()
-+-
 Reporter:  Richard Davies   |Owner:  nobody
   |   Status:  closed
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:  wontfix
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 I think this ticket should be closed as wontfix. This is a big behavior
 change leading to backwards compatibility issues, and in addition _will_
 have performance implications - save 1 objects and you create 1
 subtransactions which _does_ cost 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-updates@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] #18102: fr localflavor : force min and max length

[Django]

#18102: fr localflavor : force min and max length
--+
 Reporter:  mothsART  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.localflavor   |Version:  1.3
 Severity:  Normal|   Keywords:  fr localflavor
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 on fr localflavor, i think the best way is to force min and max length on
 form field.

-- 
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-updates@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] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
-+-
 Reporter:  fas  |Owner:  fas
 Type:  Bug  |   Status:  new
Component:  ORM aggregation  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  orm, aggregation,| Triage Stage:  Accepted
  join, contenttypes, filter |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by fhahn):

 * cc: fhahn (added)


-- 
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-updates@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] #17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python objects

[Django]

#17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python 
objects
-+-
 Reporter:  anatoly techtonik|Owner:  aaugustin
|   Status:  reopened
 Type:  New feature  |  Version:  1.2
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by akaariai):

 It could make sense to just revert r17894 to make trunk work again.

 Otherwise, the question is how likely user code is to pass in Context
 instances. I guess it happens, as it wasn't exactly uncommon in our code
 either. So, if Context is going to be disallowed, then at least provide a
 clear error message of what happened.

-- 
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-updates@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] #17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python objects

[Django]

#17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python 
objects
-+-
 Reporter:  anatoly techtonik|Owner:  aaugustin
|   Status:  reopened
 Type:  New feature  |  Version:  1.2
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


-- 
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-updates@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] #17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python objects

[Django]

#17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python 
objects
-+-
 Reporter:  anatoly techtonik|Owner:  aaugustin
|   Status:  closed
 Type:  New feature  |  Version:  1.2
Component:  Template system  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by claudep):

 Changeset r17894 produced several errors in the Django test suite. In
 fact, it reveals issues where Context instances are initialized with a
 Context argument instead of a simple dict.[[BR]]
 Examples:
  * In browser:django/trunk/django/contrib/auth/tests/urls.py, several
 render_to_response calls have the Context instance as second argument,
 which seems to be plain bugs (uncaught until now)
  * In
 browser:django/trunk/django/contrib/admin/templatetags/admin_modify.py,
 the prepopulated_fields_js inclusion tag returns a Context instance
 instead of a dict.

 The question is now whether Context initialization should accept other
 Context instance as the `__init__` dict_ parameter (and then this
 changeset should be fixed) or if we should enforce dict_ as a dict and fix
 places in Django code when it is not the case. I'd be in favour of the
 latter, but this might need some more investigation.

-- 
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-updates@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] #18101: Username doesn't allow backslash

[Django]

#18101: Username doesn't allow backslash
-+-
 Reporter:  honyczek@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.4
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  sspi, remote, user,  | Triage Stage:
  backend, middleware|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by russellm):

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


Comment:

 I'm going to mark this as a duplicate of #3011 -- the root problem here is
 the validation requirements on auth.User, and in order to satsify
 everyone, we're going to need to fix the root problem.

 The good news is that we've had recent movement on this topic, and a
 relatively simple solution that has BDFL approval. Hopefully, this means
 we'll have this fixed for 1.5.

-- 
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-updates@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] #17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python objects

[Django]

#17229: Allow 'True', 'False' and 'None' to resolve to corresponding Python 
objects
-+-
 Reporter:  anatoly techtonik|Owner:  aaugustin
|   Status:  closed
 Type:  New feature  |  Version:  1.2
Component:  Template system  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by anatoly techtonik ):

 Awesome. Nice to see it is going to be in Django 1.5

-- 
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-updates@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] #18101: Username doesn't allow backslash

[Django]

#18101: Username doesn't allow backslash
-+-
 Reporter:   |  Owner:  nobody
  honyczek@… | Status:  new
 Type:  Bug  |Version:  1.4
Component:   |   Keywords:  sspi, remote, user, backend,
  contrib.auth   |  middleware
 Severity:  Normal   |  Has patch:  0
 Triage Stage:   |  UI/UX:  0
  Unreviewed |
Easy pickings:  0|
-+-
 When its used RemoteUserBackend and RemoteUserMiddleware for
 authentication against Active Directory (eg. using auth_mod_sspi),
 User.username contains backslash.

 If you try to edit user details in Admin pages they can't be saved because
 of backslash use restriction. It would be great to remove this
 restriction.

 [http://groups.google.com/group/django-
 users/browse_thread/thread/07e699ce169218e7#]

-- 
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-updates@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] #18062: Document Best Practice for Choices in Model Fields

[Django]

#18062: Document Best Practice for Choices in Model Fields
---+--
 Reporter:  guettli|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by guettli):

 Hi danols, thank you for looking at this ticket. You can put the
 GENDER_ attributes on the User class without a circular import like
 this:

 {{{
 class UserManager(models.Manager):
 def males(self):
 return self.all().filter(gender=User.GENDER_MALE)
 def females(self):
 return self.all().filter(gender=User.GENDER_FEMALE)

 class User(models.Model):
 GENDER_MALE = 0
 GENDER_FEMALE = 1
 GENDER_CHOICES = [(GENDER_MALE, 'Male'), (GENDER_FEMALE, 'Female')]
 gender = models.IntegerField(choices=GENDER_CHOICES)
 objects = UserManager()
 def greet(self):
 return {User.GENDER_MALE: 'Hi, boy', User.GENDER_FEMALE: 'Hi,
 girl.'}[self.gender]
 }}}

-- 
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-updates@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.