Re: [Django] #32554: Add Q.TRUE, Q.FALSE, Q.any() and Q.all()

[Django]

#32554: Add Q.TRUE, Q.FALSE, Q.any() and Q.all()
-+-
 Reporter:  jonathan-golorry |Owner:  jonathan-
 |  golorry
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects, any, all  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jonathan-golorry):

 * owner:  nobody => jonathan-golorry
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * status:  new => assigned


Old description:

> `Q.FALSE` and `Q.TRUE` are classattribute aliases for `Q(pk__in=[])` and
> `~Q(pk__in=[])`.
>
> `Q.any()` and `Q.all()` mimic python's builtin `any` and `all`,
> defaulting to `Q.FALSE` and `Q.TRUE` for empty iterators (or iterators
> containing only empty Q objects).
>
> See this forum thread discussing why these are an improvement over many
> ad-hoc implementations people are using:
> https://forum.djangoproject.com/t/improving-q-objects-with-true-false-
> and-none/851
>
> My patch relies on https://code.djangoproject.com/ticket/32548 and
> https://code.djangoproject.com/ticket/32549. I kept those as separate
> tickets because they each had side effects that warranted their own
> discussion.

New description:

 `Q.FALSE` and `Q.TRUE` are classattribute aliases for `Q(pk__in=[])` and
 `~Q(pk__in=[])`.

 `Q.any()` and `Q.all()` mimic python's builtin `any` and `all`, defaulting
 to `Q.FALSE` and `Q.TRUE` for empty iterators (or iterators containing
 only empty Q objects).

 Patch: https://github.com/django/django/pull/14131

 See this forum thread discussing why these are an improvement over many
 ad-hoc implementations people are using:
 https://forum.djangoproject.com/t/improving-q-objects-with-true-false-and-
 none/851

 My patch relies on https://code.djangoproject.com/ticket/32548 and
 https://code.djangoproject.com/ticket/32549. I kept those as separate
 tickets because they each had side effects that warranted their own
 discussion.

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.8ded6bcbdedbda0e96247276504b244a%40djangoproject.com.

Re: [Django] #32552: Change DiscoverRunner to use a logger instead of print

[Django]

#32552: Change DiscoverRunner to use a logger instead of print
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  DiscoverRunner,print,logging,stdout,stderr|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 Only the last three are in the `DiscoverRunner` class. The others have
 different considerations.

 I don't think this ticket is necessarily straightforward. For example, I
 think the behavior should be opt-in (at least for now) because callers
 might not have logging enabled. I'm not sure yet what the API should be
 for opting in though. I'm still thinking about it.

 I think a good first step would be to add a `log(level, msg)` method to
 the `DiscoverRunner` class that preserves the existing `print()` behavior.
 I.e. the signature of the method would match:
 https://docs.python.org/3/library/logging.html#logging.Logger.log
 And then change the class to use that method for its print statements. The
 method would use the given `level` and compare to `self.verbosity` to
 determine whether the message should be printed.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f78ad1aa94940fc5aa9e2d36f34f4e20%40djangoproject.com.

[Django] #32554: Add Q.TRUE, Q.FALSE, Q.any() and Q.all()

[Django]

#32554: Add Q.TRUE, Q.FALSE, Q.any() and Q.all()
-+-
   Reporter:  jonathan-  |  Owner:  nobody
  golorry|
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  Q objects, any, all
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `Q.FALSE` and `Q.TRUE` are classattribute aliases for `Q(pk__in=[])` and
 `~Q(pk__in=[])`.

 `Q.any()` and `Q.all()` mimic python's builtin `any` and `all`, defaulting
 to `Q.FALSE` and `Q.TRUE` for empty iterators (or iterators containing
 only empty Q objects).

 See this forum thread discussing why these are an improvement over many
 ad-hoc implementations people are using:
 https://forum.djangoproject.com/t/improving-q-objects-with-true-false-and-
 none/851

 My patch relies on https://code.djangoproject.com/ticket/32548 and
 https://code.djangoproject.com/ticket/32549. I kept those as separate
 tickets because they each had side effects that warranted their own
 discussion.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/059.bf7deb6a5bbde859eb48f453a5b31120%40djangoproject.com.

