Re: [Django] #21603: Inconsistent column names in cursor.description under SQLite break RawQuerySet

[Django]

#21603: Inconsistent column names in cursor.description under SQLite break
RawQuerySet
-+-
 Reporter:  alex@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by alexh):

 OK, I've added the version affected and a link to the bugfix commit in the
 comments. Also added a TODO to remove the change at some point in the
 future. Let me know if it needs anything else.

 Alex

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.3b4a0348809eca9692aabf4b74539499%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22297: TransactionMiddleware signals connection_created too early

[Django]

#22297: TransactionMiddleware signals connection_created too early
---+--
 Reporter:  Naddiseo   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 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 Naddiseo):

 * cc: Naddiseo (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.74959fa7c50fa4debbd3f22f675c41cb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django]

[GitHub]

  Branch: refs/tags/1.7b2
  Home:   https://github.com/django/django

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/532b8e1e8ea09_6edeea5d44127356%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21108: pip install --pre Django==1.xb not found

[Django]

#21108: pip install --pre Django==1.xb not found
-+
 Reporter:  elena|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by timo):

 We tried this for the 1.7 alpha but there was some problem so we had to
 take the package down from PyPI. I think Donald said he would try to look
 into 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.39c9fe4731d61243cddffcddf46d4b11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] dda622: [1.7.x] Bump version numbers for 1.7 beta 1.

[GitHub]

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: dda6224459ed843dfd63e85729613fcc60ce925f
  
https://github.com/django/django/commit/dda6224459ed843dfd63e85729613fcc60ce925f
  Author: James Bennett 
  Date:   2014-03-20 (Thu, 20 Mar 2014)

  Changed paths:
M django/__init__.py

  Log Message:
  ---
  [1.7.x] Bump version numbers for 1.7 beta 1.


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/532b8b2a5f05_62c9138fd3c831ad%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21695: Allow blocktrans to set a context variable

[Django]

#21695: Allow blocktrans to set a context variable
-+
 Reporter:  mitar|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by mitar):

 This is why I created [http://django-
 
missing.readthedocs.org/en/latest/templatetags.html#missing.templatetags.context_tags.setcontext
 this tag] which simply sets the context based on whatever is in there.
 Then there is no need to modify all tags to be able to set context. DRY.
 :-)

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.2739aaa8b3c7613e1bcc6730c6ef8734%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22090: ModelAdmin list_filter field member values are serialized using __str__ and not __repr__

[Django]

#22090: ModelAdmin list_filter field member values are serialized using __str__ 
and
not __repr__
-+-
 Reporter:  sam@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  contrib.admin|   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  admin, list_filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by sam@…):

 The above comment was me, forgot to put my email in

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.5d398c479e9aad5c79633bd2b859e081%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22090: ModelAdmin list_filter field member values are serialized using __str__ and not __repr__

[Django]

#22090: ModelAdmin list_filter field member values are serialized using __str__ 
and
not __repr__
-+-
 Reporter:  sam@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  contrib.admin|   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  admin, list_filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 list_filter is using the __str__ value returned by the first member of the
 choice tuple (value_object, human_readable_string). i.e. The __str__
 representation of the value of the choice. I am arguing that list_filter
 should use the __repr__ of value_object instead, since it is being used as
 a serialized representation.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.0a8b18672f3a883f8aceded5d397a45d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21955: Formset save_as_new=True causes "This QueryDict instance is immutable" error

[Django]

#21955: Formset save_as_new=True causes "This QueryDict instance is immutable"
error
+--
 Reporter:  robin   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.6
 Severity:  Normal  |   Resolution:  invalid
 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 aaugustin):

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


Comment:

 I'm not sure this is legal. Django's tests pass an `instance` and in that
 case `save_as_new` appears to work. The docs also show an example with an
 `instance` parameter.

 Anyway, since `save_as_new` isn't documented, you're in private API
 territory here. If you have a patch for this we may take a look, otherwise
 we're just going to say that the public API works.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5defd845dbeca37cabe9c6cc879ede36%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13978: Allow inline js/css in forms.Media

[Django]

#13978: Allow inline js/css in forms.Media
---+
 Reporter:  nathforge  |Owner:  dmpayton
 Type:  New feature|   Status:  assigned
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sprintdec2010  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 Related: #21987.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0ae0064091351badcb4adaef432a95b2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22296: m2m_changed pk_set value inconsistent between post_add and post_remove

[Django]

#22296: m2m_changed pk_set value inconsistent between post_add and post_remove
-+-
 Reporter:  anentropic   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => Bug
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.cc805313e5d4512303694036eebe527f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21695: Allow blocktrans to set a context variable

[Django]

#21695: Allow blocktrans to set a context variable
-+
 Reporter:  mitar|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 It seems that every tag is going to gain this feature eventually...

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.52230c216301e22cba2d0eebf2117c14%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21987: Allow Media objects to have their own MEDIA_TYPES

[Django]

#21987: Allow Media objects to have their own MEDIA_TYPES
-+-
 Reporter:  Keryn Knight |Owner:  nobody
   |   Status:  new
 Type:   |  Version:  master
  Cleanup/optimization   |   Resolution:
Component:  Forms| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 See also #13978.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/095.c5444ef40189054240e6ff36ca99cb5d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21987: Allow Media objects to have their own MEDIA_TYPES

[Django]

#21987: Allow Media objects to have their own MEDIA_TYPES
-+-
 Reporter:  Keryn Knight |Owner:  nobody
   |   Status:  new
 Type:   |  Version:  master
  Cleanup/optimization   |   Resolution:
Component:  Forms| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/095.5d1d67afab36a6481a2202c8866aff55%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21665: assertRedirects should treat equivalent URLs differing only in URL-escaping as equal

[Django]

#21665: assertRedirects should treat equivalent URLs differing only in 
URL-escaping
as equal
--+
 Reporter:  pdc   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * type:  Bug => Cleanup/optimization
 * component:  Testing framework => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 This particular consequence could be mentioned in the
 [https://docs.djangoproject.com/en/dev/releases/1.6/#quoting-in-reverse
 release notes] but I think the code is now mostly correct.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.c9ff92be4d4067c466f7c6935a955f68%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 222262: Fixed #22163 -- Stopped ignoring unhandled kwargs ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 62ca2354abadf259f4186a0b43f583ed1bd1
  
https://github.com/django/django/commit/62ca2354abadf259f4186a0b43f583ed1bd1
  Author: Aymeric Augustin 
  Date:   2014-03-20 (Thu, 20 Mar 2014)

  Changed paths:
M django/db/models/query.py

  Log Message:
  ---
  Fixed #22163 -- Stopped ignoring unhandled kwargs in select_for_update.


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/532b5c0683163_62c9138fd3c753cf%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22163: select_for_update should take nowait directly

[Django]

#22163: select_for_update should take nowait directly
-+-
 Reporter:  kenny.macdermid@…|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"62ca2354abadf259f4186a0b43f583ed1bd1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="62ca2354abadf259f4186a0b43f583ed1bd1"
 Fixed #22163 -- Stopped ignoring unhandled kwargs in select_for_update.
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/083.f8e4413f6a683af065a64efb8599a71f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22298: Rename Media to Static

[Django]

#22298: Rename Media to Static
--+
   Reporter:  aaugustin   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  master
   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   |
--+
 The confusion between media and static files is almost cleared, except in
 the Widget API which still sports a Media class.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.e9eac1f3b218e31c33f45e5d3383a18e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17556: Let Media classes to inherit

