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

[Django]

#32547: assertHTMLEqual()/assertHTMLNotEqual() allow invalid HTML.
--+
 Reporter:  François Poulain  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

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


Comment:

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

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

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

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
-+-
Changes (by Dylan Verheul):

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


Comment:

 Thank you for pointing out #31026. This seems to at least partly resolve
 the problem I describe, and it would be better to sit that one out before
 taking any further action.

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

Re: [Django] #28822: Add DBCalculatedField to model to annotate models automatically

[Django]

#28822: Add DBCalculatedField to model to annotate models automatically
-+-
 Reporter:  Ilya |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (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
-+-
Changes (by Diego Lima):

 * cc: Diego Lima (added)


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

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

Re: [Django] #32406: Allow QuerySet.update() to return fields on supported backends.

[Django]

#32406: Allow QuerySet.update() to return fields on supported backends.
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 |  Carrick
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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
-+-
Changes (by Diego Lima):

 * cc: Diego Lima (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/065.04733eebcba66d44b31a42ee0eae67e5%40djangoproject.com.

Re: [Django] #32381: Include number of rows matched in bulk_update() return value

[Django]

#32381: Include number of rows matched in bulk_update() return value
-+-
 Reporter:  Chris Jerdonek   |Owner:  Diego
 |  Lima
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_update  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Diego Lima):

 PR ready for review at [https://github.com/django/django/pull/14125].  I
 did not handle duplicates, and did not future-proof `bulk_update`.

 I'm keeping an eye on #32406. If it gets patched, I'll update the returned
 value on `bulk_update`. If we pin down an API that is generally agreed
 upon, I might claim that ticket as well.

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

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

Re: [Django] #32381: Include number of rows matched in bulk_update() return value

[Django]

#32381: Include number of rows matched in bulk_update() return value
-+-
 Reporter:  Chris Jerdonek   |Owner:  Diego
 |  Lima
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_update  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Nick Pope):

 * needs_docs:  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/067.a4cdf4e3061c83445da545544ff039de%40djangoproject.com.

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

[Django]

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

 * has_patch:  0 => 1


Old description:

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

New description:

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

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

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

--

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

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

[Django]

#32549: Make `Q(Q(), ...)` equivalent to `Q(...)`
-+-
   Reporter:  jonathan-  |  Owner:  nobody
  golorry|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|   Keywords:  Q objects, nested,
   Severity:  Normal |  empty
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Empty Q objects (`Q()` or `~Q()`, etc) evaluate to `False`, but `Q(Q())`
 evaluates to `True`. This interferes with the shortcut on logical
 operations involving empty Q objects and can lead to bugs when trying to
 detect empty operations.
 {{{
 def q_any(iterable):
 q = Q()
 for element in iterable:
 q |= element
 if q:
 return q
 return Q(pk__in=[])
 Item.objects.filter(q_any())  # no items
 Item.objects.filter(q_any([Q()]))  # no items
 Item.objects.filter(q_any([Q(Q())]))  # all items
 }}}

 This patch removes empty Q objects from `args` during Q object
 initialization.

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

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

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

Re: [Django] #32381: Include number of rows matched in bulk_update() return value

[Django]

#32381: Include number of rows matched in bulk_update() return value
-+-
 Reporter:  Chris Jerdonek   |Owner:  Diego
 |  Lima
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_update  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Nick Pope):

 * needs_docs:  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.82aabc757a7bd73a6508757e744ff9f1%40djangoproject.com.

Re: [Django] #32548: Remove special kwarg deconstruct case for Q objects with 1 child

[Django]

#32548: Remove special kwarg deconstruct case for Q objects with 1 child
-+-
 Reporter:  jonathan-golorry |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q objects,   | Triage Stage:
  deconstruct|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jonathan-golorry):

 * has_patch:  0 => 1


Old description:

> Currently Q objects with 1 child are treated differently during
> deconstruct.
> {{{
> >>> from django.db.models import Q
> >>> Q(x=1).deconstruct()
> ('django.db.models.Q', (), {'x': 1})
> >>> Q(x=1, y=2).deconstruct()
> ('django.db.models.Q', (('x', 1), ('y', 2)), {})
> }}}
>
> This causes issues when deconstructing Q objects with a non-subscriptable
> child.
>
> {{{
> >>> from django.contrib.auth import get_user_model
> >>> from django.db.models import Exists
> >>>
> Q(Exists(get_user_model().objects.filter(username='jim'))).deconstruct()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "...", line 90, in deconstruct
> kwargs = {child[0]: child[1]}
> TypeError: 'Exists' object is not subscriptable
> }}}
>
> I'll add a patch that removes the special case, meaning single-child Q
> objects deconstruct into args instead of kwargs. A more backward-
> compatible approach would be to keep the special case and explicitly
> check that the child is a length-2 tuple, but it's unlikely that anyone
> is relying on this undocumented behavior.

