[Django] #27613: BaseInlineFormSet is validating form for extra forms

[Django]

#27613: BaseInlineFormSet is validating form for extra forms
---+-
   Reporter:  Sonu kumar   |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Forms|Version:  1.10
   Severity:  Release blocker  |   Keywords:  FormSet
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+-
 {{{
 class ExplanationFormSet(BaseInlineFormSet):
 def clean(self):
 super(ExplanationFormSet, self).clean()
 for form in self.forms:
 if not hasattr(form, 'cleaned_data'):
 continue
 data = form.cleaned_data
 if data.get('description') is None or data.get('description')
 == "":
 continue

 if data.get('user') == None:
 raise ValidationError("Explanation Author is required")

 @python_2_unicode_compatible
 class Explanation(models.Model):
 user = models.ForeignKey(User)
 question = models.ForeignKey(Question)
 description = models.TextField()
 creation = models.DateTimeField(auto_now_add=True)
 last_change = models.DateTimeField(auto_now_add=True)
 past_explanation = models.ForeignKey('self', on_delete=models.CASCADE,
  db_constraint=False, blank=True,
  default=-1, null=True)
 valid = models.BooleanField(default=False)

 def __str__(self):
 return str(self.description[:40])

 class ExplanationInline(TabularInline):
 model = Explanation
 formset = ExplanationFormSet
 extra = 1

 @register(Question)
 class QuestionAdmin(ModelAdmin):
 inlines = [
 ItemInline,
 ExplanationInline,
 ]
 list_filter = ['multiple_correct', 'timestamp','field__field_name',
'field__subfield_name' ]
 exclude = ('timestamp',)
 date_hierarchy = 'timestamp'
 search_fields = ['header']

 }}}


 Problem:

 When Question is edited in admin panel then it always throws an error for
 one additional form added at last. Form throws the error for all fields
 whose value(s) are required. This is especially seen for
 ExplanationFormSet.

--
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/050.f95dec40f51c02d660cbbf88557f825b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27392: Remove "Tests that", "Ensures that", etc. from test docstings

[Django]

#27392: Remove "Tests that", "Ensures that", etc. from test docstings
--+
 Reporter:  Tim Graham|Owner:  za
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+

Comment (by Barun Parruck):

 Hi! I was thinking of working on this. Two questions --

 1. Do you want something like "Tests adding a FK constraint for an
 existing column" to go to "Adds foreign key constraint to an existing
 column", or "Foreign key constraint can be added to an existing column".

 2. Secondly, could I create a simple pull request with only ~10 or so
 fixes to get the hang of the development workflow? (To make sure I'm doing
 the right thing!)

--
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.eaf733f97856b9213b1519c619aa8afa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27263: Allow validators to short-circuit in form field validation

[Django]

#27263: Allow validators to short-circuit in form field validation
-+-
 Reporter:  Alexey Rogachev  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  form, validator  | Triage Stage:  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 There isn't any consensus on the [https://groups.google.com/d/topic
 /django-developers/NJ9yOSQrrPE/discussion django-developers thread] or
 here that changes should be made in 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/067.79361c309ed6416254f2944cb6a115a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27470: CSRF context processor never sets NOTPROVIDED

[Django]

#27470: CSRF context processor never sets NOTPROVIDED
---+--
 Reporter:  Nick Sandford  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  CSRF   |  Version:  1.10
 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 Tim Graham):

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


Comment:

 I loaded an admin change form in a tab, then I loaded a 404 page in a
 second tab, then I submitted the form in the first tab and didn't
 encounter a problem. Please reopen with more specific details about how to
 reproduce the issue. 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/064.ab493cc6e9a9a180442e9e1e2a9f0fa5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27182: Some import statement use backslashes instead of parentheses

[Django]

#27182: Some import statement use backslashes instead of parentheses
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Django will adapt as soon as isort fixes
 [https://github.com/timothycrosley/isort/issues/466 the issue]. I don't
 see a need to keep a ticket open for it here.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.6a8d0589b52e80bf2bc587f8f4e9d27a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27580: add special field for storing content types

[Django]

#27580: add special field for storing content types
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 Sergey, could you write to the DevelopersMailingList to get feedback on
 the idea?

--
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.8af26eff2d0972642c6e3379a5701a95%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27597: UrlResolver doesn't check all possibilities

[Django]

#27597: UrlResolver doesn't check all possibilities
--+--
 Reporter:  Adrien mille  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (URLs)   |  Version:  1.10
 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 Tim Graham):

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