[Django]

#17556: Let Media classes to inherit
-+
 Reporter:  ojo  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  forms media  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 This is a duplicate of #9357.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.d2db0b21b26d88ea41f5cd711dff714d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21665: assertRedirects should treat equivalent URLs differing only in URL-escaping as equal

[Django]

#21665: assertRedirects should treat equivalent URLs differing only in 
URL-escaping
as equal
---+--
 Reporter:  pdc|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 This could be a consequence of #13260. See also #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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.8a31d698d2079053ebd90ca6c509c42e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9357: Unable to subclass form Media class

[Django]

#9357: Unable to subclass form Media class
-+
 Reporter:  Tarken   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 #17556 was a duplicate with a 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a74083cfb2b6810e0e0fcdcb00eee14f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22297: TransactionMiddleware signals connection_created too early

[Django]

#22297: TransactionMiddleware signals connection_created too early
---+--
 Reporter:  Naddiseo   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 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 aaugustin):

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


Comment:

 This will be fixed by app-loading in 1.7 ;-)

 Look for the wall of text on the DevelopersMailingList for details.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.605159b57c889cc9e39eb98d4f78a3e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22160: TimeField default argument not working.

[Django]

#22160: TimeField default argument not working.
-+-
 Reporter:  vlad.dragos.002@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  needsinfo
 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 aaugustin):

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


Comment:

 Aren't you confusing `default` and `initial` 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/083.d715cb2f1ba2cae06fd13c86b86dfe6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22163: select_for_update should take nowait directly

[Django]

#22163: select_for_update should take nowait directly
-+-
 Reporter:  kenny.macdermid@…|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * status:  new => assigned
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 This appears to be an oversight in the original implementation. I'm just
 going to change 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/083.57b22e21cb529a495ae6c6a15ed72887%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22282: models.BooleanField.blank should be 'False' if BooleanField has choices

[Django]

#22282: models.BooleanField.blank should be 'False' if BooleanField has choices
-+-
 Reporter:  django@… |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  needsinfo
 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 aaugustin):

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


Comment:

 Let's start with form fields. A `BooleanField` is rendered by default as a
 checkbox. If it's mandatory (e.g. accept terms & conditions), you set
 `blank = False`. If it's optional, you set `blank = True`.

 Let's now look at model fields. Only the second case makes sense. That's
 why Django forces `blank = True`. You're right, Django could warn that
 `blank = False` is a misconfiguration that probably doesn't do what you
 expect.

 If I understand correctly, you'd like to use a different widget, maybe a
 radio list with two choices. If a value that doesn't match either of your
 choices is returned, as far as I can tell, `BooleanField.to_python` is
 going to raise a `ValidationError`.

 I don't understand why you're saying that "There's no way to make sure the
 value is not blank." On the contrary, Django enforces that you always get
 `True`, `False` or an exception at the model layer. As explained above,
 always getting `True` or an execption isn't interesting at the model
 layer.

 I'm not sure where "`BooleanField` assumes a `None` value to be `False`"
 comes from either.

 Could you show why your example doesn't work? Either an exception
 traceback or a failing test case will do. 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.d95cfa6cfa77cd4678ef0dba19411389%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22297: TransactionMiddleware signals connection_created too early

[Django]

#22297: TransactionMiddleware signals connection_created too early
---+
 Reporter:  Naddiseo   |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 This may or may not be a django bug.

 I have a project that uses django_hstore, which relies on
 `connection_created` in order to register the database adapters for hstore
 conversion with postgresql. With `TransactionMiddleware` the signal seems
 to be called before all the `INSTALLED_APPS` are loaded, thus it is called
 before django_hstore is loaded.

 I am able to reproduce this issue with
 python 2.7.5
 django 1.6.2
 django-hstore 1.2.2
 uwsgi 2.0.3
 psycopg2 2.5.2

 Unfortunately, it can't be reproduced with `manage.py runserver` because
 it validates the models, which loads the apps before the signal is called.

 I've attached a test project with the following setup:

 - Create a postgres database named `hstore_test_db` with user/password as
 test/test
 - Run syncdb
 - Run manage.py shell
 - `from main.models import TestModel; TestModel.objects.create(dict_field=
 {'key' : 1 })`
 - Run uwsgi with the following settings:
 ` uwsgi --http :8000 --module hstore_test.wsgi --chdir $(pwd) --home
 $VIRTUAL_ENV --e DJANGO_SETTINGS_MODULE=hstore_test.settings`

 Note: the error only occurs on the first page load after starting uwsgi.
 It fails to error on any subsequent refresh.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.60a987206981c6c86083642361c75b53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22250: Regression in 1.6.1->1.6.2 -- GIS sql compiler tries to generate sql for a non-concrete field

[Django]

#22250: Regression in 1.6.1->1.6.2 -- GIS sql compiler tries to generate sql 
for a
non-concrete field
-+-
 Reporter:  gwahl@…  |Owner:  bak1an
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.39c0f9d85b229dec9c64490536b54fd5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17802: Pass the request down to the Sitemap callable

[Django]

#17802: Pass the request down to the Sitemap callable
--+--
 Reporter:  rm_   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sitemaps  |  Version:  master
 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 aaugustin):

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


Comment:

 Err. Didn't mean to close 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.588b026e62476ded7193a882a78c984b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17802: Pass the request down to the Sitemap callable

[Django]

#17802: Pass the request down to the Sitemap callable
--+--
 Reporter:  rm_   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sitemaps  |  Version:  master
 Severity:  Normal|   Resolution:  duplicate
 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 aaugustin):

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


Comment:

 I can't say what the proper solution is, but I'm afraid hardcoding a
 sitemap-specific solution will only make proper multi-tenancy harder. I
 think this requires a discussion on the DevelopersMailingList. See also
 #22231.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.a5b26ea35d9b97ef9509917f9268818d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22115: Related Querysets from Inlines not getting cached

[Django]

#22115: Related Querysets from Inlines not getting cached
-+-
 Reporter:  john.parton@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  admin, inline,   | Triage Stage:  Accepted
  queryset, queryset caching |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 This makes sense. However, it might be prohibitively hard to implement.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/083.16e0644c4d455806f92ace731766220f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22090: ModelAdmin list_filter field member values are serialized using __str__ and not __repr__

[Django]