New description:

 Currently Q objects with 1 child are treated differently during
 deconstruct.
 {{{
 >>> from django.db.models import Q
 >>> Q(x=1).deconstruct()
 ('django.db.models.Q', (), {'x': 1})
 >>> Q(x=1, y=2).deconstruct()
 ('django.db.models.Q', (('x', 1), ('y', 2)), {})
 }}}

 This causes issues when deconstructing Q objects with a non-subscriptable
 child.

 {{{
 >>> from django.contrib.auth import get_user_model
 >>> from django.db.models import Exists
 >>>
 Q(Exists(get_user_model().objects.filter(username='jim'))).deconstruct()
 Traceback (most recent call last):
   File "", line 1, in 
   File "...", line 90, in deconstruct
 kwargs = {child[0]: child[1]}
 TypeError: 'Exists' object is not subscriptable
 }}}

 Patch https://github.com/django/django/pull/14126 removes the special
 case, meaning single-child Q objects deconstruct into args instead of
 kwargs. A more backward-compatible approach would be to keep the special
 case and explicitly check that the child is a length-2 tuple, but it's
 unlikely that anyone is relying on this undocumented behavior.

--

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

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

[Django] #32548: Remove special kwarg deconstruct case for Q objects with 1 child

[Django]

#32548: Remove special kwarg deconstruct case for Q objects with 1 child
-+-
   Reporter:  jonathan-  |  Owner:  nobody
  golorry|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|   Keywords:  Q objects,
   Severity:  Normal |  deconstruct
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently Q objects with 1 child are treated differently during
 deconstruct.
 {{{
 >>> from django.db.models import Q
 >>> Q(x=1).deconstruct()
 ('django.db.models.Q', (), {'x': 1})
 >>> Q(x=1, y=2).deconstruct()
 ('django.db.models.Q', (('x', 1), ('y', 2)), {})
 }}}

 This causes issues when deconstructing Q objects with a non-subscriptable
 child.

 {{{
 >>> from django.contrib.auth import get_user_model
 >>> from django.db.models import Exists
 >>>
 Q(Exists(get_user_model().objects.filter(username='jim'))).deconstruct()
 Traceback (most recent call last):
   File "", line 1, in 
   File "...", line 90, in deconstruct
 kwargs = {child[0]: child[1]}
 TypeError: 'Exists' object is not subscriptable
 }}}

 I'll add a patch that removes the special case, meaning single-child Q
 objects deconstruct into args instead of kwargs. A more backward-
 compatible approach would be to keep the special case and explicitly check
 that the child is a length-2 tuple, but it's unlikely that anyone is
 relying on this undocumented behavior.

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

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

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

[Django]

#32260: handler500 as a Class-based view raises SystemCheckError
-+-
 Reporter:  Daniyal Abbasi   |Owner:  Daniyal
 Type:   |  Abbasi
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * version:  3.1 => dev
 * needs_tests:  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.a4a2f7446d5412f2566619b0f3451529%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:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  3.1
 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 David Smith):

 I think we need to be mindful of ticket #31026 and the associated
 [https://github.com/django/django/pull/12133 pr] which moves forms to a
 template render. For items such as labels they will be able to be
 customised via overriding a temple, which could be enough here?

 For widgets, there is already the ability to over ride templates, and if
 you want to go futher I find that a boundfield's `subwidgets`  usually has
 the information needed to render each widget. For example, it can include
 `selected` and built `attrs`. It's not clear from your ticket what extra
 context you would need that is only available via django rendering?

 Here's an example of the information available in a subwidget.

 │  choice_label = 1
 │  data = {
 │ 'name': 'checkbox_select_multiple',
 │ 'value': 1,
 │ 'label': 1,
 │ 'selected': True,
 │ 'index': '0',
 │ 'attrs': {'id': 'id_checkbox_select_multiple_0',
 'checked': True},
 │ 'type': 'checkbox',
 │ 'template_name':
 'django/forms/widgets/checkbox_option.html',
 │ 'wrap_label': True
 │ }
 │  id_for_label = 'id_checkbox_select_multiple_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/062.938ce06f6b3875460c64a3fb873eac85%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):

 Everything works with PROJ 7.2.1 (GDAL 3.0.4 and GEOS 3.8.0), so I'm going
 to prepare the docs update.  #32352 is not really an issue in Django
 itself.

 Jani, does it work for you?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.24bfd18d2625d0d4c992e84cfac84b67%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
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Mariusz Felisiak
 * 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/065.8027f7933e35b937932b563b52bc7ff9%40djangoproject.com.

Re: [Django] #32381: Include number of rows matched in bulk_update() return value

[Django]

#32381: Include number of rows matched in bulk_update() return value
-+-
 Reporter:  Chris Jerdonek   |Owner:  Diego
 |  Lima
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_update  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Diego Lima):

 * 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/067.5231e1ade92926523838d2e6d6d643ba%40djangoproject.com.

