Re: [Django] #32518: Document that QuerySet.contains() should not be overused.

[Django]

#32518: Document that QuerySet.contains() should not be overused.
--+
 Reporter:  Mariusz Felisiak  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by AdamDonna):

 I've had a go at addressing this change. I suspect this will need some
 refinement. The PR is at https://github.com/django/django/pull/14161

-- 
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.d1036bee415f33dba5652affb0d5be1b%40djangoproject.com.

Re: [Django] #32576: Correct documentation for dumpdata --exclude

[Django]

#32576: Correct documentation for dumpdata --exclude
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 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 Tim McCurrach):

 * has_patch:  0 => 1


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

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

[Django] #32576: Correct documentation for dumpdata --exclude

[Django]

#32576: Correct documentation for dumpdata --exclude
-+-
   Reporter:  Tim|  Owner:  Tim McCurrach
  McCurrach  |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  3.1
  Documentation  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The documentation for the [https://docs.djangoproject.com/en/3.1/ref
 /django-admin/#cmdoption-dumpdata-exclude dumpdata exclude option]
 currently reads:

  Prevents specific applications or models (specified in the form of
 app_label.ModelName) from being dumped. If you specify a model name, the
 output will be restricted to that model, rather than the entire
 application. You can also mix application names and model names.

 This isn't correct. If you specify a model name, the **output** is not
 restricted to that model. I think the intended meaning of this sentence is
 that only that model will be excluded (rather than the entire application
 being excluded).

-- 
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/056.062436c583056cfb8b5ec8e5a26ae6bb%40djangoproject.com.

Re: [Django] #32575: Add support for SpatiaLite 5.x.

[Django]

#32575: Add support for SpatiaLite 5.x.
-+
 Reporter:  David Smith  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  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
-+
Changes (by Mariusz Felisiak):

 * type:  Uncategorized => New feature
 * version:  3.1 => dev
 * component:  Uncategorized => GIS
 * 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.ce357e8512bb69409bcb38c586555f97%40djangoproject.com.

Re: [Django] #32574: Add support for Proj 8.x.

[Django]

#32574: Add support for Proj 8.x.
-+
 Reporter:  David Smith  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  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
-+
Changes (by Mariusz Felisiak):

 * cc: Mariusz Felisiak (added)
 * version:   => dev
 * 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.bbe993d255406f45cbe681e17fe423fe%40djangoproject.com.

[Django] #32575: Add support for SpatiaLite 5.x.

[Django]

#32575: Add support for SpatiaLite 5.x.
-+
   Reporter:  David Smith|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |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  |
-+
 See [https://www.gaia-gis.it/fossil/libspatialite/wiki?name=5.0.0-doc
 release notes].

 One of the changes is that `lwgeom` dependency has been replaced with
 `rttopo`. See [https://groups.google.com/g/spatialite-
 users/c/MlXsPU0ZMYw/m/t-ynEJ2TBQAJ mailing list].

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

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

[Django] #32574: Add support for Proj 8.x.

[Django]

#32574: Add support for Proj 8.x.
---+
   Reporter:  David Smith  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  GIS  |Version:
   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|
---+
 See [https://github.com/OSGeo/PROJ/releases/tag/8.0.0 release notes].

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

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

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

[Django]

#32554: Add Q.empty(), 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
-+-

-- 
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.191cc6598722f91fc7fe0373e3563ae4%40djangoproject.com.

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
-+-
Description changed by jonathan-golorry:

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

New description:

 `Q.empty()` checks for nested empty Q objects such as `Q(Q())`. See #32549
 for rationale.

 `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/14159

 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

--

-- 
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.187dbfd81a0db8f80f6dcb923199dd80%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:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  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 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.48744ad9491f484e9afde02a720a6f82%40djangoproject.com.

Re: [Django] #32573: Query optimization in YearLookup breaks filtering by "__iso_year"

[Django]

#32573: Query optimization in YearLookup breaks filtering by "__iso_year"
-+-
 Reporter:  Florian Demmer   |Owner:  Florian
 |  Demmer
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-
Description changed by Florian Demmer:

Old description:

> The optimization to use BETWEEN instead of the EXTRACT operation in
> [https://github.com/django/django/blob/main/django/db/models/lookups.py#L540
> YearLookup] is also registered for the
> [https://github.com/django/django/blob/main/django/db/models/functions/datetime.py#L167
> "__iso_year" lookup], which breaks the functionality provided by
> [https://docs.djangoproject.com/en/2.2/ref/models/database-
> functions/#django.db.models.functions.ExtractIsoYear ExtractIsoYear] when
> used via the lookup.
>
> This has unfortunately been broken ever since ExtractIsoYear was
> introduced in Django 2.2 via #28649 and wasn't easy to track down since
> ExtractIsoYear when used by itself eg. in an annotation works perfectly
> fine. Just when using the lookup in a filter, the optimization is used
> (even when explicitly using an annotation):
>
> {{{
> #!python
> # annotation works
> >>> qs =
> DTModel.objects.annotate(extracted=ExtractIsoYear('start_date')).only('id')
> >>> print(qs.query)
> SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
> "db_functions_dtmodel"."start_date") AS "extracted" FROM
> "db_functions_dtmodel"
>
> # explicit annotation used in filter does not use "extracted" and adds
> BETWEEN
> >>> print(qs.filter(extracted=2020).query)
> SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
> "db_functions_dtmodel"."start_date") AS "extracted" FROM
> "db_functions_dtmodel" WHERE "db_functions_dtmodel"."start_date" BETWEEN
> 2020-01-01 AND 2020-12-31
>
> # implicit lookup uses BETWEEN
> print(DTModel.objects.filter(start_date__iso_year=2020).only('id').query)
> SELECT "db_functions_dtmodel"."id" FROM "db_functions_dtmodel" WHERE
> "db_functions_dtmodel"."start_date" BETWEEN 2020-01-01 AND 2020-12-31
> }}}
>
> This results in the wrong data being returned by filters using iso_year.
>
> This PR fixes the behaviour, reverts the invalid changes to the tests and
> extends one test to catch this problem:
> https://github.com/django/django/pull/14157

New description:

 The optimization to use BETWEEN instead of the EXTRACT operation in
 [https://github.com/django/django/blob/main/django/db/models/lookups.py#L540
 YearLookup] is also registered for the
 
[https://github.com/django/django/blob/main/django/db/models/functions/datetime.py#L167
 "__iso_year" lookup], which breaks the functionality provided by
 [https://docs.djangoproject.com/en/2.2/ref/models/database-
 functions/#django.db.models.functions.ExtractIsoYear ExtractIsoYear] when
 used via the lookup.

 This has unfortunately been broken ever since ExtractIsoYear was
 introduced in [https://docs.djangoproject.com/en/2.2/ref/models/querysets
 /#iso-year Django 2.2] via #28649 and wasn't easy to track down since
 ExtractIsoYear when used by itself eg. in an annotation works perfectly
 fine. Just when using the lookup in a filter, the optimization is used
 (even when explicitly using an annotation):

 {{{
 #!python
 # annotation works
 >>> qs =
 DTModel.objects.annotate(extracted=ExtractIsoYear('start_date')).only('id')
 >>> print(qs.query)
 SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
 "db_functions_dtmodel"."start_date") AS "extracted" FROM
 "db_functions_dtmodel"

 # explicit annotation used in filter does not use "extracted" and adds
 BETWEEN
 >>> print(qs.filter(extracted=2020).query)
 SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
 "db_functions_dtmodel"."start_date") AS "extracted" FROM
 "db_functions_dtmodel" WHERE "db_functions_dtmodel"."start_date" BETWEEN
 2020-01-01 AND 2020-12-31

 # implicit lookup uses BETWEEN
 >>>
 print(DTModel.objects.filter(start_date__iso_year=2020).only('id').query)
 SELECT "db_functions_dtmodel"."id" FROM "db_functions_dtmodel" WHERE
 "db_functions_dtmodel"."start_date" BETWEEN 2020-01-01 AND 2020-12-31
 }}}

 This results in the wrong data being returned by filters using iso_year.

 This PR fixes the behaviour, reverts the invalid changes to the tests and
 extends one test to catch this problem:
 

Re: [Django] #32573: Query optimization in YearLookup breaks filtering by "__iso_year"

[Django]

#32573: Query optimization in YearLookup breaks filtering by "__iso_year"
-+-
 Reporter:  Florian Demmer   |Owner:  Florian
 |  Demmer
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 Florian Demmer):

 * owner:  nobody => Florian Demmer
 * status:  new => assigned
 * has_patch:  0 => 1


Old description:

> The optimization to use BETWEEN instead of the EXTRACT operation in
> [https://github.com/django/django/blob/main/django/db/models/lookups.py#L540
> YearLookup] is also registered for the
> [https://github.com/django/django/blob/main/django/db/models/functions/datetime.py#L167
> "__iso_year" lookup], which breaks the functionality provided by
> [https://docs.djangoproject.com/en/2.2/ref/models/database-
> functions/#django.db.models.functions.ExtractIsoYear ExtractIsoYear] when
> used via the lookup.
>
> This has unfortunately been broken ever since ExtractIsoYear was
> introduced in Django 2.2 via #28649 and wasn't easy to track down since
> ExtractIsoYear when used by itself eg. in an annotation works perfectly
> fine. Just when using the lookup in a filter, the optimization is used
> (even when explicitly using an annotation):
>
> {{{
> #!python
> # annotation works
> >>> qs =
> DTModel.objects.annotate(extracted=ExtractIsoYear('start_date')).only('id')
> >>> print(qs.query)
> SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
> "db_functions_dtmodel"."start_date") AS "extracted" FROM
> "db_functions_dtmodel"
>
> # explicit annotation used in filter does not use "extracted" and adds
> BETWEEN
> >>> print(qs.filter(extracted=2020).query)
> SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
> "db_functions_dtmodel"."start_date") AS "extracted" FROM
> "db_functions_dtmodel" WHERE "db_functions_dtmodel"."start_date" BETWEEN
> 2020-01-01 AND 2020-12-31
>
> # implicit lookup uses BETWEEN
> print(DTModel.objects.filter(start_date__iso_year=2020).only('id').query)
> SELECT "db_functions_dtmodel"."id" FROM "db_functions_dtmodel" WHERE
> "db_functions_dtmodel"."start_date" BETWEEN 2020-01-01 AND 2020-12-31
> }}}
>
> This results in the wrong data being returned by filters using iso_year.

New description:

 The optimization to use BETWEEN instead of the EXTRACT operation in
 [https://github.com/django/django/blob/main/django/db/models/lookups.py#L540
 YearLookup] is also registered for the
 
[https://github.com/django/django/blob/main/django/db/models/functions/datetime.py#L167
 "__iso_year" lookup], which breaks the functionality provided by
 [https://docs.djangoproject.com/en/2.2/ref/models/database-
 functions/#django.db.models.functions.ExtractIsoYear ExtractIsoYear] when
 used via the lookup.

 This has unfortunately been broken ever since ExtractIsoYear was
 introduced in Django 2.2 via #28649 and wasn't easy to track down since
 ExtractIsoYear when used by itself eg. in an annotation works perfectly
 fine. Just when using the lookup in a filter, the optimization is used
 (even when explicitly using an annotation):

 {{{
 #!python
 # annotation works
 >>> qs =
 DTModel.objects.annotate(extracted=ExtractIsoYear('start_date')).only('id')
 >>> print(qs.query)
 SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
 "db_functions_dtmodel"."start_date") AS "extracted" FROM
 "db_functions_dtmodel"

 # explicit annotation used in filter does not use "extracted" and adds
 BETWEEN
 >>> print(qs.filter(extracted=2020).query)
 SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
 "db_functions_dtmodel"."start_date") AS "extracted" FROM
 "db_functions_dtmodel" WHERE "db_functions_dtmodel"."start_date" BETWEEN
 2020-01-01 AND 2020-12-31

 # implicit lookup uses BETWEEN
 print(DTModel.objects.filter(start_date__iso_year=2020).only('id').query)
 SELECT "db_functions_dtmodel"."id" FROM "db_functions_dtmodel" WHERE
 "db_functions_dtmodel"."start_date" BETWEEN 2020-01-01 AND 2020-12-31
 }}}

 This results in the wrong data being returned by filters using iso_year.

 This PR fixes the behaviour, reverts the invalid changes to the tests and
 extends one test to catch this problem:
 https://github.com/django/django/pull/14157

--

-- 
Ticket URL: 
Django 
The Web framework for 

[Django] #32573: Query optimization in YearLookup breaks filtering by "__iso_year"

[Django]

#32573: Query optimization in YearLookup breaks filtering by "__iso_year"
-+-
   Reporter:  Florian|  Owner:  nobody
  Demmer |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The optimization to use BETWEEN instead of the EXTRACT operation in
 [https://github.com/django/django/blob/main/django/db/models/lookups.py#L540
 YearLookup] is also registered for the
 
[https://github.com/django/django/blob/main/django/db/models/functions/datetime.py#L167
 "__iso_year" lookup], which breaks the functionality provided by
 [https://docs.djangoproject.com/en/2.2/ref/models/database-
 functions/#django.db.models.functions.ExtractIsoYear ExtractIsoYear] when
 used via the lookup.

 This has unfortunately been broken ever since ExtractIsoYear was
 introduced in Django 2.2 via #28649 and wasn't easy to track down since
 ExtractIsoYear when used by itself eg. in an annotation works perfectly
 fine. Just when using the lookup in a filter, the optimization is used
 (even when explicitly using an annotation):

 {{{
 #!python
 # annotation works
 >>> qs =
 DTModel.objects.annotate(extracted=ExtractIsoYear('start_date')).only('id')
 >>> print(qs.query)
 SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
 "db_functions_dtmodel"."start_date") AS "extracted" FROM
 "db_functions_dtmodel"

 # explicit annotation used in filter does not use "extracted" and adds
 BETWEEN
 >>> print(qs.filter(extracted=2020).query)
 SELECT "db_functions_dtmodel"."id", EXTRACT('isoyear' FROM
 "db_functions_dtmodel"."start_date") AS "extracted" FROM
 "db_functions_dtmodel" WHERE "db_functions_dtmodel"."start_date" BETWEEN
 2020-01-01 AND 2020-12-31

 # implicit lookup uses BETWEEN
 print(DTModel.objects.filter(start_date__iso_year=2020).only('id').query)
 SELECT "db_functions_dtmodel"."id" FROM "db_functions_dtmodel" WHERE
 "db_functions_dtmodel"."start_date" BETWEEN 2020-01-01 AND 2020-12-31
 }}}

 This results in the wrong data being returned by filters using iso_year.

-- 
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/050.e6fd204e0378d4841d3faab40c6c%40djangoproject.com.

Re: [Django] #32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.

[Django]

#32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.
-+--
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  __repr__ | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Nick Pope):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14155 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.524f706a825edd93fe6c56c1031df478%40djangoproject.com.

[Django] #32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.

[Django]

#32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.
---+---
   Reporter:  Nick Pope|  Owner:  Nick Pope
   Type:  Bug  | Status:  assigned
  Component:  Core (URLs)  |Version:  dev
   Severity:  Normal   |   Keywords:  __repr__
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
 When a partial function is passed as the view, the `__repr__` shows the
 `func` argument as `functools.partial` which isn't very helpful,
 especially as it doesn't reveal the underlying function or arguments
 provided.

 Because a partial function also has arguments provided up front, we need
 to handle those specially so that they are accessible in `__repr__`.

 ISTM that we can simply unwrap `functools.partial` objects in
 `ResolverMatch.__init__()`.

-- 
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/050.932de70799942026be01b1b428220c84%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:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * stage:  Accepted => Ready for checkin


Comment:

 So we've got consensus on the approach from a few people reviewing on
 GitHub.

 It turned out that this was a bit more messy than expected due to the use
 of `functools.update_wrapper()`. This adds `__wrapped__` which was causing
 the issue with the signature inspection. We also noticed that this caused
 clobbering of the `__name__` and `__qualname__` of the generated view
 function with those of the class which is misleading. We already have
 `.view_class` available, so that should be used.

 The first part of the solution is Adam's
 [https://github.com/django/django/pull/14138 PR] that makes use of
 `.view_class` appropriately in various places.

 The second part (which will need rebasing on top of the first part) is
 Daniyal's [https://github.com/django/django/pull/14124 PR] that stops
 using `functools.update_wrapper()` and only sets certain special
 attributes.

 Marking this as RFC.

-- 
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.19c8356c95e3e38d0d3d356fae17cbc2%40djangoproject.com.

Re: [Django] #32570: Documentation example for AppConfig is overloaded

[Django]

#32570: Documentation example for AppConfig is overloaded
-+-
 Reporter:  Aymeric Augustin |Owner:  Kshitij
 Type:   |  Raghav
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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:"fb92a9e2879d9944244300353e8c8c72cc5d8e5f" fb92a9e]:
 {{{
 #!CommitTicketReference repository=""
 revision="fb92a9e2879d9944244300353e8c8c72cc5d8e5f"
 [3.2.x] Fixed #32570 -- Removed unnecessary default_auto_field in app
 config example.

 Backport of d40402cfb023801f0d83f19747e30b13096e3636 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/067.a412d1c410ce0a80221e4f50ccd79291%40djangoproject.com.

Re: [Django] #32570: Documentation example for AppConfig is overloaded

[Django]

#32570: Documentation example for AppConfig is overloaded
-+-
 Reporter:  Aymeric Augustin |Owner:  Kshitij
 Type:   |  Raghav
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"d40402cfb023801f0d83f19747e30b13096e3636" d40402c]:
 {{{
 #!CommitTicketReference repository=""
 revision="d40402cfb023801f0d83f19747e30b13096e3636"
 Fixed #32570 -- Removed unnecessary default_auto_field in app config
 example.
 }}}

-- 
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.77787237bf39dce563fa0897103c2284%40djangoproject.com.

Re: [Django] #32570: Documentation example for AppConfig is overloaded

[Django]

#32570: Documentation example for AppConfig is overloaded
-+-
 Reporter:  Aymeric Augustin |Owner:  Kshitij
 Type:   |  Raghav
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 [https://github.com/django/django/pull/14152 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/067.a49df258443b63136a49dd9ed1aa5b1a%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:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Adam Johnson):

 Exceptions in `__del__` are only one kind of unraisable exception. The
 other kind I know of that motivated me to look into them are from async
 tasks that were not joined by the task that spawned them.

 Python already prints tracebacks for unraisable exceptions, the main point
 of this ticket is to ensure that such tracebacks in tests do not get
 missed because the tests exit with a 0 status code. The default behaviour
 looks like this:

 {{{
 $ cat test.py
 class Naughty:
 def __del__(self):
 1 / 0


 Naughty()

 $ python test.py
 Exception ignored in: 
 Traceback (most recent call last):
   File "/Users/chainz/tmp/test/test.py", line 3, in __del__
 1 / 0
 ZeroDivisionError: division by zero

 $ echo $?
 0
 }}}

 The PR disabling gc affects only objects in cycles, which are a minority.
 Moreover all garbage is still collected at interpreter shutdown, so any
 unraisable exceptions would have their traceback printed at that point,
 although they indeed not be picked up by a sys.unraisablehook installed
 only for the duration of the test run. That said, the gc PR affects only
 the Django test suite which has no unraisable exceptions at the moment,
 and it's likely if any were added someone would spot them.

-- 
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.8ca2834a11e46bcf943104e90737a249%40djangoproject.com.

Re: [Django] #32570: Documentation example for AppConfig is overloaded

[Django]

#32570: Documentation example for AppConfig is overloaded
-+-
 Reporter:  Aymeric Augustin |Owner:  Kshitij
 Type:   |  Raghav
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Kshitij Raghav):

 Sucessfully removed "default_auto_field = 'django.db.models.BigAutoField'
 that was causing confusion.

-- 
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.2b8e130127b5ac066ae1ceac03b5f1c6%40djangoproject.com.

Re: [Django] #32570: Documentation example for AppConfig is overloaded

[Django]

#32570: Documentation example for AppConfig is overloaded
-+-
 Reporter:  Aymeric Augustin |Owner:  Kshitij
 Type:   |  Raghav
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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
-+-
Changes (by Kshitij Raghav):

 * owner:  nobody => Kshitij Raghav
 * status:  new => assigned


-- 
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.ffd7d97e6e9477d76fe90bd7c721365f%40djangoproject.com.

Re: [Django] #32571: CsrfViewMiddleware assumes referer header can be parsed

[Django]

#32571: CsrfViewMiddleware assumes referer header can be parsed
-+-
 Reporter:  Chris Jerdonek   |Owner:  AdamDonna
 Type:  Bug  |   Status:  closed
Component:  CSRF |  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  referer,CSRF,CsrfViewMiddleware|  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:"e49fdfa405fcacb59d7ff2f321a7ddbc65dfc68b" e49fdfa4]:
 {{{
 #!CommitTicketReference repository=""
 revision="e49fdfa405fcacb59d7ff2f321a7ddbc65dfc68b"
 Fixed #32571 -- Made CsrfViewMiddleware handle invalid URLs in Referer
 header.
 }}}

-- 
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.9e86f90bcb64e78174ef5f2c4b28bb3b%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:  Baptiste
 |  Mispelon
 Type:  Bug  |   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 Baptiste Mispelon):

 * needs_better_patch:  1 => 0


Comment:

 PR updated

-- 
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.611c92713facd8057e3a64d782b74ed0%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:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Chris Jerdonek):

 One comment: the `sys.unraisablehook` docs say:

 > Called when an exception has occurred but there is no way for Python to
 handle it. For example, when a destructor raises an exception or during
 garbage collection (`gc.collect()`).

 Thus, with this patch, if we disable garbage collection as in this PR:
 https://github.com/django/django/pull/14142
 then it seems like we won't get the benefit of this patch in checking for
 exceptions that occur during garbage collection.

-- 
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.32c740eae6bc20930a61bf4615d4f3e6%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:"474cc420bf6bc1067e2aaa4b40cf6a08d62096f7" 474cc420]:
 {{{
 #!CommitTicketReference repository=""
 revision="474cc420bf6bc1067e2aaa4b40cf6a08d62096f7"
 Refs #32508 -- Raised Type/ValueError instead of using "assert" in
 django.core.
 }}}

-- 
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.7bf0c8f3376f901cfea03995560a84ca%40djangoproject.com.

Re: [Django] #32571: CsrfViewMiddleware assumes referer header can be parsed

[Django]

#32571: CsrfViewMiddleware assumes referer header can be parsed
-+-
 Reporter:  Chris Jerdonek   |Owner:  AdamDonna
 Type:  Bug  |   Status:  assigned
Component:  CSRF |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  referer,CSRF,CsrfViewMiddleware|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => AdamDonna
 * status:  new => assigned
 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 Replying to [comment:4 AdamDonna]:
 > Great i've got a PR up for this. Are there any docs that need to be
 updated?
 > https://github.com/django/django/pull/14151

 No need, thanks.

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

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

Re: [Django] #32571: CsrfViewMiddleware assumes referer header can be parsed

[Django]

#32571: CsrfViewMiddleware assumes referer header can be parsed
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  referer,CSRF,CsrfViewMiddleware|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by AdamDonna):

 Great i've got a PR up for this. Are there any docs that need to be
 updated?
 https://github.com/django/django/pull/14151

-- 
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.33e19ec7ed4026ae2bb27ec99e784612%40djangoproject.com.

Re: [Django] #32571: CsrfViewMiddleware assumes referer header can be parsed

[Django]

#32571: CsrfViewMiddleware assumes referer header can be parsed
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  referer,CSRF,CsrfViewMiddleware|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:2 AdamDonna]:
 > Should the response in this scenario be something like this line? Or
 would a different response reason make more sense
 
https://github.com/django/django/blob/45814af6197cfd8f4dc72ee43b90ecde305a1d5a/django/middleware/csrf.py#L248

 Yes, we should reject immediately.

-- 
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.86933a64b81175d576405e519750d1a8%40djangoproject.com.

Re: [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 |   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):

 * cc: Carlton Gibson, Tom Forbes, Chris Jerdonek (added)
 * stage:  Unreviewed => Accepted


Comment:

 Tentatively accepted. As with #32557, I would like to check this in
 practice.

-- 
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.c8d21f31cf38bce176bbf2ec5a6dc206%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:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * cc: Chris Jerdonek (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/068.40eec8141dbc414ef2b48e0ec2706832%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:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * cc: Carlton Gibson, Tom Forbes (added)
 * stage:  Unreviewed => Accepted


Comment:

 Tentatively accepted. I would like to check this in practice.

-- 
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.e502f239c2ca0019769c3cc3bcbfc427%40djangoproject.com.

Re: [Django] #32571: CsrfViewMiddleware assumes referer header can be parsed

[Django]

#32571: CsrfViewMiddleware assumes referer header can be parsed
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  referer,CSRF,CsrfViewMiddleware|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by AdamDonna):

 Should the response in this scenario be something like this line? Or would
 a different response reason make more sense
 
https://github.com/django/django/blob/45814af6197cfd8f4dc72ee43b90ecde305a1d5a/django/middleware/csrf.py#L248

-- 
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.40105f201944fb7bd40dc627478bedc1%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:  Baptiste
 |  Mispelon
 Type:  Bug  |   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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.32518d427ffe9ae4724036cd5687f443%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):

 Replying to [comment:19 Daniyal Abbasi]:
 > Next up, I would like to work on removing the usage of assert in
 django.db module.

 Please take into account Tim's
 [https://code.djangoproject.com/ticket/32508#comment:3 comment].

-- 
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.7ec1939914e59757955838a0394ff414%40djangoproject.com.

Re: [Django] #25735: Add test tagging to Django test runner

[Django]

#25735: Add test tagging to Django test runner
-+-
 Reporter:  Carl Meyer   |Owner:  Jakub
 |  Paczkowski
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  1.8
 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:"11d241dcf78842764fc3d0feac1a0b2bd78aa398" 11d241dc]:
 {{{
 #!CommitTicketReference repository=""
 revision="11d241dcf78842764fc3d0feac1a0b2bd78aa398"
 [3.1.x] Refs #25735 -- Added tags/exclude_tags arguments to DiscoverRunner
 docs.

 Backport of 37044817f9a57126d655f216019e8c8cca7c151b 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/064.0207f1dd6a29fc35c5e19539b7a112fd%40djangoproject.com.

Re: [Django] #29606: Validate the type of ALLOWED_HOSTS

[Django]

#29606: Validate the type of ALLOWED_HOSTS
-+-
 Reporter:  rafis|Owner:  Marius
 |  Räsener
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  allowed_hosts| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by AdamDonna):

 I've recreated the PR and incorporated the feedback from the reviewers.
 It's ready for another review at
 https://github.com/django/django/pull/14149.
 Functionally i think it's good; the docs will need some review (especially
 if they needed to be included in other places)

-- 
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/063.395106e7dc7616158850f373cdf9eabf%40djangoproject.com.

Re: [Django] #25735: Add test tagging to Django test runner

[Django]

#25735: Add test tagging to Django test runner
-+-
 Reporter:  Carl Meyer   |Owner:  Jakub
 |  Paczkowski
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  1.8
 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:"8298775dad2a9e4f7c48829b212b32e542f51c69" 8298775d]:
 {{{
 #!CommitTicketReference repository=""
 revision="8298775dad2a9e4f7c48829b212b32e542f51c69"
 [3.2.x] Refs #25735 -- Added tags/exclude_tags arguments to DiscoverRunner
 docs.

 Backport of 37044817f9a57126d655f216019e8c8cca7c151b 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/064.215955d219c7356b1214e9d44562f3f9%40djangoproject.com.

Re: [Django] #25735: Add test tagging to Django test runner

[Django]

#25735: Add test tagging to Django test runner
-+-
 Reporter:  Carl Meyer   |Owner:  Jakub
 |  Paczkowski
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  1.8
 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:"37044817f9a57126d655f216019e8c8cca7c151b" 3704481]:
 {{{
 #!CommitTicketReference repository=""
 revision="37044817f9a57126d655f216019e8c8cca7c151b"
 Refs #25735 -- Added tags/exclude_tags arguments to DiscoverRunner 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/064.372583d104b128de100cfa1a101c9ad9%40djangoproject.com.