#22090: ModelAdmin list_filter field member values are serialized using __str__ 
and
not __repr__
-+-
 Reporter:  sam@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  contrib.admin|   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  admin, list_filter   |  Unreviewed
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
 * needs_docs:   => 0
 * resolution:   => needsinfo
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 I'm not sure to understand your message.

 Since you're referring to the `__str__` method of models, maybe you're
 thinking of foreign keys, but in that case Django uses
 `xxx__id__exact=yyy`, so there's no `__str__` or `__repr__` involved.

 [https://docs.djangoproject.com/en/dev/ref/models/fields/#choices choices]
 are an iterable of 2-uples where:

 - the first item is an arbitrary object corresponding to the underlying
 database field
 - the second item a a string describing that object

 Both should be unique to avoid ambiguity. Since the second item is
 guaranteed to be a string, it's natural to use it in the URL. But once
 again there's no `__str__` or `__repr__` involved.

 Can you provide a sample models.py and admin.py that exhibits the problem
 you're reporting?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.b10e3232c88f65bee49281c626467005%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21694: Default filter cannot be used with undefined variables

[Django]

#21694: Default filter cannot be used with undefined variables
-+--
 Reporter:  mitar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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:  0|UI/UX:  0
-+--

Comment (by aaugustin):

 That doesn't sound like a very good design :(

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.48848a1554b7cb721969665891ebc7d9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22238: {% url %} allow optional parameters

[Django]

#22238: {% url %} allow optional parameters
-+--
 Reporter:  anonymous|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  1.6
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  url tag  | Triage Stage:  Unreviewed
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:   => needsinfo


Comment:

 Please propose a solution.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.20f76e533140e7946abffa5b9aa9c1cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22220: reverse() documentation

[Django]

#0: reverse() documentation
--+
 Reporter:  EvilDMP   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.6
 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 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f84d6d0f2555a6b4f8ed9c59cebc58ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22109: clarify difference between relative and absolute STATIC_URL

[Django]

#22109: clarify difference between relative and absolute STATIC_URL
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Documentation|   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  static_url,static|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 The docs for `STATIC_URL` link to the docs for the `staticfiles` app,
 which seems reasonable and DRY to me.

 There's tons of useful information in the `staticfiles` docs, including
 but not limited to this one, and it isn't a good idea to duplicate 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6e6462ffba98e1c60fd554a2ecf7489a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22246: WizardView.form_list is undocumented

[Django]

#22246: WizardView.form_list is undocumented
-+
 Reporter:  django-issues@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/081.6cfd279dd7c4d9a370c150b61fa73ae5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22146: Database-Connections time out in long running Applications without request context.

[Django]

#22146: Database-Connections time out in long running Applications without 
request
context.
-+-
 Reporter:  kahnert  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   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'd say it's up to the application to close the connection when it knows
 it isn't going to use it for some time that may exceed the database's
 connection timeout :)

 What database backend are you using? Isn't this a duplicate of #21597?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.50acc5ec3b2d0feeedea182dc234edfa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22037: Allow testing and dumping legacy database without enabling syncdb

[Django]

#22037: Allow testing and dumping legacy database without enabling syncdb
-+-
 Reporter:  ellisd23@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  duplicate
 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 aaugustin):

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


Comment:

 This appears to be a duplicate of #21906.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.fccc38103a312b11c26d4b5e62024f22%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21603: Inconsistent column names in cursor.description under SQLite break RawQuerySet

[Django]

#21603: Inconsistent column names in cursor.description under SQLite break
RawQuerySet
-+-
 Reporter:  alex@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Given that the patch isn't too invasive, yes, we could include it... It
 needs a comment stating which versions of SQLite are affected, so we can
 eventually remove the workaround when we consider them sufficiently
 outdated.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.6eac6b617e3f610c7dabbe0a235686a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22203: Automatically get default value for "current_app", for easier namespace support.

[Django]

#22203: Automatically get default value for "current_app", for easier namespace
support.
---+--
 Reporter:  mrmachine  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (URLs)|  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 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 aaugustin):

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


Comment:

 In fact, I'm going to reject the idea to use global state for this
 purpose. I don't believe that's the answer.

 That said, if you can build consensus on the DevelopersMailingList that
 there's no better answer, please 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.71c06e8b955221248ecfc8a6b1e9a810%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22055: 404 page does not display stack trace when Resolver404 is raised from a view

[Django]

#22055: 404 page does not display stack trace when Resolver404 is raised from a
view
--+
 Reporter:  gnosek|Owner:  gnosek
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (URLs)   |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * type:  Uncategorized => Cleanup/optimization
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.4f6afe0b9cf496b1013c5e4f7b0ad3fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22203: Automatically get default value for "current_app", for easier namespace support.

[Django]

#22203: Automatically get default value for "current_app", for easier namespace
support.
---+--
 Reporter:  mrmachine  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (URLs)|  Version:  master
 Severity:  Normal |   Resolution:
 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 aaugustin):

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


Comment:

 If you're talking about thread local storage, that really means global
 state (otherwise you would have no reason to make it thread local). We've
 always been at war with global state :-)

 However, I agree that the URL namespacing API isn't optimal. I suspect
 #21927 would address your goals. Is this ticket a duplicate?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.dac36f18d63e1696b7d013651b138e5f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21936: Add delete message mixin

[Django]

#21936: Add delete message mixin
+
 Reporter:  david.fischer.ch@…  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.messages|  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  mixin   | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  1   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by aaugustin):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted
 * type:  Uncategorized => New feature
 * needs_docs:  0 => 1


Comment:

 Your patch sets the message before the object is deleted. What if deleting
 the object fails?

 Otherwise, this addition makes sense.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/084.7e2aaa9e11ff4a3976541cfd534d4b2a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22004: Allow session.modified with an explicit False value to override SESSION_SAVE_EVERY_REQUEST

[Django]

#22004: Allow session.modified with an explicit False value to override
SESSION_SAVE_EVERY_REQUEST
--+--
 Reporter:  bruth |Owner:
 Type:  Uncategorized |   Status:  closed
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 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 aaugustin):

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


Comment:

 Your proposal could degenerate into a war of (overrides that override)+
 the default behavior :/

 The root cause of the problem is that Django has global settings to
 control the session behavior globally. Introducing exceptions isn't a good
 idea.

 A better idea would be to replace all relevant SESSION_* settings with a
 flexible mechanism to control when sessions are saved.

 In the short term, may I suggest a hack: substitute request.session with a
 mock object in that view? Would that work?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c26c91e3abb3ea044bd0c4bcbedee1b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20373: Simple Multi-DB read replica unit test raises TransactionManagementError

[Django]

#20373: Simple Multi-DB read replica unit test raises TransactionManagementError
---+--
 Reporter:  TTimo  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Old description:

> (I posted this on the ML initially, but I suspect it's a bug in the
> testing framework. A complete example is attached. Empty unit test, with
> no routers and a read replica DB setup gives a
> TransactionManagementError)
>
> --
>
> I started assessing multi-db support in Django 1.5.1, I'm interested in
> having read replicas and a write master.
>
> I've figured out all the easy stuff: using TEST_MIRROR in the DATABASES
> setting, writing a simple router that splits read and write traffic, all
> according to the documentation. I can run a test server and issue some
> calls manually, but I have not been able to run simple unit tests.
>
> The most simple test I can build fails during _pre_setup() with a
> "TransactionManagementError: Transaction managed block ended with pending
> COMMIT/ROLLBACK"
>
> My databases are MySQL EC2 RDS instances, the replication is working
> fine, the tables are InnoDB etc.
>
> I know there is active development around transaction management code in
> Django lately, so maybe I've stumbled on a bug? I'm attaching a simple
> test setup that should make it easy to reproduce.
>
> Any advice would be greatly appreciated.
>
> Cheers,
> TTimo
>
> ./manage.py test readreplica
> Creating test database for alias 'default'...
> E
> ==
> ERROR: testTest (readreplica.tests.Test)
> --
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py",
> line 240, in __call__
> self._pre_setup()
>   File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py",
> line 462, in _pre_setup
> self._fixture_setup()
>   File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py",
> line 822, in _fixture_setup
> if not connections_support_transactions():
>   File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py",
> line 809, in connections_support_transactions
> for conn in connections.all())
>   File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py",
> line 809, in 
> for conn in connections.all())
>   File "/usr/local/lib/python2.7/dist-
> packages/django/utils/functional.py", line 48, in __get__
> res = instance.__dict__[self.func.__name__] = self.func(instance)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/backends/__init__.py", line 627, in
> supports_transactions
> self.connection.leave_transaction_management()
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/backends/__init__.py", line 319, in
> leave_transaction_management
> "Transaction managed block ended with pending COMMIT/ROLLBACK")
> TransactionManagementError: Transaction managed block ended with pending
> COMMIT/ROLLBACK
>
> --
> Ran 0 tests in 0.084s
>
> FAILED (errors=1)
> Destroying test database for alias 'default'...