Re: [Django] #32549: Add `Q.empty()` to check for nested empty Q objects like `Q(Q())` (was: Make `Q(Q(), ...)` equivalent to `Q(...)`)

[Django]

#32549: Add `Q.empty()` to check for nested empty Q objects like `Q(Q())`
-+-
 Reporter:  jonathan-golorry |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects, nested,   | Triage Stage:
  empty  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jonathan-golorry):

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


Old description:

> Empty Q objects (`Q()` or `~Q()`, etc) evaluate to `False`, but `Q(Q())`
> evaluates to `True`. This interferes with the shortcut on logical
> operations involving empty Q objects and can lead to bugs when trying to
> detect empty operations.
> {{{
> def q_any(iterable):
> q = Q()
> for element in iterable:
> q |= element
> if q:
> return q
> return Q(pk__in=[])
> Item.objects.filter(q_any())  # no items
> Item.objects.filter(q_any([Q()]))  # no items
> Item.objects.filter(q_any([Q(Q())]))  # all items
> }}}
>
> Patch https://github.com/django/django/pull/14127 removes empty Q objects
> from `args` during Q object initialization.
>
> This requires https://code.djangoproject.com/ticket/32548 in order to
> prevent a regression in logical operations between query expressions and
> empty Q objects.

New description:

 Empty Q objects (`Q()` or `~Q()`, etc) evaluate to `False`, but `Q(Q())`
 evaluates to `True`. This interferes with the shortcut on logical
 operations involving empty Q objects and can lead to bugs when trying to
 detect empty operations.
 {{{
 def q_any(iterable):
 q = Q()
 for element in iterable:
 q |= element
 if q:
 return q
 return Q(pk__in=[])
 Item.objects.filter(q_any())  # no items
 Item.objects.filter(q_any([Q()]))  # no items
 Item.objects.filter(q_any([Q(Q())]))  # all items
 }}}

 ~~Patch https://github.com/django/django/pull/14127 removes empty Q
 objects from `args` during Q object initialization.~~

 Patch https://github.com/django/django/pull/14130 adds `.empty()` for
 detecting nested empty Q objects and uses that instead of boolean
 evaluation for shortcutting logical operations between empty Q objects. So
 `Q(x=1) | Q(Q())` will now shortcut to `Q(x=1)` the same way `Q(x=1) |
 Q()` does. No simplifying is done during Q object initialization.

 This requires https://code.djangoproject.com/ticket/32548 in order to
 prevent a regression in logical operations between query expressions and
 empty Q objects.

--

Comment:

 Here is an alternate approach that adds a way to check for nested empty Q
 objects instead of making them impossible to create.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.0f8410eddd348955e01fb04edf02243c%40djangoproject.com.

Re: [Django] #32536: Add references to get() methods in CBV docs.

[Django]

#32536: Add references to get() methods in CBV docs.
-+-
 Reporter:  Thomas Güttler   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.dea24e05ed8c93f2171a03be202aed6a%40djangoproject.com.

Re: [Django] #23076: Cascaded deletion of polymorphic models fails

[Django]