Re: [Django] #32381: Include number of rows matched in bulk_update() return value

[Django]

#32381: Include number of rows matched in bulk_update() return value
-+-
 Reporter:  Chris Jerdonek   |Owner:  Diego
 |  Lima
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_update  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Diego Lima):

 * cc: Diego Lima (added)
 * owner:  bhavikabadjate901 => Diego Lima


Comment:

 Due to inactivity, I'm claiming this ticket. [comment:11
 bhavikabadjate901] please come forward if you have done any work on this!

 I'm taking the simplest approach first, which is `bulk_update -> int`. As
 stated by [comment:4 Simon Charette]:
 > I think that making `bulk_update` return the sums of its `update`s
 should be good enough for now.

 and  [comment:5 Tom Forbes]:
 > Let’s just make it return the updated rows

 Then, I'll stop and think a bit more about [comment:1 Chris Jerdonek]'s
 future-proofing and [comment:8 Tim McCurrach]'s duplicate edge case.

-- 
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.6a2e3d7114d4fe0edd8eb4ea5ce2867c%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:  3.1
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniyal Abbasi):

 An update [https://github.com/django/django/pull/14124 PR] has been
 created, as suggested in the comments of the previous 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/071.43bc2b7fffbac640fc3d74edafa973b8%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:  3.1
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Daniyal Abbasi):

 * 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/071.f85a931527f1e51bce8c2f22ed956204%40djangoproject.com.

Re: [Django] #32547: assertHTMLEqual allows invalid HTML

[Django]

#32547: assertHTMLEqual allows invalid HTML
---+--
 Reporter:  François Poulain   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  Version:  3.1
 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 François Poulain:

Old description:

> Hi,
>
> The docs for assertHTMLEqual says "html1 and html2 must be valid HTML.".
> The formulation suggest that html validation is enforced. But is is
> actually easy to get test succeeding with invalid html. Eg.
> ```
> SimpleTestCase.assertHTMLEqual(None, '',
> '')
> ```
> The code rely on Python's HTMLParser
> (https://docs.python.org/3/library/html.parser.html) for which the
> documentation states it produce parsers "able to parse invalid markup.".
>
> I suggest to correct documentation and/or to enforce validation on the
> parser side.
>
> How do you think about it?

New description:

 Hi,

 The docs for assertHTMLEqual says "html1 and html2 must be valid HTML.".
 The formulation suggest that html validation is enforced. But is is
 actually easy to get test succeeding with invalid html. Eg.
 {{{
 SimpleTestCase.assertHTMLEqual(None, '',
 '')
 }}}
 The code rely on Python's HTMLParser
 (https://docs.python.org/3/library/html.parser.html) for which the
 documentation states it produce parsers "able to parse invalid markup.".

 I suggest to correct documentation and/or to enforce validation on the
 parser side.

 How do you think about it?

--

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

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

[Django] #32547: assertHTMLEqual allows invalid HTML

[Django]

#32547: assertHTMLEqual allows invalid HTML
-+
   Reporter:  François Poulain   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Testing framework  |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  |
-+
 Hi,

 The docs for assertHTMLEqual says "html1 and html2 must be valid HTML.".
 The formulation suggest that html validation is enforced. But is is
 actually easy to get test succeeding with invalid html. Eg.
 ```
 SimpleTestCase.assertHTMLEqual(None, '',
 '')
 ```
 The code rely on Python's HTMLParser
 (https://docs.python.org/3/library/html.parser.html) for which the
 documentation states it produce parsers "able to parse invalid markup.".

 I suggest to correct documentation and/or to enforce validation on the
 parser side.

 How do you think about it?

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

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