New description:

 (I posted this on the ML initially, but I suspect it's a bug in the
 testing framework. A complete example is attached. Empty unit test, with
 no routers and a read replica DB setup gives a TransactionManagementError)

 --

 I started assessing multi-db support in Django 1.5.1, I'm interested in
 having read replicas and a write master.

 I've figured out all the easy stuff: using TEST_MIRROR in the DATABASES
 setting, writing a simple router that splits read and write traffic, all
 according to the documentation. I can run a test server and issue some
 calls manually, but I have not been able to run simple unit tests.

 The most simple test I can build fails during _pre_setup() with a
 "TransactionManagementError: Transaction managed block ended with pending
 COMMIT/ROLLBACK"

 My databases are MySQL EC2 RDS instances, the replication is working fine,
 the tables are InnoDB etc.

 I know there is active development around transaction management code in
 Django lately, so maybe I've stumbled on a bug? I'm attaching a simple
 test setup that should make it easy to reproduce.

 Any advice would be greatly appreciated.

 Cheers,
 TTimo

 {{{
 ./manage.py test 

Re: [Django] #20373: Simple Multi-DB read replica unit test raises TransactionManagementError

[Django]

#20373: Simple Multi-DB read replica unit test raises TransactionManagementError
---+--
 Reporter:  TTimo  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.5
 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 aaugustin):

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


Comment:

 After changing the settings file to:

 {{{
 SECRET_KEY='oh hay this is a test'

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql',
 'NAME': 'django_test',
 'USER': 'root',
 },
 'slave': {
 'ENGINE': 'django.db.backends.mysql',
 'NAME': 'django_other',
 'USER': 'root',
 # https://docs.djangoproject.com/en/dev/topics/testing/advanced
 /#topics-testing-masterslave
 'TEST_MIRROR' : 'default',
 },
 }

 INSTALLED_APPS = ['readreplica']
 }}}

 The example works for me on Django 1.7:

 {{{
 (django-dev)myk@mYk readreplica % ./manage.py test --settings=settings
 ~/Documents/dev/django/readreplica
 Creating test database for alias 'default'...
 testTest
 .
 --
 Ran 1 test in 0.054s

 OK
 Destroying test database for alias 'default'...
 }}}

 Since this was reopened anonymously there's nothing we can do about 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.981f5bb045c5c79b941ba144da9c8b9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21966: Incorrect usage of constraint_checks_disabled in tests

[Django]

#21966: Incorrect usage of constraint_checks_disabled in tests
---+--
 Reporter:  wlodek |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  master
 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 aaugustin):

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


Comment:

 Indeed, `constraint_checks_disabled` and related APIs exist only because
 MySQL is unable to defer constraints checks until transaction commit. See
 #3615 for details.

 I read your description a few times and I don't understand what your
 proposal actually is. Maybe you could take this to the
 DevelopersMailingList?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.b6536b4407eada3da874896ecd28a18c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22259: Per row result for dumpdata

[Django]

#22259: Per row result for dumpdata
-+-
 Reporter:  Gwildor  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Someday/Maybe
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Overall the idea makes sense but we cannot accept this ticket without a
 plan to address the backwards-incompatibility. Remember that dumpdata
 output may be read by tools other by Django.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.daffa235397c93621a7fcb00d8dcd013%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22078: views.Feed methods cannot be decorated

[Django]

#22078: views.Feed methods cannot be decorated
-+
 Reporter:  tyrion   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.syndication  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

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


Comment:

 Yes, that code is fragile.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.bbcd80d5045caad02dacd7800d333742%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21837: auth.User Email - non-RFC spec normalization

[Django]

#21837: auth.User Email - non-RFC spec normalization
-+-
 Reporter:  ross@…   |Owner:  erikr
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  authentication,  | Triage Stage:  Accepted
  email, filter, get, error  |  Needs documentation:  0
  nlsprint14 |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Erik, did you have a plan for this?

 I'm wondering why we bother with normalize_email. Can't we simply drop 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.1d7dd5b385d4569a63b1511addc2ca63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22226: Reversing admin URLs requires undocumented filter admin_urlquote.

[Django]

#6: Reversing admin URLs requires undocumented filter admin_urlquote.
---+
 Reporter:  mattias|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4ee8c9d18bdc9bc9dfceb474f59260c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22258: Show progress during dumpdata and loaddata

[Django]

#22258: Show progress during dumpdata and loaddata
-+-
 Reporter:  Gwildor  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.72770d7b40cdcc3b4ede5f6ea562e293%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21906: dumpdata should not use router.allow_syncdb

[Django]

#21906: dumpdata should not use router.allow_syncdb
-+-
 Reporter:  yscumc   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.5
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Currently, the documentation for `allow_syncdb` says:

 > This method can be used to determine the availability of a model on a
 given database.

 I don't think that's entirely correct. `allow_syncdb` / `allow_migrate`
 controls on which databases `syncdb` / `migrate` will create the tables.
 In a master - slave setup where the replication mechanism propagates DDL
 statements, `allow_syncdb` should return `True` for the master and `False`
 for the slave; however, the model is available on both databases. I
 believe the documentation of `allow_syncdb` / `allow_migrate` should be
 changed.

 Furthermore, the fix for #13308 was a bit simplistic. The goal is to
 prevent `./manage.py dumpdata --database=...` to fail when only a few
 models don't exist in that database. There must be a better way to achieve
 that.

 With the current database router API, all `dumpdata` and `loaddata` can do
 with router information is check `db_for_read` and `db_for_write` to
 determine which database to use by default for each model. Most likely the
 ORM already does this automatically.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a68b481f0a0b913b4b3bd2a8e62d2f80%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22274: better tutorial for geodjango

[Django]

#22274: better tutorial for geodjango
-+
 Reporter:  digi_c@… |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => New feature
 * needs_tests:   => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.ca9c899b178e5a986e266a243570b46e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22263: KeyError: 'to' in MigrationAutodetector with uncommon rel.to setup (django-taggit)

[Django]

#22263: KeyError: 'to' in MigrationAutodetector with uncommon rel.to setup 
(django-
taggit)
+
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d72d523bc16ac48a6f568226e40cd19a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22243: migrate raises IndexError when getting parent from self.graph

[Django]

#22243: migrate raises IndexError when getting parent from self.graph
---+--
 Reporter:  mszamot@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 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 aaugustin):

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


Old description:

> After deleting south migrations (I move from Django 1.6) and using
> ./manage.py makemigrations the ./manage.py migrate raises an error.  Here
> is the full traceback:
>
> Traceback (most recent call last):
>   File "./manage.py", line 7, in 
> execute_from_command_line(sys.argv)
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/core/management/__init__.py",
> line 427, in execute_from_command_line
> utility.execute()
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/core/management/__init__.py",
> line 419, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/core/management/base.py",
> line 288, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/core/management/base.py",
> line 337, in execute
> output = self.handle(*args, **options)
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/core/management/commands/migrate.py",
> line 62, in handle
> executor = MigrationExecutor(connection,
> self.migration_progress_callback)
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/db/migrations/executor.py",
> line 14, in __init__
> self.loader = MigrationLoader(self.connection)
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/db/migrations/loader.py",
> line 48, in __init__
> self.build_graph()
>   File
> "/home/coot/webapps/social_feel/venv/src/django/django/db/migrations/loader.py",
> line 229, in build_graph
> parent = list(self.graph.root_nodes(parent[0]))[0]
> IndexError: list index out of range