#23076: Cascaded deletion of polymorphic models fails
-+-
 Reporter:  jernej@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Brulhart):

 * cc: Simon Brulhart (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.54da56b3ea79b029bc36c36cf182d19d%40djangoproject.com.

Re: [Django] #32548: Support passing conditional expressions to Q().

[Django]

#32548: Support passing conditional expressions to Q().
-+-
 Reporter:  jonathan-golorry |Owner:  jonathan-
 Type:   |  golorry
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects,   | Triage Stage:  Accepted
  deconstruct|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Ian, can I ask for your opinion? We need another pair of eyes, I really
 don't see why the current format of `deconstruct()` is problematic 路.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.73a5a5b6e20640620300a53c204a%40djangoproject.com.

Re: [Django] #32546: Meta.ordering fields must not be included in GROUP BY clause

[Django]

#32546: Meta.ordering fields must not be included in GROUP BY clause
-+-
 Reporter:  Yuri Konotopov   |Owner:  Yuri
 |  Konotopov
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.171807a97c71591e0e6c956a5538a215%40djangoproject.com.

Re: [Django] #32548: Support passing conditional expressions to Q().

[Django]

#32548: Support passing conditional expressions to Q().
-+-
 Reporter:  jonathan-golorry |Owner:  jonathan-
 Type:   |  golorry
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects,   | Triage Stage:  Accepted
  deconstruct|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jonathan-golorry):

 I suppose it's a semantics argument whether `Q(Exists...)` is untested if
 there's a test that runs that exact expression, but isn't solely checking
 that functionality.

 My point is that `Q(("x", 1))` and `Q(x=1)` are equivalent, so it's
 impossible for the deconstruct to correctly recreate the original args and
 kwargs in all cases. Therefore, unless there's an argument for keeping the
 special case, it's better to consistently use args for both `Q(x=1)` and
 `Q(x=1, y=2)`.

 I point out `Q(Exists...) | Q(Q())` to show that the fragility of the
 special case is problematic and hard to catch. An internal optimization
 for nested empty Q objects can cause conditional expression combination to
 fail. That's why I'd like this patch to be focused on removing the special
 case and making Q objects more robust for all inputs, rather than only
 adding support for expressions. Both would make my future work on Q
 objects possible, but the current patch would put django in a better
 position for future development.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.139c4de4b81d4247699295297f5a12fd%40djangoproject.com.

Re: [Django] #32508: Raise proper exceptions instead of using "assert".

[Django]