Comment:

 Ok, I guess we'll close this for now. If someone wants to offer an
 argument for changing the behavior, please write to the
 DevelopersMailingList. Thanks for investigating, Marten. I created #27612
 for your idea about a system check for unique instance namespaces.

--
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.f1f3ac810b9eadeead0e4df5243cac0a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27612: Add a check that URL instance namespaces are unique across a project

[Django]

#27612: Add a check that URL instance namespaces are unique across a project
+
   Reporter:  Tim Graham|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (System checks)  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 As Marten suggested in ticket:27597#comment:4, "it may be a good idea to
 add a system check that checks if instance namespaces are indeed unique
 across the project."

--
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.de23e39f3b4ae7359d3e5dd11e307dca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27601: BooleanField no longer accepts empty string as False value

[Django]

#27601: BooleanField no longer accepts empty string as False value
-+-
 Reporter:  elpescado|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 Tim Graham):

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


Comment:

 Please reopen if you feel you have some justification for restoring the
 old behavior or mentioning the change in the release notes.

--
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.185fc4010d7eb14fe5c3c311494587a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27477: Use QuerySet.select_for_update() in admin change form to fix race condition

[Django]

#27477: Use QuerySet.select_for_update() in admin change form to fix race 
condition
---+--
 Reporter:  Dave Hall  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 Can you provide a patch so we can get feedback on 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/065.bec8db9d37517c3a2bda628e1b0b8ba9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27534: Add CSRF_COOKIE_HTTPONLY note to CSRF AJAX docs

[Django]

#27534: Add CSRF_COOKIE_HTTPONLY note to CSRF AJAX docs
--+
 Reporter:  Andrew Charles|Owner:  nobody
 Type:  Cleanup/optimization  |   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 Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 The technique of retrieving the CSRF token from a form input is now
 [https://docs.djangoproject.com/en/dev/ref/csrf/#acquiring-the-token-if-
 csrf-use-sessions-is-true documented for a different reason]. I created
 #27611 to remove the check suggesting the use of `CSRF_COOKIE_HTTPONLY`,
 but a brief explanation of the proposed docs with a link to the other
 section seems fine.

--
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.ce3b5f359a0f9c946c5dc61fb9b203ca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27480: Add a Cache.touch(key, timeout=DEFAULT_TIMEOUT) method

[Django]

#27480: Add a Cache.touch(key, timeout=DEFAULT_TIMEOUT) method
-+-
 Reporter:  Victor Porton|Owner:  Nicolas
 |  Noé
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Someday/Maybe