New description:

 After deleting south migrations (I move from Django 1.6) and using
 ./manage.py makemigrations the ./manage.py migrate raises an error.  Here
 is the full traceback:

 {{{
 Traceback (most recent call last):
   File "./manage.py", line 7, in 
 execute_from_command_line(sys.argv)
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/core/management/__init__.py",
 line 427, in execute_from_command_line
 utility.execute()
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/core/management/__init__.py",
 line 419, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/core/management/base.py",
 line 288, in run_from_argv
 self.execute(*args, **options.__dict__)
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/core/management/base.py",
 line 337, in execute
 output = self.handle(*args, **options)
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/core/management/commands/migrate.py",
 line 62, in handle
 executor = MigrationExecutor(connection,
 self.migration_progress_callback)
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/db/migrations/executor.py",
 line 14, in __init__
 self.loader = MigrationLoader(self.connection)
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/db/migrations/loader.py",
 line 48, in __init__
 self.build_graph()
   File
 
"/home/coot/webapps/social_feel/venv/src/django/django/db/migrations/loader.py",
 line 229, in build_graph
 parent = list(self.graph.root_nodes(parent[0]))[0]
 IndexError: list index out of range
 }}}

--

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.3c62f1a79a2a9adb5738af58ef2c9241%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22277: migrations: a migration that depends on itself causing

[Django]

#22277: migrations: a migration that depends on itself causing
-+-
 Reporter:  Marcin Szamotulski   |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  master
Component:  Migrations   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/096.9af6d9958eb34c1eed2781d0256711df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22279: AttributeError: 'db.backends.dummy.base.DatabaseWrapper' object has no attribute 'Database'

[Django]

#22279: AttributeError: 'db.backends.dummy.base.DatabaseWrapper' object has no
attribute 'Database'
-+-
 Reporter:  blueyed  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c1e03d9009db9d542cc523102cbabe22%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17802: Pass the request down to the Sitemap callable

[Django]

#17802: Pass the request down to the Sitemap callable
--+--
 Reporter:  rm_   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sitemaps  |  Version:  master
 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 aaugustin):

 Comments 2 and 3 look like they belong to #15089. The problem here isn't
 sitemaps, it's multi-tenancy -- and it's a hard problem.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.1aa27c19232b2a498a13d82425ff6301%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22102: Wrong test ordering

[Django]

#22102: Wrong test ordering
---+
 Reporter:  aptiko |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ae3e0da72eeaa521fa6bebd5a0c7cfcf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22079: TestClient serialization of POST params with empty list as value

[Django]

#22079: TestClient serialization of POST params with empty list as value
-+-
 Reporter:   |Owner:  nobody
  code.djangoproject.com@…   |   Status:  new
 Type:  Bug  |  Version:  master
Component:  Testing framework|   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 aaugustin):

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


Comment:

 As noted on the pull request, we may want to fix GET rather than POST.

 In any case, they should behave similarly.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/093.252dfc82a6f50d67bebe8becd02db49a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22261: Wrong Permalink for flatpages

[Django]

#22261: Wrong Permalink for flatpages
---+
 Reporter:  allo@… |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.flatpages  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

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


Comment:

 The implementation is intended to match the catchall middleware.

 We could try reversing and only if that fails fall back to the current
 logic.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.dbdd416c33f956dfb66af83fd712bc1b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22257: Write to specified file for dumpdata

[Django]

#22257: Write to specified file for dumpdata
-+-
 Reporter:  Gwildor  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Yes, that makes sense.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0ec49d3b8d8c3999c3991995d42d8207%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22231: Subdomain support in Sitemaps

[Django]

#22231: Subdomain support in Sitemaps
--+--
 Reporter:  anilashanbhag@…   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sitemaps  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 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 aaugustin):

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


Comment:

 This isn't an API, it's a hack.

 Generally speaking, I'm not convinced that django.contrib.sitemaps should
 attempt to do this. Django has a fairly strong assumption that a single
 instance serves a single domain. The current excepted way to serve
 multiple domains is with multiple instances and django.contrib.sites.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/081.e18f9468167469f3b0ee9dc3f18e8524%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21602: FileSystemStorage._save() Should Save to a Temporary Filename and Rename to Attempt to be Atomic

[Django]

#21602: FileSystemStorage._save() Should Save to a Temporary Filename and 
Rename to
Attempt to be Atomic
--+
 Reporter:  kevinastone   |Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  File uploads/storage  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Alex):

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


Comment:

 Agreed that atomic rename should be used.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.37f72aaf5ed2c84214612f63211ec711%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22291: transactions.atomic (with savepoints) doesn't work correctly with deadlocks in mysql

[Django]

#22291: transactions.atomic (with savepoints) doesn't work correctly with 
deadlocks
in mysql
-+-
 Reporter:  err  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  needsinfo
 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 aaugustin):

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


Comment:

 I assume Django raises an exception when trying to rollback to the
 savepoint that no longer exists, which eventually leads to the entire
 transaction being rolled back. This appears to be the correct behavior.

 What do you suggest Django should do instead?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.7f1a5e475703a781c3814cfb70cb0d3c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22280: "Conflicting models in application" RuntimeError for same model with different paths

[Django]

#22280: "Conflicting models in application" RuntimeError for same model with
different paths
--+--
 Reporter:  blueyed   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:  app-loading   | Triage Stage:  Unreviewed
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:   => needsinfo


Comment:

 Closing again, because I don't think there's a bug in Django. I will to
 investigate more if you can provide a minimal project exhibiting this
 issue. 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c02e88a858d720534e68b7d65578f430%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22295: admin/base.html only shows #user-tools when user is staff

[Django]

#22295: admin/base.html only shows #user-tools when user is staff
-+-
 Reporter:  wouter@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  user-tools admin |  Unreviewed
  base template  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Yes, option 2 sounds like a better approach if the goal is simply to hide
 this block.

 But what about people who extend this template and rely on the current
 implementation to hide the block?

 Even for small things, it's important to consider backwards compatibility.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.cb8ceaabb514a6560a9bde1b405c3774%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21379: class AbstractUser: validators should compile re with Unicode

[Django]

#21379: class AbstractUser: validators should compile re with Unicode
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Alex):

 * stage:  Unreviewed => Accepted


Comment:

 The behavior difference between py2 and py3 is clearly a bug, not sure
 which fix is correct.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.4b0409c950beac60bc99bc202be0c0cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #12118: in-memory test database does not work with threads

[Django]

#12118: in-memory test database does not work with threads
-+-
 Reporter:  bluebird75   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  threads  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Alex):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.e8a0ab3b4f1a9ee22768c66ee95f7dd9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22293: ERROR: relation "app_taggedcountryoforigin" already exists

[Django]

#22293: ERROR: relation "app_taggedcountryoforigin" already exists
+
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 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):

 * stage:  Unreviewed => Accepted


Comment:

 taggit is known to abuse the internals, but this looks like something
 Django should prevent.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.9a3c29f25a7faa5458bf0fd13c10d98e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #5437: Make GDAL optional for GIS test runner

