Re: [Django] #24522: Add --random option to test command to run test cases in random order

[Django]

#24522: Add --random option to test command to run test cases in random order
---+
 Reporter:  Andreas Savvides   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Adam Johnson):

 `--shuffle` sounds good to me.

-- 
Ticket URL: 
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.0c07be9f51144b66f3cb1750048b6fd4%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 Ian Foote):

 Replying to [comment:9 jonathan-golorry]:
 > Unfortunately we can't use kwargs for Q objects with multiple children.
 >
 > `(Q(x=1) &  Q(x=2)).deconstruct()` would lose an argument.

 Excellent point!

-- 
Ticket URL: 
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.fbd9caebd1bdc587212b6cef5c9278b3%40djangoproject.com.

Re: [Django] #24522: Add --random option to test command to run test cases in random order

[Django]

#24522: Add --random option to test command to run test cases in random order
---+
 Reporter:  Andreas Savvides   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Chris Jerdonek):

 By the way, while working on the PR, I realized that we could name the
 option `--shuffle` instead of `--random`. I felt `--shuffle` was more
 specific and self-descriptive, whereas `--random` can be used in broader
 contexts (e.g. altering random data in tests themselves). So if we have
 the opportunity to be more specific in naming, I thought we should take
 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.3d6ff8d10aa7833dcf72f35a1d522124%40djangoproject.com.

Re: [Django] #32353: Add support for PROJ 7.X.

[Django]

#32353: Add support for PROJ 7.X.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"4aba70900ccdc71544d150f65e432056564d01c7" 4aba7090]:
 {{{
 #!CommitTicketReference repository=""
 revision="4aba70900ccdc71544d150f65e432056564d01c7"
 [3.2.x] Fixed #32353 -- Confirmed support for PROJ 7.X.

 Backport of 065832eaec167a45008aa125887ce1215a1f257d from main
 }}}

-- 
Ticket URL: 
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.7c6169736735c2dd143d5a8a4ebcf705%40djangoproject.com.

Re: [Django] #32353: Add support for PROJ 7.X.

[Django]

#32353: Add support for PROJ 7.X.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"065832eaec167a45008aa125887ce1215a1f257d" 065832ea]:
 {{{
 #!CommitTicketReference repository=""
 revision="065832eaec167a45008aa125887ce1215a1f257d"
 Fixed #32353 -- Confirmed support for PROJ 7.X.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.c57d1a80423e6688df1751b44d1aed83%40djangoproject.com.

Re: [Django] #24522: Add --random option to test command to run test cases in random order

[Django]

#24522: Add --random option to test command to run test cases in random order
---+
 Reporter:  Andreas Savvides   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  dev
 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 Mariusz Felisiak):

 * 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.920ab07bce51e95cc969409a4e91e81e%40djangoproject.com.

Re: [Django] #24522: Add --random option to test command to run test cases in random order

[Django]

#24522: Add --random option to test command to run test cases in random order
---+--
 Reporter:  Andreas Savvides   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Chris Jerdonek):

 * status:  closed => new
 * has_patch:  0 => 1
 * resolution:  wontfix =>


Comment:

 I'm reopening the ticket based on the mailing list discussion (a number of
 people replied in support).

 I also posted a PR here: https://github.com/django/django/pull/14137

-- 
Ticket URL: 
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.96d1bc5848a6ec0fd7d2278773d37d61%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
--+--

Comment (by Mariusz Felisiak):

 > I do not see the complexity being mentioned in Mariusz’s feedback.

 I was talking about complexity of supporting related fields e.g. with
 lookups `user_attributes=('profile__description', 'username')`. On the
 other hand adding `get_user_attribute()` to
 `UserAttributeSimilarityValidator` is misleading, validators are not a
 place for such hooks, which are rather workarounds for a specific
 situation. `get_user_attribute()` would be useful but for a quite niche
 scenario i.e. when you have a user model with custom profile but you
 cannot control user properties.

 Finally, `UserAttributeSimilarityValidator` is a small validator, you can
 always create a custom implementation in your code.

 You can start a discussion on DevelopersMailingList if you don't agree.

-- 
Ticket URL: 
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.2eab9000fad937ee8d41150853ae676c%40djangoproject.com.

[Django] #32558: Fail tests when unhandled thread exceptions occur

[Django]

#32558: Fail tests when unhandled thread exceptions occur
-+
   Reporter:  Adam Johnson   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |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  |