Comment:

 This is blocked on two fixes for python-memcached
 ([https://github.com/linsomniac/python-memcached/pull/107 PR #107],
 [https://github.com/linsomniac/python-memcached/pull/108 PR #108]) so that
 the Django tests can use the latest version (#25277) where `touch()`
 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/065.65a0987dd119b90c4b77e9297cb61871%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27611: Remove check that suggests enabling CSRF_COOKIE_HTTPONLY setting

[Django]

#27611: Remove check that suggests enabling CSRF_COOKIE_HTTPONLY setting
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 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 Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7700 PR]

--
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.53538a670b06bc508b0dd26e82703e11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27611: Remove check that suggests enabling CSRF_COOKIE_HTTPONLY setting

[Django]

#27611: Remove check that suggests enabling CSRF_COOKIE_HTTPONLY setting
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 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 Tim Graham):

 [https://github.com/django/django/pull/7700 PR]

--
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.64c9e00c4598b9ef4e8b82a0432b53a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27611: Remove check that suggests enabling CSRF_COOKIE_HTTPONLY setting

[Django]

#27611: Remove check that suggests enabling CSRF_COOKIE_HTTPONLY setting
-+-
   Reporter:  Tim|  Owner:  Tim Graham
  Graham |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Core   |Version:  master
  (System checks)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 As discussed on [https://groups.google.com/d/topic/django-
 developers/nXjfLd8ba5k/discussion django-developers],
 `settings.CSRF_COOKIE_HTTPONLY` offers no practical benefit, so nudging
 users to activate it isn't 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/052.19e60ee6db3a143df5340d088055aaab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27610: Unexpected behavior on chained filters

[Django]

#27610: Unexpected behavior on chained filters
-+-
 Reporter:  Thomas Recouvreux|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  orm filter   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marten Kenbeek):

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


Comment:

 This is expected and
 [https://docs.djangoproject.com/en/1.10/topics/db/queries/#spanning-multi-
 valued-relationships documented] behaviour:

 > To handle both of these situations, Django has a consistent way of
 processing filter() calls. Everything inside a single filter() call is
 applied simultaneously to filter out items matching all those
 requirements. Successive filter() calls further restrict the set of
 objects, but for multi-valued relations, they apply to any object linked
 to the primary model, not necessarily those objects that were selected by
 an earlier filter() call.

--
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.69c5cfd113de0c38cf32a597e029ace7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27610: Unexpected behavior on chained filters

[Django]

#27610: Unexpected behavior on chained filters
-+-
   Reporter:  Thomas |  Owner:  nobody
  Recouvreux |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  orm filter
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Using Django 1.10.4 with psycopg engine, I got 2 different results
 depending on filter chaining or not.

 How to reproduce :
 {{{
 a = Group.objects.filter(user__date_joined__gte='2016-01-01',
 user__date_joined__lt='2016-03-01').distinct().count()
 b =
 
Group.objects.filter(user__date_joined__gte='2016-01-01').filter(user__date_joined__lt='2016-03-01').distinct().count()
 if a == b:
   print('as expected')
 else:
   print('something went wrong')
 }}}

 Expected result : `a == b`

 Result : `a != b`

 Using --print-sql I managed to extract the generated SQL.

 {{{
 -- SQL for a
 SELECT COUNT(*)
 FROM
   (SELECT DISTINCT "auth_group"."id" AS Col1,
"auth_group"."name" AS Col2
FROM "auth_group"
INNER JOIN "ts_user_usr_groups" ON ("auth_group"."id" =
 "ts_user_usr_groups"."group_id")
INNER JOIN "ts_user_usr" ON ("ts_user_usr_groups"."user_id" =
 "ts_user_usr"."id")
WHERE ("ts_user_usr"."date_joined" <
 '2016-03-01T00:00:00+00:00'::timestamptz
   AND "ts_user_usr"."date_joined" >=
 '2016-01-01T00:00:00+00:00'::timestamptz)) subquery
 }}}


 {{{
 -- SQL for b
 SELECT COUNT(*)
 FROM
   (SELECT DISTINCT "auth_group"."id" AS Col1,
"auth_group"."name" AS Col2
FROM "auth_group"
INNER JOIN "ts_user_usr_groups" ON ("auth_group"."id" =
 "ts_user_usr_groups"."group_id")
INNER JOIN "ts_user_usr" ON ("ts_user_usr_groups"."user_id" =
 "ts_user_usr"."id")
INNER JOIN "ts_user_usr_groups" T4 ON ("auth_group"."id" =
 T4."group_id")
INNER JOIN "ts_user_usr" T5 ON (T4."user_id" = T5."id")
WHERE ("ts_user_usr"."date_joined" >=
 '2016-01-01T00:00:00+00:00'::timestamptz
   AND T5."date_joined" <
 '2016-03-01T00:00:00+00:00'::timestamptz)) subquery
 }}}

 It seems that chaining filters adds an unecessary inner join on the
 ts_user_usr table (`INNER JOIN "ts_user_usr" T5 ON (T4."user_id" =
 T5."id")`).

--
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.fd6434b039576b4f71a544f9d3573718%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27610: Unexpected behavior on chained filters

[Django]

#27610: Unexpected behavior on chained filters
-+-
 Reporter:  Thomas Recouvreux|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm filter   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Thomas Recouvreux):

 * type:  Uncategorized => Bug


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.23a0d359ffd8261be6462b704027b81d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27573: Distance function returns Distance object instead of raw value on MySQL

[Django]

#27573: Distance function returns Distance object instead of raw value on MySQL
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.9
 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 Tim Graham):

 * 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.05f4147f77dfc30ecd394d08627fded1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27600: Support reading commands from stdin in shell command

[Django]

#27600: Support reading commands from stdin in shell command
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 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 Tim Graham):

 * 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/062.94687b69f5965f400e8e7625eabc5be7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27609: gettext_lazy cast to str/unicode errors under py 2.7 if performed after language activation.

[Django]