[Django]

#5437: Make GDAL optional for GIS test runner
-+
 Reporter:  rcoup|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  testing  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Alex):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.4bbe429cb2383596fe7f7a6a256943e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22248: Model renaming doesn't work backwards

[Django]

#22248: Model renaming doesn't work backwards
--+
 Reporter:  andrewgodwin  |Owner:  andrewgodwin
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.8ffe1664ffbcd27100dc5d5540570cc4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22296: m2m_changed pk_set value inconsistent between post_add and post_remove (was: Documentation clarification: m2m_changed pk_set inconsistent between post_add and post_remove)

[Django]

#22296: m2m_changed pk_set value inconsistent between post_add and post_remove
---+--
 Reporter:  anentropic |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.5
 Severity:  Normal |   Resolution:
 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 anentropic):

 * needs_better_patch:   => 0
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.6bcb2b36ead7c3e9e36a376a7169e3e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22296: Documentation clarification: m2m_changed pk_set inconsistent between post_add and post_remove

[Django]

#22296: Documentation clarification: m2m_changed pk_set inconsistent between
post_add and post_remove
---+
 Reporter:  anentropic |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 the docs say:

 "`pk_set`: For the pre_add, post_add, pre_remove and post_remove actions,
 this is a set of primary key values that have been added to or removed
 from the relation."

 What I found is that for `action=='post_add'`:
 - first time `add(x)` -> `set([x])`
 - next time (same `x`) `add(x)` -> `set([])`

 but for `action=='post_remove'`:
 - first time `remove(x)` -> `set([x])`
 - next time (same `x`) `remove(x)` -> `set([x])`

 I feel like they should be consistent. Either way is fine but the
 behaviour of `post_add` seems more useful to me (can avoid unnecessary
 action in your signal receiver)... but it should be documented that you
 get empty set if nothing needed adding.

 I've only tried on 1.5 so far but looking at source I don't see any new
 code to change this behaviour
 
https://github.com/django/django/blob/master/django/db/models/fields/related.py#L1032

 Whereas it looks like the add method has code to deliberately exclude
 already added items
 
https://github.com/django/django/blob/master/django/db/models/fields/related.py#L1008

 I'm happy to make a patch if it's felt this is useful?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.e4e350121d004ded4e031c47656f94c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 0cf158: Fixed a small collection of flake8 violations that...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0cf158cf9ac6f4d03faf8b72a71bf1d06ad8503e
  
https://github.com/django/django/commit/0cf158cf9ac6f4d03faf8b72a71bf1d06ad8503e
  Author: Alex Gaynor 
  Date:   2014-03-20 (Thu, 20 Mar 2014)

  Changed paths:
M tests/model_forms/tests.py

  Log Message:
  ---
  Fixed a small collection of flake8 violations that had snuck in


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/532b25c63d16a_60431095d3464286%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22289: Field with Validator always considered changed in migrations

[Django]

#22289: Field with Validator always considered changed in migrations
+---
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7-alpha-2
 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 bmispelon):

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


Comment:

 I'm also unabled to reproduce this (tried sqlite and postgres).

 I did make one change compared to the models you provided: I replaced
 `TimeStampedModel` with a regular `models.Model`.
 So maybe the problem is in `TimeStampedModel`?

 On a sidenote, compiled regexp don't implement `__eq__` in python, so two
 different regexp objects will always be different, even if they use the
 same `pattern` and `flags`.

 I'll close this as `needsinfo`. Can you reopen with either the full
 definition of `TimestampedModel` or a fully contained testcase (something
 that doesn't use external models)?

 Thanks.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.023c2ab8ec1d61be2aff66129010909f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22249: Cannot resolve keyword '' into field. Choices are:...

[Django]

#22249: Cannot resolve keyword '' into field. Choices are:...
--+--
 Reporter:  srnsht@…  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.6
 Severity:  Normal|   Resolution:  worksforme
 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 bmispelon):

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


Comment:

 Hi,

 Using the provided models (I also defined an empty `Tag` model and I
 assumed `User` referred to `auth.User`), I cannot reproduce the issue.

 I tried both on master and on 1.6.

 Could you provide more information on how you're able to trigger this
 error?
 Thanks.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.998b166b94acd55e540c4a24b14ceb8b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22268: values_list() on a ManyToManyField returns extra None's when iterated over.

[Django]

#22268: values_list() on a ManyToManyField returns extra None's when iterated 
over.
-+-
 Reporter:  k_sze|Owner:
 Type:  Bug  |  anubhav9042
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  orm, values_list,| Triage Stage:  Accepted
  ManyToManyField|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anubhav9042):

 In the diff, the added lines are in red color..

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.d3c56f0905a8334f0427d57fb63676ae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22268: values_list() on a ManyToManyField returns extra None's when iterated over.

[Django]

#22268: values_list() on a ManyToManyField returns extra None's when iterated 
over.
-+-
 Reporter:  k_sze|Owner:
 Type:  Bug  |  anubhav9042
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  orm, values_list,| Triage Stage:  Accepted
  ManyToManyField|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anubhav9042):

 According to me the query generated for
 {{{Class.objects.values('available_in_languages', 'students')}}}:
 {{{
 SELECT `tic_22268_class_available_in_languages`.`language_id`,
 `tic_22268_class_students`.`student_id` FROM `tic_22268_class` LEFT OUTER
 JOIN `tic_22268_class_available_in_languages` ON (`tic_22268_class`.`id` =
 `tic_22268_class_available_in_languages`.`class_id`) LEFT OUTER JOIN
 `tic_22268_class_students` ON (`tic_22268_class`.`id` =
 `tic_22268_class_students`.`class_id`)
 }}}

 is correct as it yield the following result
 {{{
 language_id student_id
 NULL   1
 NULL   NULL
 1  1
 1  2
 2  1
 2  2
 }}}

 Although the result is correct as we want combination of
 `available_in_languages` and `students` for `Class` objects. However it is
 confusing.
 I propose the following:
 Whenever there is a case of M2M in values() or values_list(), we could
 introduce additional `id` into the query, which will help in making the
 result meaningful and understandable.

 We make the query into:
 {{{
 SELECT `tic_22268_class_available_in_languages`.`language_id`,
 `tic_22268_class_students`.`student_id`, `tic_22268_class_students`.`id`
 FROM `tic_22268_class` LEFT OUTER JOIN
 `tic_22268_class_available_in_languages` ON (`tic_22268_class`.`id` =
 `tic_22268_class_available_in_languages`.`class_id`) LEFT OUTER JOIN
 `tic_22268_class_students` ON (`tic_22268_class`.`id` =
 `tic_22268_class_students`.`class_id`)
 }}}

 resulting in
 {{{
 language_id student_id  id
 NULL  1  1
 NULL   NULL NULL
 1 1 2
 1 2 3
 2 1 2
 2 2 3
 }}}

 The output also becomes:
 {{{
 [{'students': 1L, 'available_in_languages': None, 'id': 1L},
 {'students': None, 'available_in_languages': None, 'id': 2L},
 {'students': 1L, 'available_in_languages': 1L, 'id': 3L}, {'students': 2L,
 'available_in_languages': 1L, 'id': 3L}, {
 'students': 1L, 'available_in_languages': 2L, 'id': 3L}, {'students': 2L,
 'available_in_languages': 2L, 'id': 3L}]
 }}}
 }}}

 Now the result is as required, since we wanted the combination of values:
 'available_in_languages' and 'students' along with 'id' of the `Class`
 object to which it belongs.

 I am adding a diff.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.aad4ccbb68af2885792151398b9c7114%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15049: Using annotation before and after filter gives wrong results