-+
 Pair of #32557 and its discussion.

 In Python it's possible for a thread to be started, quit with an
 exception, and this exception never get seen since the main thread doesn't
 call `join()` on the failed thread.

 Since Python 3.8 it's possible to detect such a case by installing a hook
 at `threading.excepthook`:
 https://docs.python.org/3.9/library/threading.html#threading.excepthook

 pytest recently added such a hook, alongside the unraisable exception
 hook: https://github.com/pytest-dev/pytest/pull/8055

 I think we can do similarly here, since an exception in a non-main thread
 could indicate a problem with code. This is especially pertinent in the
 async world where sync code can be run in threads through `sync_to_async`

-- 
Ticket URL: 
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/053.b548e60a5354dd7de6b627b707d8520d%40djangoproject.com.

Re: [Django] #32557: Fail tests when unraisable exceptions occur

[Django]

#32557: Fail tests when unraisable exceptions occur
---+--
 Reporter:  Adam Johnson   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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
---+--

Comment (by Adam Johnson):

 There's a reference implementation in pytest we might be able to copy:
 https://github.com/pytest-dev/pytest/pull/8055

 Additionally here's an implementation I've used - calling the context
 manager in an overridden DiscoverRunner.run_tests to wrap the whole test
 run:

 {{{
 @contextmanager
 def fail_if_any_unraisable_exceptions():
 orig_unraisable_hook = sys.unraisablehook
 hook_called = multiprocessing.Value("b", lock=False)
 hook_called.value = 0

 def hook(unraisable, /):
 hook_called.value = 1
 orig_unraisable_hook(unraisable)

 sys.unraisablehook = hook

 try:
 yield
 finally:
 sys.unraisablehook = orig_unraisable_hook

 if hook_called.value:
 print(
 "❌ Unraisable exceptions reported, failing test run - see
 above.",
 file=sys.stderr,
 )
 sys.exit(1)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.d33e52e278437918f02a03e46ea193a1%40djangoproject.com.

[Django] #32557: Fail tests when unraisable exceptions occur

[Django]

#32557: Fail tests when unraisable exceptions occur
-+
   Reporter:  Adam Johnson   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |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  |
-+
 Following django-developers discussion: https://groups.google.com/g
 /django-developers/c/ea21KjiGiY4/m/7HTnQaS8BwAJ

 Django's test runner should install an unraisable exception hook and fail
 the test run if it is ever triggered. The check could be done just once at
 the end of the test run (in subprocesses when run in parallel), because
 unraisable exceptions already print their traceback by default.

-- 
Ticket URL: 
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/053.59dda093510ced31519cd892bdf2ffdd%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):

 Unfortunately we can't use kwargs for Q objects with multiple children.

 `(Q(x=1) &  Q(x=2)).deconstruct()` would lose an argument.

-- 
Ticket URL: 
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.69358cd0ffcc71a9bb56f9e6ba5994f7%40djangoproject.com.

Re: [Django] #32555: DecimalField Rounding inconsistency (PostgreSQL)

[Django]

#32555: DecimalField Rounding inconsistency (PostgreSQL)
-+-
 Reporter:  bluppfisk|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  decimalfield,| Triage Stage:
  rounding, float|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bluppfisk):

 * cc: bluppfisk (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/067.950ed2254f6240a308e580c4ad93733f%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
--+--

Comment (by Meiyer):

 1. I do not see the complexity being mentioned in Mariusz’s feedback. The
 change required for the validator itself is customisable logic to obtain
 the attribute’s `value` (and possibly `verbose_name`) by substitution of
 the line which performs `getattr` with a call to
 `self.get_user_attribute`. This pluggable helper could be defined per
 default as

 {{{#!python
   def get_user_attribute(self, user, attribute_name):
   return getattr(user, attribute_name, None)
 }}}

 2. It is not possible to add properties to the built-in `User` model, and
 switching the `User` model for code which runs in production multiple
 years already with thousands of users is an endeavour too risky.

-- 
Ticket URL: 
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.8ea679baa7280f82be13e4b1f83cb137%40djangoproject.com.

Re: [Django] #32535: Include reference to DEBUG_PROPAGATE_EXCEPTIONS in middleware docs

[Django]

#32535: Include reference to DEBUG_PROPAGATE_EXCEPTIONS in middleware docs
-+-
 Reporter:  Jesse|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:

 I've created a [https://github.com/django/django/pull/14134 PR] and added
 a reference to [https://docs.djangoproject.com/en/3.1/ref/settings/#debug-
 propagate-exceptions DEBUG_PROPAGATE_EXCEPTIONS] setting in middleware
 docs.

 I don't think we need a link back from setting docs to middleware doc.

-- 
Ticket URL: 
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.7f7369b8196e1a11e68a343372cbaaae%40djangoproject.com.

Re: [Django] #32555: DecimalField Rounding inconsistency (PostgreSQL)

[Django]

#32555: DecimalField Rounding inconsistency (PostgreSQL)
-+-
 Reporter:  bluppfisk|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  decimalfield,| Triage Stage:
  rounding, float|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bluppfisk):

 I agree that is related, but even as I imitate Django's behaviour by using
 its own field and field configuration, the rounding is correct. It is only
 when I leave it fully up to Django that the rounding error happens.

 {{{
 def _normalize_positions(self):
 decimal_field = self._meta.get_field('positions').base_field
 self.positions = [
 decimal_field.context.create_decimal_from_float(val)
 .quantize(Decimal("1").scaleb(-decimal_field.decimal_places),
 context=decimal_field.context)
 for val in self.positions
 ]
 }}}

 > [Decimal('6586.878'), Decimal('0.204'), Decimal('0.715')]

 This is good.

 What is Django doing differently than me? It would seem logical that
 Django takes care of the normalising in a reproducible way.

-- 
Ticket URL: 
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.66fd6729daccbfef7734402899f28870%40djangoproject.com.

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
---+--
 Reporter:  Baptiste Mispelon  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  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
---+--

Comment (by Baptiste Mispelon):

 Digging into this, the issue appears to be that `django.test.html.Element`
 has a different logic in its `__eq__` vs `__str__`.

 In particular, `__eq__` [1] has this comment:
 {{{
 # attributes without a value is same as attribute with value that
 # equals the attributes name:
 #  == 
 }}}

 Whereas `__str__` will simply drop the value if it's false-ish.

 But I'm not sure that's a correct interpretation of the HTML spec on
 boolean attributes [2].
 From what I understand not all HTML attributes can be used without a
 value, but I can't seem to find an exhaustive list. A random comment on
 the internet suggests going through the complete HTML5 spec [3] and
 looking for the phrase "is a boolean".

 With Django's current approach, the two elements `` and
 `` would be considered equivalent but I'm not sure
 that's correct.


 [1]
 
https://github.com/django/django/blob/54d91795408c878ad335226a87a44961d7f646a9/django/test/html.py#L61
 [2] https://www.w3.org/TR/html52/infrastructure.html#sec-boolean-
 attributes
 [3] https://html.spec.whatwg.org/

-- 
Ticket URL: 
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.69d869f3e535bfb845be498d50aa9c93%40djangoproject.com.

Re: [Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
---+--
 Reporter:  Baptiste Mispelon  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  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 Baptiste Mispelon:

Old description:

> If you try the following assertion:
> ```
> self.assertHTMLEqual('', '')
> ```
>
> You get a test failure and the following message:
> ```
> AssertionError:  != 
>   
>
> ```
>
> I'm getting mixed signals here: either the test should pass or the error
> message should show the difference between the two strings.
>
> I'm not actually sure which option would be correct in this case so I'm
> leaving the ticket as "uncategorized" instead of "bug" or "cleanup".

New description:

 If you try the following assertion:
 {{{
 self.assertHTMLEqual('', '')
 }}}

 You get a test failure and the following message:
 {{{
 AssertionError:  != 
   

 }}}

 I'm getting mixed signals here: either the test should pass or the error
 message should show the difference between the two strings.

 I'm not actually sure which option would be correct in this case so I'm
 leaving the ticket as "uncategorized" instead of "bug" or "cleanup".

--

-- 
Ticket URL: 
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.e6ac4dec18a38c671331e25e77892042%40djangoproject.com.

[Django] #32556: assertHTMLEqual gives a confusing error message with empty attributes

[Django]

#32556: assertHTMLEqual gives a confusing error message with empty attributes
-+
   Reporter:  Baptiste Mispelon  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Testing framework  |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  |
-+
 If you try the following assertion:
 ```
 self.assertHTMLEqual('', '')
 ```

 You get a test failure and the following message:
 ```
 AssertionError:  != 
   

 ```

 I'm getting mixed signals here: either the test should pass or the error
 message should show the difference between the two strings.

 I'm not actually sure which option would be correct in this case so I'm
 leaving the ticket as "uncategorized" instead of "bug" or "cleanup".

-- 
Ticket URL: 
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.b0a64eacc7d6bfe73d6143c8bcbd32f0%40djangoproject.com.

Re: [Django] #31370: Make parallel test runner work with buffer option.

[Django]

#31370: Make parallel test runner work with buffer option.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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 Adam Johnson):

 * needs_better_patch:  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/068.0c5c7149410ac6229f326323542c6f6b%40djangoproject.com.

Re: [Django] #32353: Add support for PROJ 7.X.

[Django]

#32353: Add support for PROJ 7.X.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14133 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.5a7c0e95ba4ceae33fbc49db6e6b8650%40djangoproject.com.

Re: [Django] #32353: Add support for PROJ 7.X.

[Django]

#32353: Add support for PROJ 7.X.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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
-+-

Comment (by Mariusz Felisiak):

 > Jani, does it work for you?

 Confirmed on IRC:
 {{{
 [09:28]  felixx: Hi. If tests do pass with proj4 versions it's good
 then.
 [09:31]  jtiai: yes all tests work with PROJ 7
 [09:32]  and GEOS 3.8 and GDAL 3
 [10:18]  Then it must be ok.
 }}}

-- 
Ticket URL: 
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.d2f31b3ee090963b243375cc306c20e0%40djangoproject.com.

Re: [Django] #26459: Allow providing DecimalField with a custom context

[Django]

#26459: Allow providing DecimalField with a custom context
-+-
 Reporter:  yasondinalt  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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):

 #32555 was marked as a duplicate for `ArrayField(DecimalField())`.

-- 
Ticket URL: 
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.61870013f8db8a3859ca08ef878c6281%40djangoproject.com.

Re: [Django] #32555: DecimalField Rounding inconsistency (PostgreSQL)

[Django]

#32555: DecimalField Rounding inconsistency (PostgreSQL)
-+-
 Reporter:  bluppfisk|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  decimalfield,| Triage Stage:
  rounding, float|  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:   => duplicate


Comment:

 I cannot reproduce the incosistent rounding, however I believe we can mark
 this as a duplicate of #26459. Providing a custom context to
 `DecimalField` should fix this and similar issues, see also
 [https://groups.google.com/g/django-
 developers/c/bnoVTOx2GFs/m/i0lNDpV8EgAJ discussion] and #28164.

-- 
Ticket URL: 
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.e845752b8f7830bc7f16201597334bcf%40djangoproject.com.

[Django] #32555: DecimalField Rounding inconsistency (PostgreSQL)

[Django]

#32555: DecimalField Rounding inconsistency (PostgreSQL)
-+-
   Reporter:  bluppfisk  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|   Keywords:  decimalfield,
   Severity:  Normal |  rounding, float
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Note, I've initially posted this on
 [https://stackoverflow.com/questions/66644473/django-decimalfield-
 inconsistent-rounding stackoverflow]

 Django 2.2, PostgreSQL database. I have a `Line` object with a `positions`
 property. This is an `ArrayField` of a `DecimalField` with a `max_digits`
 of 12 and `decimal_places` of 3.

 I store some floats as `Decimal`s and get them back out of the Database:

 {{{
 pos = [6586.87849502, 2.04190477e-01, 7.1469e-01]
 line = Line(positions=pos)
 line.save()
 line.refresh_from_db()  # send it through Django's ORM piping
 print(line.positions)
 }}}
 Output:

 > [Decimal('6586.87**9**'), Decimal('0.204'), Decimal('0.715')]

 Interestingly, the first position was rounded up despite its next more
 significant digit being below 5. The other float is rounded down as
 expected.

 I thought it might be PostgreSQL messing around, but no:

 {{{
 INSERT INTO line(positions) VALUES (array[6586.87849502, 2.04190477e-01,
 7.1469e-01]) RETURNING positions;
 }}}

 > positions (numeric[])
 > {6586.878,0.204,0.715}


 The real issue is that I should be able to predict what will come out of
 the database, down to the required precision of three decimal places:

 {{{
 [Decimal(x).quantize(Decimal("0.001")) for x in pos]
 }}}

 might yield

 > [Decimal('6586.878'), Decimal('0.204'), Decimal('0.715')]

 or

 > [Decimal('6586.879'), Decimal('0.205'), Decimal('0.714')]

 depending on the `decimal.ROUND_*` flag I pass in `quantize()`, but I
 never get consistent rounding throughout the array.

 I also tried using the `django.db.backends.util::number_format` function
 for every of my `Decimal`s as I gathered that this is used by Django
 before inserting into the database, but the results are still
 inconsistent.

-- 
Ticket URL: 
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.bff1f31857cff4578c404c2cb6f1d60f%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
--+
Description changed by Mariusz Felisiak:

Old description:

> For a long time, Django has shipped with the debug 500 handler, which
> defaults to a view where "local vars" for every stack frame can be
> expanded and inspected to see the internal state at the various points in
> the stack trace.
>
> Between that renderer, the heavy usage of `django-debug-toolbar`, which
> ships with a template context inspector, and my preference throwing `pdb`
> everywhere, there is a notable lack of a good `repr()` experience in much
> of Django, both in debugging public API (that is, the bits a user will
> use and encounter), and internals that might be exposed, or could
> otherwise be served better by having a repr that says something more than
> it's address/id.
>
> A couple of previous tickets have addressed this in minor, one off ways -
> #23167, #22906, #22531 - but as I've begun collecting places they could
> supply useful info as I spot them in my stuff, they've become a
> hodgepodge across a number of modules.
>
> For example, a couple I've got implemented:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> All of which, IMHO, provide a more useful context in which to evaluate
> state.
>
> The branch I have implemented my reprs in is in no way merge ready yet,
> partially because there's no tests, and it'd need rebasing & squashing,
> but also because there are some parts I'd like to see reprs on but
> haven't landed on a good way to do so.
> An example being the concept of a `Loader`, which currently has no repr()
> and thus shows up as `` which at least
> tells us which loader is being referenced. Given the convention so far
> for reprs() is just the class name (rather than module + class), the fact
> all Loaders (and now Engines) all share the same class name means in
> exposing more useful internal state we lose knowledge of the loader in
> question's module namespace.
>
> As I write this, I've got at least rudimentary (as in, it was possibly to
> replace the 0x... with at least one object-state variable) reprs for:
> * `StaticNode`
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `Lookup`
> * `BaseDatabaseWrapper`
> * `SQLCompiler`
> * `JoinPromoter`
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * `PermWrapper`
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite`
> * `ModelAdmin`
> * `Origin`
> * `TemplateOrigin`
> * `BlockContext`
> * `IncludeNode`
> * `Template`/`Engine` (would need work still I think)
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> If accepted, this ticket could just track whatever I can end up getting
> reviewed/merged, or it could be a meta-ticket for accepting as a
> principle, and I could spin off tickets for more targeted areas.

New description:

 For a long time, Django has shipped with the debug 500 handler, which
 defaults to a view where "local vars" for every stack frame can be
 expanded and inspected to see the internal state at the various points in
 the stack trace.

 Between that renderer, the heavy usage of `django-debug-toolbar`, which
 ships with a template context inspector, and my preference throwing `pdb`
 everywhere, there is a notable lack of a good `repr()` experience in much
 of Django, both in debugging p

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 Ian Foote):

 I like the consistency and simplicity of the reworked {{{deconstruct}}}
 method. I think removing weird edge-cases in {{{Q}}} is a good thing.

 I think I would personally prefer a deconstruct api that always uses
 kwargs where possible, rather than args:

 {{{('django.db.models.Q', (), {'x': 1, 'y': 2})}}} looks nicer than
 {{{('django.db.models.Q', (('x', 1), ('y', 2)), {})}}} to me.

 I don't know how much harder this would be to implement though, and it's a
 machine facing interface, so human readability isn't the highest priority.

-- 
Ticket URL: 
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.b73b4982df08b8287030adbf410740b4%40djangoproject.com.

Re: [Django] #32541: Separate context and rendering in forms

[Django]

#32541: Separate context and rendering in forms
-+-
 Reporter:  Dylan Verheul|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  3.1
 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
-+-

Comment (by Dylan Verheul):

 👍 Thanks both!

-- 
Ticket URL: 
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/062.8749ab648d2f512d02d22a5194803a96%40djangoproject.com.

Re: [Django] #32543: Add `search_help_text` to `admin.ModelAdmin`

[Django]

#32543: Add `search_help_text` to `admin.ModelAdmin`
-+
 Reporter:  Caram|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  admin search_fields  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Maybe the placeholder idea (and disabling) is worth looking at, but the
 basic idea from the screenshot seems nice enough, so let's accept.

 Caram, I didn't look at the patch in detail yet, but do go over the patch
 review checklist that was linked in the comment on the PR. Look at the
 naming, which should begin `Fixed #32543 -- ...` which let's us auto-link
 back to the PR from here, and other similar conveniences. 🙂