#32508: Raise proper exceptions instead of using "assert".
--+
 Reporter:  Adam Johnson  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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 Mariusz Felisiak ):

 In [changeset:"775b796d8d13841059850d73986d5dcc2e593077" 775b796]:
 {{{
 #!CommitTicketReference repository=""
 revision="775b796d8d13841059850d73986d5dcc2e593077"
 Refs #32508 -- Raised ValueError instead of using "assert" in 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.f8471e2d84cf2287e604249ee283bf6b%40djangoproject.com.

Re: [Django] #32548: Support passing conditional expressions to Q().

[Django]

#32548: Support passing conditional expressions to Q().
-+-
 Reporter:  jonathan-golorry |Owner:  jonathan-
 Type:   |  golorry
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects,   | Triage Stage:  Accepted
  deconstruct|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > Django already passes conditional expressions to Q objects internally.
 https://github.com/django/django/blob/main/django/db/models/expressions.py#L113
 >
 > Tested here
 https://github.com/django/django/blob/main/tests/expressions/tests.py#L827

 These are example of combining conditional expressions. Again,
 initializing `Q` objects with conditional expressions is undocumented and
 untested.

 > That test is only succeeding because `Q(...) | Q(Q())` is treated
 differently from `Q(...) | Q()`.

 I'm not sure how it's related with the ticket 樂

 > As for the form of `.deconstruct()`, is there any reason for keeping the
 special case? It's:
 >
 > 1. Inconsistent: `Q(x=1).deconstruct()` vs `Q(x=1, y=2).deconstruct()`

 First is a single condition without a connector.

 > 2. Fragile: Unsupported inputs like `Q(False)` sometimes (but not
 always!) lead to "not subscriptable" errors.
 > 3. Incorrect: `Q(("x", 1)).deconstruct()` incorrectly puts the condition
 in  kwargs instead of args.

 I wouldn't say that is incorrect `Q(('x', 1))` is equivalent to the
 `Q(x=1)` so I don't see anything wrong with this behavior.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.32e143d9c227c539100be5321ac1fb75%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

[Django]

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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 tiagohonorato):

 Added __repr__() to Origin [https://github.com/django/django/pull/14119]

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.13131aaa1f7acd1b6c436865c7ace9f8%40djangoproject.com.

Re: [Django] #32548: Support passing conditional expressions to Q().

[Django]

#32548: Support passing conditional expressions to Q().
-+-
 Reporter:  jonathan-golorry |Owner:  jonathan-
 Type:   |  golorry
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects,   | Triage Stage:  Accepted
  deconstruct|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jonathan-golorry):

 Django already passes conditional expressions to Q objects internally.
 https://github.com/django/django/blob/main/django/db/models/expressions.py#L113

 Tested here
 https://github.com/django/django/blob/main/tests/expressions/tests.py#L827

 That test is only succeeding because `Q(...) | Q(Q())` is treated
 differently from `Q(...) | Q()`.

 As for the form of `.deconstruct()`, is there any reason for keeping the
 special case? It's:

 1. Inconsistent: `Q(x=1).deconstruct()` vs `Q(x=1, y=2).deconstruct()`
 2. Fragile: Unsupported inputs like `Q(False)` sometimes (but not always!)
 lead to "not subscriptable" errors.
 3. Incorrect: `Q(("x", 1)).deconstruct()` incorrectly puts the condition
 in  kwargs instead of args.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.a56d84f208baaab6154bd3a07b92214a%40djangoproject.com.

Re: [Django] #32553: Allow UserAttributeSimilarityValidator to validate against fields of related models

[Django]

#32553: Allow UserAttributeSimilarityValidator to validate against fields of
related models
--+--
 Reporter:  Meiyer|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  dev
 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 Mariusz Felisiak):

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


Comment:

 Thanks for this ticket, however I don't think it's worth addition
 complexity. You can always add properties based on related models and pass
 them to the validator in `user_attributes`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.d7714aba2285cfbbcb4cd9d410c12760%40djangoproject.com.

Re: [Django] #32552: Change DiscoverRunner to use a logger instead of print

[Django]

#32552: Change DiscoverRunner to use a logger instead of print
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  DiscoverRunner,print,logging,stdout,stderr|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniyal Abbasi):

 Is this ticket available? I would like to take up.

 I went through the `DiscoverRunner` class and I found 7 instances where
 `print` was used.

 I believe a good starting approach would be to classify the print
 statements on the bases of their logging levels.

 105: `print("\nOpening PDB: %r" % exc_value)` -> DEBUG

 142: `print("""Subtest failed: ...``` -> ERROR

 172 & 186 : Two print statements in the `check_picklable()` -> ERROR

 594: `print('Including test tag(s): %s.' % ', '.join(sorted(self.tags)))`
 -> INFO

 596: `print('Excluding test tag(s): %s.' % ',
 '.join(sorted(self.exclude_tags)))` -> INFO

 681: `print('Skipping setup of unused database(s): %s.' % ',
 '.join(sorted(unused_databases)))` -> INFO

 Let me know if this is the right way to proceed!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b4423461fc9a401e197fd41e34193994%40djangoproject.com.

Re: [Django] #32260: handler500 as a Class-based view raises SystemCheckError

[Django]

#32260: handler500 as a Class-based view raises SystemCheckError
-+-
 Reporter:  Daniyal Abbasi   |Owner:  Daniyal
 Type:   |  Abbasi
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  dev
  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 Nick Pope):

 * needs_tests:  1 => 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.d694476f9464cecc41534ae1db7ec5a3%40djangoproject.com.

Re: [Django] #32553: Allow UserAttributeSimilarityValidator to validate against fields of related models

[Django]

#32553: Allow UserAttributeSimilarityValidator to validate against fields of
related models
--+--
 Reporter:  Meiyer|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  dev
 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 Meiyer:

Old description:

> The password validator `UserAttributeSimilarityValidator` is currently
> too rigid and allows comparison of the password only to the fields of the
> `User` model, while ignoring the common case where there is also a
> profile attached to the user (as a separate model). My suggestion is to
> relax the attribute resolution so that also fields defined on related
> models could be accessed; for example, by traversing a dotted path as in
> `reduce(getattr, path.split('.'), obj)`.
>
> Yet a better option could be to allow plugging into the validator by
> means of an overridable method `get_user_attribute(self, attribute_name)`
> used instead of a direct `getattr`, that will allow more customisation
> while leaving the validation logic intact.

New description:

 The password validator `UserAttributeSimilarityValidator` is currently too
 rigid and allows comparison of the password only to the fields of the
 `User` model, while ignoring the common case where there is also a profile
 attached to the user (as a separate model). My suggestion is to relax the
 attribute resolution so that also fields defined on related models could
 be accessed; for example, by traversing a dotted path as in
 `reduce(getattr, path.split('.'), obj)`.

 Yet a better option could be to allow plugging into the validator by means
 of an overridable method `get_user_attribute(self, attribute_name)` used
 instead of a direct `getattr`, that will allow more customisation while
 leaving the validation logic intact.

 (Related to #26909 and #28127)

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.affad922e10137b43a08cb8874111da1%40djangoproject.com.

[Django] #32553: Allow UserAttributeSimilarityValidator to validate against fields of related models

[Django]

#32553: Allow UserAttributeSimilarityValidator to validate against fields of
related models
+
   Reporter:  Meiyer|  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.auth  |Version:  dev
   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 password validator `UserAttributeSimilarityValidator` is currently too
 rigid and allows comparison of the password only to the fields of the
 `User` model, while ignoring the common case where there is also a profile
 attached to the user (as a separate model). My suggestion is to relax the
 attribute resolution so that also fields defined on related models could
 be accessed; for example, by traversing a dotted path as in
 `reduce(getattr, path.split('.'), obj)`.

 Yet a better option could be to allow plugging into the validator by means
 of an overridable method `get_user_attribute(self, attribute_name)` used
 instead of a direct `getattr`, that will allow more customisation while
 leaving the validation logic intact.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.4f4188beb74699cda2c592f22ca049e0%40djangoproject.com.

Re: [Django] #16010: Support Origin header checking in the CSRF middleware

[Django]

#16010: Support Origin header checking in the CSRF middleware
-+-
 Reporter:  davidben |Owner:  Tim Graham
 Type:  New feature  |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for checkin
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 => Ready for checkin


Comment:

 Reviewed by Florian Apolloner, Chris Jerdonek, and Adam Johnson.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1602f13e376f8988f68ce0b642dab0a5%40djangoproject.com.

Re: [Django] #32536: Add references to get() methods in CBV docs.

[Django]

#32536: Add references to get() methods in CBV docs.
-+-
 Reporter:  Thomas Güttler   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14129 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.801a8dcad8d2fd687797c74c5b0aa14f%40djangoproject.com.

Re: [Django] #31158: _password_validators_help_text_html() returns HTML block level element.

[Django]

#31158: _password_validators_help_text_html() returns HTML block level element.
---+--
 Reporter:  Carsten Fuchs  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.auth   |  Version:  3.0
 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
---+--

Comment (by Meiyer):

 I just came across this myself. While I accept Mariusz’s explanation (even
 though I do not agree, as the `ul` being output by the function is
 unexpected and breaks the typical help text output in `p` or `small`), I
 do think that the documentation should be updated to clarify this point
 and to show how to perform the customisation. In my opinion, this ticket
 should be reopened as requesting change of documentation.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.9eef58aebf73335c68fdb0a387fd4d37%40djangoproject.com.

Re: [Django] #32552: Change DiscoverRunner to use a logger instead of print

[Django]

#32552: Change DiscoverRunner to use a logger instead of print
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  DiscoverRunner,print,logging,stdout,stderr|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 I'll note that one thing this would help with is when testing
 `DiscoverRunner`. Currently, testing some `DiscoverRunner` methods results
 in undesired console output. If a logger was used instead of printing,
 then the test framework could take care of this without any extra work.
 Using a logger would also make it easier to test that certain messages are
 being emitted, because the testing framework's logging assertions could 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c6cb609f775dc87be5b6276447d2b84c%40djangoproject.com.

[Django] #32552: Change DiscoverRunner to use a logger instead of print

[Django]

#32552: Change DiscoverRunner to use a logger instead of print
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type:  New| Status:  new
  feature|
  Component:  Testing|Version:  4.0
  framework  |   Keywords:
   Severity:  Normal |  
DiscoverRunner,print,logging,stdout,stderr
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently, the `DiscoverRunner` class (used when running tests) "logs" by
 printing directly to stdout. Here is one example:
 
https://github.com/django/django/blob/7bdd09d016f418719f2d0297f58bd81c5349101d/django/test/runner.py#L592-L596

 It would be much better if `DiscoverRunner` could instead use a Python
 logger. The "verbosity" of each `print()` statement could be converted to
 a log message at an appropriate level.

 Related to this, passing a `--verbosity {0,1,2,3}` (e.g. when using
 
[https://github.com/django/django/blob/7bdd09d016f418719f2d0297f58bd81c5349101d/tests/runtests.py#L433-L436
 runtests.py]) could configure a logger at the appropriate level.

 This ticket is related to (but different from) ticket #21429, which is
 about `BaseCommand`. While `DiscoverRunner` can be triggered by the `test`
 command, it can also be run separately from a management command, e.g. via
 `runtests`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.62a3dae7a4d80309006180072b3134b7%40djangoproject.com.

Re: [Django] #32548: Support passing conditional expressions to Q().

[Django]

#32548: Support passing conditional expressions to Q().
-+-
 Reporter:  jonathan-golorry |Owner:  jonathan-
 Type:   |  golorry
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects,   | Triage Stage:  Accepted
  deconstruct|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Pope):

 As `Q()` has `.conditional` set to `True`, we can amend Mariusz' example
 above to the following:
 {{{#!diff
 diff --git a/django/db/models/query_utils.py
 b/django/db/models/query_utils.py
 index ae0f886107..5dc71ad619 100644
 --- a/django/db/models/query_utils.py
 +++ b/django/db/models/query_utils.py
 @@ -85,7 +85,7 @@ class Q(tree.Node):
  if path.startswith('django.db.models.query_utils'):
  path = path.replace('django.db.models.query_utils',
 'django.db.models')
  args, kwargs = (), {}
 -if len(self.children) == 1 and not isinstance(self.children[0],
 Q):
 +if len(self.children) == 1 and getattr(self.children[0],
 'conditional', False) is False:
  child = self.children[0]
  kwargs = {child[0]: child[1]}
  else:
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.a601f6a198d8841363a21305d91f7765%40djangoproject.com.

Re: [Django] #32551: Need a direct reference of MEDIA_URL and MEDIA_ROOT in file uploads

[Django]

#32551: Need a direct reference of MEDIA_URL and MEDIA_ROOT in file uploads
-+-
 Reporter:  Ashutosh Vishu   |Owner:  nobody
  Yadav  |
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.1
 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 Mariusz Felisiak):

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


Comment:

 "File Uploads" docs already contains a reference to
 [https://docs.djangoproject.com/en/3.1/topics/http/file-uploads/#changing-
 upload-handler-behavior File upload settings]. It's also explained in
 [https://docs.djangoproject.com/en/dev/faq/usage/#how-do-i-use-image-and-
 file-fields FAQs] and [https://docs.djangoproject.com/en/dev/topics/files
 /#managing-files Managing files] docs.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.dfdb5e9ef4adc14b152b2482c9a4a1fb%40djangoproject.com.

[Django] #32551: Need a direct reference of MEDIA_URL and MEDIA_ROOT in file uploads

[Django]

#32551: Need a direct reference of MEDIA_URL and MEDIA_ROOT in file uploads
+
   Reporter:  Ashutosh Vishu Yadav  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  3.1
   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 |
+
 https://docs.djangoproject.com/en/3.1/topics/http/file-uploads/ **requires
 a direct reference of**
 https://docs.djangoproject.com/en/3.1/ref/settings/#std:setting-MEDIA_ROOT
 and https://docs.djangoproject.com/en/3.1/ref/settings/#media-url

 The current file upload doc doesn't show the settings.py changes to
 achieve the result, rather than all the settings it should tell the
 **minimum** changes require for the **file upload system** to work so
 people don't have to look for another blog to find out what was the
 problem.

 should include or refer:
 - a **media** dir in root
 - **MEDIA_URL = '/media/'** and **MEDIA_ROOT = os.path.join(BASE_DIR,
 'media')**

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.f52cdb3752d8d3e4cad5196063dcb6ae%40djangoproject.com.

Re: [Django] #32540: Only do "top level" detection in DiscoverRunner.build_suite() when needed

[Django]

#32540: Only do "top level" detection in DiscoverRunner.build_suite() when 
needed
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  DiscoverRunner,build_suite,discovery|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d5a214c7c4575773e0f1b8b99f6018bcb7adb8cd" d5a214c7]:
 {{{
 #!CommitTicketReference repository=""
 revision="d5a214c7c4575773e0f1b8b99f6018bcb7adb8cd"
 Refs #32540 -- Added django.test.runner.find_top_level().
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ca443d06a3ad447e7fd8eff469a5a600%40djangoproject.com.

Re: [Django] #32540: Only do "top level" detection in DiscoverRunner.build_suite() when needed

[Django]

#32540: Only do "top level" detection in DiscoverRunner.build_suite() when 
needed
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  DiscoverRunner,build_suite,discovery|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"7bdd09d016f418719f2d0297f58bd81c5349101d" 7bdd09d]:
 {{{
 #!CommitTicketReference repository=""
 revision="7bdd09d016f418719f2d0297f58bd81c5349101d"
 Fixed #32540 -- Optimized DiscoverRunner.build_suite() by calling
 find_top_level() only if is_discoverable() is true.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.871e05b6304fe4a62df8a32ab901ef88%40djangoproject.com.

Re: [Django] #32546: Meta.ordering fields must not be included in GROUP BY clause

[Django]

#32546: Meta.ordering fields must not be included in GROUP BY clause
-+-
 Reporter:  Yuri Konotopov   |Owner:  Yuri
 |  Konotopov
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_tests:  1 => 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.096f800ee5e550440e2d47f60047c62d%40djangoproject.com.

Re: [Django] #32546: Meta.ordering fields must not be included in GROUP BY clause

[Django]

#32546: Meta.ordering fields must not be included in GROUP BY clause
-+-
 Reporter:  Yuri Konotopov   |Owner:  Yuri
 |  Konotopov
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => assigned
 * cc: Simon Charette (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * owner:  nobody => Yuri Konotopov
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a52636478beb920a821a004685490b7d%40djangoproject.com.

Re: [Django] #32540: Only do "top level" detection in DiscoverRunner.build_suite() when needed

[Django]

#32540: Only do "top level" detection in DiscoverRunner.build_suite() when 
needed
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  DiscoverRunner,build_suite,discovery|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.36eb1fbf4ff65922e879d26504ba08e5%40djangoproject.com.

Re: [Django] #32545: Admin foreign key raw inputs are too small when referring to a UUID field

[Django]

#32545: Admin foreign key raw inputs are too small when referring to a UUID 
field
-+-
 Reporter:  Jerome Leclanche |Owner:  Jerome
 Type:   |  Leclanche
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Muhammad Amir => Jerome Leclanche
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a9afe9c2abad915be49f7f6377bd7e7b%40djangoproject.com.

Re: [Django] #32550: Translation Error

[Django]

#32550: Translation Error
---+--
 Reporter:  october-one|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  3.1
 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 Mariusz Felisiak):

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


Comment:

 Thanks for the report, however, translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.
 Transifex] and not in this tracker.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.804667600088b55bc8923c36e6d46cb8%40djangoproject.com.

Re: [Django] #32548: Support passing conditional expressions to Q(). (was: Remove special kwarg deconstruct case for Q objects with 1 child)

[Django]

#32548: Support passing conditional expressions to Q().
-+-
 Reporter:  jonathan-golorry |Owner:  jonathan-
 Type:   |  golorry
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects,   | Triage Stage:  Accepted
  deconstruct|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => assigned
 * cc: Ian Foote, Matthew Schinckel (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * owner:  nobody => jonathan-golorry
 * stage:  Unreviewed => Accepted


Comment:

 Conditional expressions can be combined together, so it's not necessary to
 encapsulate `Exists()` with `Q()`. Moreover it's an undocumented and
 untested to pass conditional expressions to `Q()`. Nevertheless I think it
 makes sense to support this.

 There is no need to change the current format of `deconstruct()`, it
 should be enough to handle conditional expressions, e.g.
 {{{
 diff --git a/django/db/models/query_utils.py
 b/django/db/models/query_utils.py
 index ae0f886107..5dc71ad619 100644
 --- a/django/db/models/query_utils.py
 +++ b/django/db/models/query_utils.py
 @@ -85,7 +85,7 @@ class Q(tree.Node):
  if path.startswith('django.db.models.query_utils'):
  path = path.replace('django.db.models.query_utils',
 'django.db.models')
  args, kwargs = (), {}
 -if len(self.children) == 1 and not isinstance(self.children[0],
 Q):
 +if len(self.children) == 1 and not isinstance(self.children[0],
 Q) and getattr(self.children[0], 'conditional', False) is False:
  child = self.children[0]
  kwargs = {child[0]: child[1]}
  else:
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.7da03ab99a820a068c9a4154ac29d429%40djangoproject.com.

Re: [Django] #32549: Make `Q(Q(), ...)` equivalent to `Q(...)`

[Django]

#32549: Make `Q(Q(), ...)` equivalent to `Q(...)`
-+-
 Reporter:  jonathan-golorry |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Q objects, nested,   | Triage Stage:
  empty  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this proposition, however I don't think we should implicitly
 remove anything from `args`, even an empty `Q()` instances. This would be
 backward incompatible, inconsistent with the `Node` behavior, and can be
 handled in your code.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.731c0825186e4203a1acf77ca89d7034%40djangoproject.com.

[Django] #32550: Translation Error

[Django]

#32550: Translation Error
-+
   Reporter:  october-one|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  3.1
   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  |
-+
 In the url,https://docs.djangoproject.com/zh-
 hans/3.1/howto/deployment/checklist/#secret-key,wrote:
 逾期将安全密码硬编码在配置模块中，不然考虑从环境变量加载它:
 It is a wrong translation, the correct translation is,
 相比于将安全密码硬编码在你的配置模块中，更应当从环境变量中加载它。

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.fec90b7a9bccbde11653fefff166696d%40djangoproject.com.

Re: [Django] #32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML. (was: assertHTMLEqual allows invalid HTML)

[Django]

#32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.
--+
 Reporter:  François Poulain  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.1
 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 Mariusz Felisiak):

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


Comment:

 Agreed, we should clarify this in
 
[https://docs.djangoproject.com/en/dev/topics/testing/tools/#django.test.SimpleTestCase.assertHTMLEqual
 assertHTMLEqual()],
 
[https://docs.djangoproject.com/en/dev/topics/testing/tools/#django.test.SimpleTestCase.assertHTMLNotEqual
 assertHTMLNotEqual()] docs and
 
[https://github.com/django/django/blob/876dc0c1a7dbf569782eb64f62f339c1daeb75e0/django/test/html.py#L227-L232
 parse_html()] docstring.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.945bd533706052c11e302db8f194fcd8%40djangoproject.com.