[Django]

#15049: Using annotation before and after filter gives wrong results
-+-
 Reporter:  Alex |Owner:  anonymous
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by terpsquared):

 Just ran into this. At the very least, the documentation should be updated
 to reflect this issue.

 https://docs.djangoproject.com/en/dev/topics/db/aggregation/#order-of-
 annotate-and-filter-clauses

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.022ac00bb05b2525073c438710e0f23f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22288: F() expression not compatible with __range field look up

[Django]

#22288: F() expression not compatible with __range field look up
-+-
 Reporter:  liushaohua86@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * version:  1.5 => master
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 I can reproduce this issue on latest master as well as on 1.6 so it
 doesn't appear to be related to the new custom lookup feature.

 Regarding your formatting issues, you can make code blocks on trac using
 `{{{ code goes here }}}`, as explained on the WikiFormatting page.

 Thanks.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.a507b616740c706fd654f88ce660c11a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22294: length filter changes type of output to string if passed safe string

[Django]

#22294: length filter changes type of output to string if passed safe string
--+
 Reporter:  steve.pike@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  filter safe   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.5 => master
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 I agree that this behavior is not obvious and could lead to hard-to-debug
 issues.

 I don't really see a reason why `length` needs `is_safe=True`, since it
 should normally return either integers, or an empty string in case of an
 error.

 In fact, making this change doesn't seem to break any existing test which
 is a good sign.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/086.82bf9d4f6b9f2fb4f8d5e98651c155eb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22295: admin/base.html only shows #user-tools when user is staff

[Django]

#22295: admin/base.html only shows #user-tools when user is staff
-+-
 Reporter:  wouter@… |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  master
Component:  contrib.admin|   Keywords:  user-tools admin base
 Severity:  Normal   |  template
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 The build-in Django Admin ships with the admin/base.html template. This
 template is, among other things, responsible for rendering the #user-tools
 div that contains the 'log out' and 'change password' buttons. The user
 tools are only rendered if user.is_active and user.is_staff are True, see:
 
https://github.com/django/django/blob/2bc51438664b5ffbbd1430b4f9f3307f18b2b9db/django/contrib/admin/templates/admin/base.html#L27

 This check makes sure that #user-tools is only rendered when the user is
 actually authenticated for use of the admin. This is required because the
 login template (admin/login.html) eventually inherits from
 admin/base.html. If the check would be omitted, the #user-tools would
 become visible if the user was yet to be authenticated resulting in a
 situation where the user could 'log out' without being 'logged in' first.

 This check is therefore relevant, but is it the wrong check and breaks
 inheritance in the following case:

 Lets say you want to inherit from django.contrib.admin.sites.BaseSite to
 create a customized admin for special users that are not necessarily staff
 members. You can override the BaseSite.has_permission method. Currently
 this method holds the condition: {{{ request.user.is_active and
 request.user.is_staff }}}. You might change this to {{{
 request.user.is_active and request.user.is_a_special_user_but_not_staff
 }}}. This user would now be allowed to access this customised admin
 without having access to the default admin.

 The problem is that the user cannot log out from this special admin
 because the #user-tools are only rendered if the user is a staff member.

 I can think of two solutions:
 1. Use the BaseAdmin.has_permission to do this check
 2. Create a block called user-tools in the template and override this
 block in the admin/login.html to be empty

 In my opinion solution number 2 would be the best 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.2708b299d88928c90950bdd4f553919e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21695: Allow blocktrans to set a context variable

[Django]

#21695: Allow blocktrans to set a context variable
-+--
 Reporter:  mitar|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by bmihelac):

 Here is a link to branch that  implements this feature and two simple
 tests:

 https://github.com/bmihelac/django-1/compare/fix-21695-allow-blocktrans-
 to-set-a-context-variable?expand=1

 Please note that assigning option is named `asvar` contrary to usual `as`
 to avoid confusion between legacy format for using `with`.

 If there is interest in merging this I will add docs and changelog and any
 more tests if needed.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.91a6085244386c1c7550ba2daf84d151%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22289: Field with Validator always considered changed in migrations

[Django]

#22289: Field with Validator always considered changed in migrations
+---
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7-alpha-2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+---

Comment (by erikr):

 Perhaps, but then I still find it suspicious that the tests work for you,
 and that it seems to work for me. Could you publish a small demo
 somewhere, which replicates the problem for you? Preferably with SQLite,
 assuming you can replicate the problem with that. Then I can see whether I
 can reproduce this myself somehow.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.db0507a3e5c2d384aa182d41a4b5263b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22290: Forms DateField show_hidden_initial USE_L10N = False and custom DATE_INPUT_FORMATS

[Django]

#22290: Forms DateField show_hidden_initial USE_L10N = False and custom
DATE_INPUT_FORMATS
-+-
 Reporter:  dibrovsd@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  DateField USE_L10N   |  worksforme
  hidden_initial DATE_INPUT_FORMATS  | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

 * resolution:  needsinfo => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.803f179ef7d4a75a5c2e491f0a431a4f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21952: Deadlock while dispatching signals

[Django]

#21952: Deadlock while dispatching signals
-+
 Reporter:  edevil   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.6
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  signal deadlock  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by apollo13):

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


Comment:

 Since the original report is fixed, this should stay as fixed. Please open
 a new ticket with a patch, as I said before I ran into to many issues
 while backporting 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.4699e124e821900019e524d84034dfdb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21952: Deadlock while dispatching signals

[Django]

#21952: Deadlock while dispatching signals
-+
 Reporter:  edevil   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  signal deadlock  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by edevil):

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


Comment:

 Since it is reproducible in CPython, maybe 1.6 (current latest version)
 should be patched as well.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e1a47a4e193b745317f3058b9595dab2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22290: Forms DateField show_hidden_initial USE_L10N = False and custom DATE_INPUT_FORMATS

[Django]

#22290: Forms DateField show_hidden_initial USE_L10N = False and custom
DATE_INPUT_FORMATS
-+-
 Reporter:  dibrovsd@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  DateField USE_L10N   | Triage Stage:
  hidden_initial DATE_INPUT_FORMATS  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by dibrovsd@…):

 now i cannot reproduce too.
 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.f6fe1186b9ddec1826dd103f32de79cc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22294: length filter changes type of output to string if passed safe string

[Django]