-- 
Ticket URL: 
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.3dd47cdeef02fcb21b7e46e8b70cb5f0%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:"54d91795408c878ad335226a87a44961d7f646a9" 54d91795]:
 {{{
 #!CommitTicketReference repository=""
 revision="54d91795408c878ad335226a87a44961d7f646a9"
 Refs #32508 -- Raised ImproperlyConfigured instead of using "assert" in
 SessionStorage.
 }}}

-- 
Ticket URL: 
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.448e9be09bc232250906c763f4982f7e%40djangoproject.com.

Re: [Django] #32513: SQLite3 Backend Falsly claims SQLite does not support Timezone aware DateTimes

[Django]

#32513: SQLite3 Backend Falsly claims SQLite does not support Timezone aware
DateTimes
-+-
 Reporter:  Arthur Moore |Owner:  udaykiran
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  datetime, timezone   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Thanks for the clarification/follow-up both.
 I'll close as wontfix on the change in the designed behaviour.
 As per Aymeric's comments, there would need to be discussion to amend
 that.
 Please see TicketClosingReasons/DontReopenTickets for details on the
 project triage flow.

-- 
Ticket URL: 
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.824671335b7b49a4f70b6c05df3c1cf2%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:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"330bc402a8d2d8f23cf2e07d9dabf333003677d3" 330bc40]:
 {{{
 #!CommitTicketReference repository=""
 revision="330bc402a8d2d8f23cf2e07d9dabf333003677d3"
 Fixed #32546 -- Avoided Meta.ordering columns in GROUP BY clauses.

 Follow up to 0ddb4ebf7bfcc4730c80a772dd146a49ef6895f6.
 }}}