#27609: gettext_lazy cast to str/unicode errors under py 2.7 if performed after
language activation.
-+-
 Reporter:  rafalp   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  1.10
  checks)|
 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 rafalp):

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


Comment:

 Replying to [comment:2 Claude Paroz]:
 > Do you have a reason to use `gettext_lazy` instead of `ugettext_lazy`?

 Gaah, I'm blind today.

--
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.b9ca58c1dd8cdc0a0d33193215d4c208%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27609: gettext_lazy cast to str/unicode errors under py 2.7 if performed after language activation.

[Django]

#27609: gettext_lazy cast to str/unicode errors under py 2.7 if performed after
language activation.
-+-
 Reporter:  rafalp   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.10
  checks)|
 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 Claude Paroz):

 Do you have a reason to use `gettext_lazy` instead of `ugettext_lazy`?

--
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.febacf114b9bd1a113634fa44db2f95b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27608: Combine simple_tag and assignment_tag

[Django]

#27608: Combine simple_tag and assignment_tag
+--
 Reporter:  Jimmy Merrild Krag  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Template system |  Version:  master
 Severity:  Normal  |   Resolution:  duplicate
 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 Tim Graham):

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


Comment:

 This is done as of Django 1.9 (#18651), and `assignment_tag` is deprecated
 per the [https://docs.djangoproject.com/en/stable/releases/1.9
 /#assignment-tag 1.9 release notes]:

  Django 1.4 added the `assignment_tag` helper to ease the creation of
 template tags that store results in a template variable. The
 `simple_tag()` helper has gained this same ability, making the
 `assignment_tag` obsolete. Tags that use `assignment_tag` should be
 updated to use `simple_tag`.

--
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.c186a9f40d2721cdf3a05f263da1b636%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27609: gettext_lazy cast to str/unicode errors under py 2.7 if performed after language activation. (was: UnicodeEncodeError in check_models_permissions for added unicode verbose name to

[Django]

#27609: gettext_lazy cast to str/unicode errors under py 2.7 if performed after
language activation.
-+-
 Reporter:  rafalp   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.10
  checks)|
 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
-+-
Description changed by rafalp:

Old description:

> I have model in my application that defined two fields: api_key, label.
> My cron task that fires periodically scraps the 3rd party API containing
> list of objects like {"id": "LAW", "name": "Prawo"} and turns those into
> instances of my model. This worked allright until we've got asked for
> ability to browse this data in our Admin.
>
> So I've wen't to my models file that looked like this:
>
> {{{
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import models
> from django.utils.translation import gettext_lazy as _
>

> class Branch(ad):
> name=models.CharField(verbose_name=_("Nazwa"), max_length=255,
> db_index=True)
> api_id = models.CharField(verbose_name=_("ID API"), max_length=255)
>
> def __unicode__(self):
> return self.name
> }}}
>

> And added verbose name to it:
>

> {{{
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import models
> from django.utils.translation import gettext_lazy as _
>

> class Branch(ad):
> name=models.CharField(verbose_name=_("Nazwa"), max_length=255,
> db_index=True)
> api_id = models.CharField(verbose_name=_("ID API"), max_length=255)
>
> class Meta:
> verbose_name = _("Branża")
> verbose_name_plural = _("Branże")
>
> def __unicode__(self):
> return self.name
> }}}
>
> Now I can't get pass systems check, crashing with:
>
> {{{
> Performing system checks...
>
> Unhandled exception in thread started by  0x1031e9b18>
> Traceback (most recent call last):
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/utils/autoreload.py", line 226, in wrapper
> fn(*args, **kwargs)
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/core/management/commands/runserver.py", line 121, in
> inner_run
> self.check(display_num_errors=True)
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/core/management/base.py", line 374, in check
> include_deployment_checks=include_deployment_checks,
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/core/management/base.py", line 361, in _run_checks
> return checks.run_checks(**kwargs)
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/core/checks/registry.py", line 81, in run_checks
> new_errors = check(app_configs=app_configs)
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/contrib/auth/checks.py", line 112, in
> check_models_permissions
> builtin_permissions = dict(_get_builtin_permissions(opts))
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/contrib/auth/management/__init__.py", line 35, in
> _get_builtin_permissions
> 'Can %s %s' % (action, opts.verbose_name_raw)
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/db/models/options.py", line 341, in verbose_name_raw
> return force_text(self.verbose_name)
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/utils/encoding.py", line 80, in force_text
> s = six.text_type(bytes(s), encoding, errors)
>   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
> packages/django/utils/functional.py", line 119, in __bytes_cast
> return bytes(func(*self.__args, **self.__kw))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017c' in
> position 4: ordinal not in range(128)
> }}}

New description:

 I have model in my application that defined two fields: api_key, label. My
 cron task that fires periodically scraps the 3rd party API containing list
 of objects like {"id": "LAW", "name": "Prawo"} and turns those into
 instances of my model. This worked allright until we've got asked for
 ability to browse this data in our Admin.

 So I've wen't to my models file that looked like this:

 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models
 

[Django] #27609: UnicodeEncodeError in check_models_permissions for added unicode verbose name to models

[Django]

#27609: UnicodeEncodeError in check_models_permissions for added unicode verbose
name to models
+
   Reporter:  rafalp|  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (System checks)  |Version:  1.10
   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 |
+
 I have model in my application that defined two fields: api_key, label. My
 cron task that fires periodically scraps the 3rd party API containing list
 of objects like {"id": "LAW", "name": "Prawo"} and turns those into
 instances of my model. This worked allright until we've got asked for
 ability to browse this data in our Admin.

 So I've wen't to my models file that looked like this:

 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models
 from django.utils.translation import gettext_lazy as _


 class Branch(ad):
 name=models.CharField(verbose_name=_("Nazwa"), max_length=255,
 db_index=True)
 api_id = models.CharField(verbose_name=_("ID API"), max_length=255)

 def __unicode__(self):
 return self.name
 }}}


 And added verbose name to it:


 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models
 from django.utils.translation import gettext_lazy as _


 class Branch(ad):
 name=models.CharField(verbose_name=_("Nazwa"), max_length=255,
 db_index=True)
 api_id = models.CharField(verbose_name=_("ID API"), max_length=255)

 class Meta:
 verbose_name = _("Branża")
 verbose_name_plural = _("Branże")

 def __unicode__(self):
 return self.name
 }}}

 Now I can't get pass systems check, crashing with:

 {{{
 Performing system checks...

 Unhandled exception in thread started by 
 Traceback (most recent call last):
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/utils/autoreload.py", line 226, in wrapper
 fn(*args, **kwargs)
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/core/management/commands/runserver.py", line 121, in
 inner_run
 self.check(display_num_errors=True)
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 374, in check
 include_deployment_checks=include_deployment_checks,
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 361, in _run_checks
 return checks.run_checks(**kwargs)
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/core/checks/registry.py", line 81, in run_checks
 new_errors = check(app_configs=app_configs)
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/contrib/auth/checks.py", line 112, in
 check_models_permissions
 builtin_permissions = dict(_get_builtin_permissions(opts))
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/contrib/auth/management/__init__.py", line 35, in
 _get_builtin_permissions
 'Can %s %s' % (action, opts.verbose_name_raw)
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/db/models/options.py", line 341, in verbose_name_raw
 return force_text(self.verbose_name)
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/utils/encoding.py", line 80, in force_text
 s = six.text_type(bytes(s), encoding, errors)
   File "/Users/rafapiton/projectdir/www/venv/lib/python2.7/site-
 packages/django/utils/functional.py", line 119, in __bytes_cast
 return bytes(func(*self.__args, **self.__kw))
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u017c' in
 position 4: ordinal not in range(128)
 }}}

--
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/049.b0ce424b214a21c7852187b13ab213dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27608: Combine simple_tag and assignment_tag

[Django]

#27608: Combine simple_tag and assignment_tag
+--
 Reporter:  Jimmy Merrild Krag  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  Template system |  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 Jimmy Merrild Krag):

 * type:  Uncategorized => New feature


--
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.b4eae8136f4f46bb60562e55a53bcaaa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27608: Combine simple_tag and assignment_tag

[Django]

#27608: Combine simple_tag and assignment_tag
--+
   Reporter:  Jimmy Merrild Krag  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Template system |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   |
--+
 It would be awesome if {{{simple_tag}}} could used as an
 {{{assignment_tag}}} as well, such that there were two forms of uses of
 the same tag:

 % mytag argument1 argument2 %
 and
 % mytag argument1 argument2 as variable %

 Where the first function as {{{simple_tag}}} does now and the second as
 {{{assignment_tag}}}, but both are defined by the same function.

--
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/049.029878194a5554627861874f47fbf984%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.