#22294: length filter changes type of output to string if passed safe string
-+-
 Reporter:  steve.pike@… |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Template system  |Version:  1.5
 Severity:  Normal   |   Keywords:  filter safe
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+-
 if you do:

 {{{
 {% if some_string|length > 123 %}
 Hurrah!
 {% endif %}
 }}}

 what happens is what you expect to happen - the length of the string is
 determined and compared to the integer given in the condition.

 However if you do this:

 {{{
 {% if some_safe_string|length > 123 %}
 Booo!
 {% endif %}
 }}}

 Then the result is non obvious, since passing a safe_string to length
 results in the output also being marked safe and thus changed into a safe
 *string*... on which you cannot do simple comparisons to integers in this
 way... (see: https://docs.djangoproject.com/en/dev/howto/custom-template-
 tags/#filters-and-auto-escaping and
 
https://github.com/django/django/blob/master/django/template/defaultfilters.py#L581
 )

 This seems like a bug rather than a feature, but since the type of the
 result of the length filter is not stated in the docs (
 https://docs.djangoproject.com/en/1.5/ref/templates/builtins/#length )
 this is really misleading.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.44787aea9b536ab6f5cdb78c1f3ea010%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 3ecc25: Removed a file accidentally added in 81f5408c7a16b...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3ecc25bd587d10f16831d6d1939ec7c758fc90c4
  
https://github.com/django/django/commit/3ecc25bd587d10f16831d6d1939ec7c758fc90c4
  Author: Baptiste Mispelon 
  Date:   2014-03-20 (Thu, 20 Mar 2014)

  Changed paths:
R django:master...bak1an:ticket_22275.diff

  Log Message:
  ---
  Removed a file accidentally added in 81f5408c7a16b8c79053950f05fe7a873506ca55.


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/532ab7574c986_6c299cdd44101b2%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21695: Allow blocktrans to set a context variable

[Django]

#21695: Allow blocktrans to set a context variable
-+--
 Reporter:  mitar|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 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 bmihelac):

 * cc: bmihelac@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c29ad824f26c5234d588d0b0ab4042c1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22290: Forms DateField show_hidden_initial USE_L10N = False and custom DATE_INPUT_FORMATS

[Django]

#22290: Forms DateField show_hidden_initial USE_L10N = False and custom
DATE_INPUT_FORMATS
-+-
 Reporter:  dibrovsd@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.6
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  DateField USE_L10N   | Triage Stage:
  hidden_initial DATE_INPUT_FORMATS  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 I cannot reproduce that issue, see the test I'm attaching.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.be4dfd4c6fbdcdc27dbe60189f991a5f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22289: Field with Validator always considered changed in migrations

[Django]

#22289: Field with Validator always considered changed in migrations
+---
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7-alpha-2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+---

Comment (by blueyed):

 btw: the tests in `tests/validators` work fine, and they also compare
 RegexValidator instances.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e873f0e6d07976ea8d75397c043737db%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22289: Field with Validator always considered changed in migrations

[Django]

#22289: Field with Validator always considered changed in migrations
+---
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7-alpha-2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+---

Comment (by blueyed):

 Compiled patterns (_sre.SRE_Pattern) are considered to equal/identical for
 the same pattern (from ipyhon shell).

 RegexValidator's `__eq__` only tests for `==` for the SRE_Pattern, which
 fails in my case:

 {{{
 ipdb> v1.regex
 <_sre.SRE_Pattern object at 0x1b0e470>
 ipdb> _v2.regex
 <_sre.SRE_Pattern object at 0x2abbdd0>
 ipdb> _v1.regex == _v2.regex
 False
 ipdb> _v1.regex.
 _v1.regex.findall _v1.regex.flags   _v1.regex.groups
 _v1.regex.pattern _v1.regex.search  _v1.regex.sub
 _v1.regex.finditer_v1.regex.groupindex  _v1.regex.match
 _v1.regex.scanner _v1.regex.split   _v1.regex.subn
 ipdb> _v1.regex.pattern
 '(?i)^(?:(?:https?://)?www.imdb.com/title/)?(tt\\d+)(?:/.*)?$'
 ipdb> _v2.regex.pattern
 '(?i)^(?:(?:https?://)?www.imdb.com/title/)?(tt\\d+)(?:/.*)?$'
 ipdb> _v2.regex.flags
 2
 ipdb> _v1.regex.flags
 2
 ipdb> pprint(_v1)
 
 ipdb> pprint(_v1.__dict__)
 {'_constructor_args':
 (('(?i)^(?:(?:https?://)?www.imdb.com/title/)?(tt\\d+)(?:/.*)?$',),
{}),
  'regex': <_sre.SRE_Pattern object at 0x1b0e470>}
 ipdb> pprint(_v2.__dict__)
 {'_constructor_args':
 (('(?i)^(?:(?:https?://)?www.imdb.com/title/)?(tt\\d+)(?:/.*)?$',),
{}),
  'regex': <_sre.SRE_Pattern object at 0x2abbdd0>}
 }}}

 Maybe `RegexValidator.__eq__` needs to get enhanced, to compare the
 relevant regex attributes?

 I am using Python 2.7.5+ (Ubuntu Linux), on a 64bit.
 Something must causing the SRE_Pattern objects to not get re-used in my
 case.


 {{{
 (full output of all attributes:
 ipdb> [_v1.regex.__getattribute__(x) for x in ['findall', 'finditer',
 'flags', 'groupindex', 'groups', 'match', 'pattern', 'scanner', 'search',
 'split', 'sub', 'subn']]
 [,
 , 2, {},
 1, ,
 '(?i)^(?:(?:https?://)?www.imdb.com/title/)?(tt\\d+)(?:/.*)?$', , , , , ]

 ipdb> [_v2.regex.__getattribute__(x) for x in ['findall', 'finditer',
 'flags', 'groupindex', 'groups', 'match', 'pattern', 'scanner', 'search',
 'split', 'sub', 'subn']]
 [,
 , 2, {},
 1, ,
 '(?i)^(?:(?:https?://)?www.imdb.com/title/)?(tt\\d+)(?:/.*)?$', , , , , ]
 )
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c75d98d40a6101b4b17757200afc394e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22109: clarify difference between relative and absolute STATIC_URL

[Django]

#22109: clarify difference between relative and absolute STATIC_URL
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  static_url,static|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by cjerdonek):

 I can try to find time to come up with a patch.  In the meantime, to say a
 little more about what I'm getting at, it turns out that the point I was
 trying to raise in this issue is discussed in the Django documentation,
 though not in the `STATIC_URL` documentation itself (which is supposed to
 contain details about the setting).  Namely, the point is discussed
 [https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/ here] in
 the "The staticfiles app" section.  For example, it says, "This helper
 function will only work if `DEBUG` is `True` and your `STATIC_URL` setting
 is neither empty nor a full URL such as http://static.example.com/.;

 In other words, the functionality I'm referencing only becomes enabled
 when `STATIC_URL` is a relative URL reference (i.e. does not contain the
 host name, etc).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ba3eb3622a3892868d78da66ab6cc6b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22289: Field with Validator always considered changed in migrations

[Django]

#22289: Field with Validator always considered changed in migrations
+---
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7-alpha-2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+---

Comment (by erikr):

 I used SQLite, not PostgreSQL, but I strongly doubt that this is a
 database-specific issue: validators aren't actually stored in the
 database, as far as I know.

 Regarding comment:5: it makes sense that the instances might be two
 different ones, that's why there's a custom `__eq__`. The `__eq__` you're
 looking at doesn't seem to be the right one, when comparing these two
 tuples, it should call `__eq__` of `RegexValidator`. I notice that in
 there, it compares `self.regex`, which at that point is a compiled regex,
 not the original string. So the next step would be to look into whether,
 in your case, `RegexValidator.__eq__` says they are not equal, and why.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.457752889e29813f763e06ae372dc161%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22286: TypedChoiceField rejects valid input with coerce=float

[Django]

#22286: TypedChoiceField rejects valid input with coerce=float
+--
 Reporter:  johnnybrown7@…  |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Uncategorized   |  Version:  1.5
 Severity:  Normal  |   Resolution:  worksforme
 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 russellm):

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


Comment:

 The logic around to_python and TypedChoiceField was changed in a0f3eecc in
 response to #21397. The behaviour you describe is no longer present.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.a57fa897c90374a74932a8eafc5ff850%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.