-- 
Ticket URL: 
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.b8775f373e3d3bcaad30a23cb14b2342%40djangoproject.com.

Re: [Django] #32541: Separate context and rendering in forms

[Django]

#32541: Separate context and rendering in forms
-+-
 Reporter:  Dylan Verheul|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  3.1
 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
-+-

Comment (by Carlton Gibson):

 Thanks both.

 > I think we need to be mindful of ticket #31026...

 Exactly right.

 I loathe to say when anything might happen but, #31026 is ≈top of my long-
 list for 4.0 so … 😀 — if you follow there Dylan you can see what remains
 once we merge that.

-- 
Ticket URL: 
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/062.ada593772caf6d0ff440c09263a34ef0%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:  Accepted
  DiscoverRunner,print,logging,stdout,stderr|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 I think this is a good move, so let's accept the ticket.

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

 Yes... 🤔 And folks have a hard time getting up and running with logging,
 so we need to be conscious of that. Part of it is good documentation.

 Thanks for all the work you're doing in this area Chris, and thanks for
 wanting to pick this up Daniyal!

-- 
Ticket URL: 
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.5641f7e7a2e49178856bd2996776022d%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:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"0415ac5af97e51aeb77b6b4203e57456535a2c16" 0415ac5]:
 {{{
 #!CommitTicketReference repository=""
 revision="0415ac5af97e51aeb77b6b4203e57456535a2c16"
 [3.1.x] Fixed #32536 -- Added links to BaseDetailView/BaseListView.get()
 methods in CBV docs.

 Backport of bc04941bf811d1ea2c79fb7fc20457ed2c7e3410 from main
 }}}

-- 
Ticket URL: 
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.7b6ce51ab9b971a22d45c49e60c1b451%40djangoproject.com.

Re: [Django] #32430: Documentation for BaseCreateView, BaseUpdateView, BaseFormView and BaseDeleteView.

[Django]

#32430: Documentation for BaseCreateView, BaseUpdateView, BaseFormView and
BaseDeleteView.
-+-
 Reporter:  Anil Khatri  |Owner:  Anil
 Type:   |  Khatri
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * component:  Generic views => 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/064.35506385a23b085f18278d07688ba66e%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:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"7e43a1008496ba00b584594f99f2ce35347e4d5e" 7e43a100]:
 {{{
 #!CommitTicketReference repository=""
 revision="7e43a1008496ba00b584594f99f2ce35347e4d5e"
 [3.2.x] Fixed #32536 -- Added links to BaseDetailView/BaseListView.get()
 methods in CBV docs.

 Backport of bc04941bf811d1ea2c79fb7fc20457ed2c7e3410 from main
 }}}

-- 
Ticket URL: 
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.4b37e2cf4f1fa3efb8008d202adfc8a0%40djangoproject.com.