Re: [Django] #31750: Abstract model field should not be equal across models

[Django]

#31750: Abstract model field should not be equal across models
-+-
 Reporter:  Ryan Hiebert |Owner:  Ryan
 |  Hiebert
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Nicolas Delaby):

 Hi, I wonder if the submitted fix didn't introduce a subtle regression.
 Given the example posted in the description, how would you evaluate the
 following statements ?

 **before**
 
https://github.com/django/django/commit/502e75f9ed5476ffe8229109acf0c23999d4b533
 {{{#!python
 assert B._meta.get_field('myfield') == C._meta.get_field('myfield')
 assert B._meta.get_field('myfield') == A._meta.get_field('myfield')
 assert C._meta.get_field('myfield') == A._meta.get_field('myfield')
 }}}

 **after**
 
https://github.com/django/django/commit/502e75f9ed5476ffe8229109acf0c23999d4b533
 {{{#!python
 assert B._meta.get_field('myfield') != C._meta.get_field('myfield')
 assert B._meta.get_field('myfield') != A._meta.get_field('myfield')
 assert C._meta.get_field('myfield') != A._meta.get_field('myfield')
 }}}

 What if it shouldn't be this ? Since B (or C) doesn't override
 ''myfield'', I would expect the subclass to evaluate equality as if the
 field was defined on itself (given the parent model is abstract)
 **maybe?**
 {{{#!python
 assert B._meta.get_field('myfield') != C._meta.get_field('myfield')
 assert B._meta.get_field('myfield') == A._meta.get_field('myfield')
 assert C._meta.get_field('myfield') == A._meta.get_field('myfield')
 }}}

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

Re: [Django] #31685: Support updating conflicts with QuerySet.bulk_create().

[Django]

#31685: Support updating conflicts with QuerySet.bulk_create().
-+-
 Reporter:  Vitor Pereira|Owner:  Chih Sean
 |  Hsu
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk insert update   | Triage Stage:  Accepted
  upsert |
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/062.b91955aa2a5b0baec9ef6d3087a9e7a1%40djangoproject.com.

Re: [Django] #32906: Explain JSONBAgg benefit

[Django]

#32906: Explain JSONBAgg benefit
--+
 Reporter:  Claude Paroz  |Owner:  Abhyudai
 Type:  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:  0 |UI/UX:  0
--+
Changes (by Abhyudai):

 * owner:  nobody => Abhyudai
 * 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.f4a595b690f7aa6eb87b65ae026ac610%40djangoproject.com.

Re: [Django] #32917: Add an internal _value_from_datadict() method to BaseForm

[Django]

#32917: Add an internal _value_from_datadict() method to BaseForm
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  dev
 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 GitHub ):

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


Comment:

 In [changeset:"4be58fcc369a024bd7ac72bb09af7d230499cccb" 4be58fc]:
 {{{
 #!CommitTicketReference repository=""
 revision="4be58fcc369a024bd7ac72bb09af7d230499cccb"
 Fixed #32917 -- Added BaseForm._widget_data_value()/_field_data_value().
 }}}

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

Re: [Django] #23359: Add ability to show the migration plan

[Django]

#23359: Add ability to show the migration plan
-+-
 Reporter:  Markus Holtermann|Owner:  Markus
 |  Holtermann
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  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:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"bbf93efa1939682c2af9e3fac03e8c4173523a0d" bbf93ef]:
 {{{
 #!CommitTicketReference repository=""
 revision="bbf93efa1939682c2af9e3fac03e8c4173523a0d"
 Refs #23359 -- Corrected showmigrations help text for the --database
 option.
 }}}

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

Re: [Django] #32920: BaseForm's _clean_fields() and changed_data should access values via BoundField

[Django]

#32920: BaseForm's _clean_fields() and changed_data should access values via
BoundField
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  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 Chris Jerdonek:

Old description:

> While working on #32917, I noticed that
> [https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L386-L388
> BaseForm._clean_fields()] and
> [https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L436
> BaseForm.changed_data] don't currently access their values through a
> `BoundField` object. It would be better for consistency if they did, and
> to reduce the number of code paths.
>
> One consequence of the current code is that `form._clean_fields()` can
> return a different value from `form[name].initial` when they should be
> the same. This case is almost, but not quite, covered by
> [https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/tests/forms_tests/tests/test_forms.py#L2115-L2123
> test_datetime_clean_initial_callable_disabled()] (the test can be
> adjusted to cover this case).
>
> As part of this ticket and in line with accessing data through the
> `BoundField` objects, I noticed that the code would also be simpler if
> the per-field logic of `changed_data()` were moved into a method of the
> `BoundField` class. It could be called something like `bf.did_change()`.
> This would be more appropriate because whether form data changed for a
> field is a property of its `BoundField` (as it depends on the underlying
> form data), as opposed to the unbound field. With this change, the method
> could change from its current ~20 lines to something like this--
>
> {{{#!python
> @cached_property
> def changed_data(self):
> return [name for name, bf in self._bound_items() if bf._did_change()]
> }}}

New description:

 While working on #32917, I noticed that
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L386-L388
 BaseForm._clean_fields()] and
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L436
 BaseForm.changed_data] don't currently access their values through a
 `BoundField` object. It would be better for consistency if they did, and
 to reduce the number of code paths.

 One consequence of the current code is that `form._clean_fields()` can
 return a different value from `form[name].initial` when they should be the
 same. This case is almost, but not quite, covered by
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/tests/forms_tests/tests/test_forms.py#L2115-L2123
 test_datetime_clean_initial_callable_disabled()] (the test can be adjusted
 to cover this case).

 As part of this ticket and in line with accessing data through the
 `BoundField` objects, I noticed that the code would also be simpler if the
 per-field logic of `changed_data()` were moved into a method of the
 `BoundField` class. It could be called something like `bf.did_change()`.
 This would be more appropriate because whether form data changed for a
 field is a property of its `BoundField` (as it depends on the underlying
 form data), as opposed to the unbound field. With this change, the method
 could change from its current ~20 lines to something like this--

 {{{#!python
 @cached_property
 def changed_data(self):
 return [name for name, bf in self._bound_items() if bf._did_change()]
 }}}

 A similar change could be made to `BaseForm._clean_fields()`.

--

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

Re: [Django] #32920: BaseForm's _clean_fields() and changed_data should access values via BoundField

[Django]

#32920: BaseForm's _clean_fields() and changed_data should access values via
BoundField
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  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 Chris Jerdonek:

Old description:

> While working on #32917, I noticed that
> [https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L386-L388
> BaseForm._clean_fields()] and
> [https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L436
> BaseForm.changed_data] don't currently access their values through a
> `BoundField` object. It would be better for consistency if they did, and
> to reduce the number of code paths.
>
> One consequence of the current code is that `form._clean_fields()` can
> return a different value from `form[name].initial` when they should be
> the same. This case is almost, but not quite, covered by
> [https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/tests/forms_tests/tests/test_forms.py#L2115-L2123
> test_datetime_clean_initial_callable_disabled()] (the test can be
> adjusted to cover this case).
>
> As part of this ticket and in line with accessing data through the
> `BoundField` objects, I noticed that the code would also be simpler if
> the per-field logic of `changed_data()` were moved into a method of the
> `BoundField` class. It could be called something like `bf.did_change()`.
> This would be more appropriate because whether form data changed for a
> field is a property of its `BoundField` (as it depends on the underlying
> form data), as opposed to the unbound field.

New description:

 While working on #32917, I noticed that
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L386-L388
 BaseForm._clean_fields()] and
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L436
 BaseForm.changed_data] don't currently access their values through a
 `BoundField` object. It would be better for consistency if they did, and
 to reduce the number of code paths.

 One consequence of the current code is that `form._clean_fields()` can
 return a different value from `form[name].initial` when they should be the
 same. This case is almost, but not quite, covered by
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/tests/forms_tests/tests/test_forms.py#L2115-L2123
 test_datetime_clean_initial_callable_disabled()] (the test can be adjusted
 to cover this case).

 As part of this ticket and in line with accessing data through the
 `BoundField` objects, I noticed that the code would also be simpler if the
 per-field logic of `changed_data()` were moved into a method of the
 `BoundField` class. It could be called something like `bf.did_change()`.
 This would be more appropriate because whether form data changed for a
 field is a property of its `BoundField` (as it depends on the underlying
 form data), as opposed to the unbound field. With this change, the method
 could change from its current ~20 lines to something like this--

 {{{#!python
 @cached_property
 def changed_data(self):
 return [name for name, bf in self._bound_items() if bf._did_change()]
 }}}

--

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

Re: [Django] #32920: BaseForm's _clean_fields() and changed_data should access values via BoundField

[Django]

#32920: BaseForm's _clean_fields() and changed_data should access values via
BoundField
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  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 Chris Jerdonek):

 Here is how to make the failing test I mentioned above (roughly):

 {{{
  def test_datetime_clean_initial_callable_disabled(self):
 -now = datetime.datetime(2006, 10, 25, 14, 30, 45, 123456)
 -
  class DateTimeForm(forms.Form):
 -dt = DateTimeField(initial=lambda: now, disabled=True)
 +dt = DateTimeField(initial=datetime.datetime.now,
 disabled=True)

  form = DateTimeForm({})
  self.assertEqual(form.errors, {})
 -self.assertEqual(form.cleaned_data, {'dt': now})
 +cleaned_value = form.cleaned_data['dt']
 +bf = form['dt']
 +self.assertEqual(cleaned_value, bf.initial)
 }}}

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

Re: [Django] #32847: Adjust models.E025 system check for updated field descriptor setting.

[Django]

#32847: Adjust models.E025 system check for updated field descriptor setting.
-+-
 Reporter:  Carlton Gibson   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-

Comment (by Hasan Ramezani):

 Hey @Carlton,

 I've checked it a little bit and it seems the property replaced by this
 [https://github.com/django/django/pull/14508/files#diff-
 35c61cb049d39b2e890f12f8c1f9583fb8ca351a8495718b5375a7120f775d05R785
 change].

 > Can we still though detect that such a configuration error occurred,
 i.e. that I named a property *_id matching an FK accessor?

 I couldn't find a way to detect.

 > Can we then update the system check (or replace it) and adjust/remove
 the test_property_and_related_field_accessor_clash test in
 tests/invalid_models_tests/test_models.py?

 I think we can remove the check and test but I am not sure!

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

[Django] #32920: BaseForm's _clean_fields() and changed_data should access values via BoundField

[Django]

#32920: BaseForm's _clean_fields() and changed_data should access values via
BoundField
-+-
   Reporter:  Chris  |  Owner:  Chris Jerdonek
  Jerdonek   |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Forms  |Version:  dev
   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  |
-+-
 While working on #32917, I noticed that
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L386-L388
 BaseForm._clean_fields()] and
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/django/forms/forms.py#L436
 BaseForm.changed_data] don't currently access their values through a
 `BoundField` object. It would be better for consistency if they did, and
 to reduce the number of code paths.

 One consequence of the current code is that `form._clean_fields()` can
 return a different value from `form[name].initial` when they should be the
 same. This case is almost, but not quite, covered by
 
[https://github.com/django/django/blob/0250340e372f652c4f276e6874d452d683c94dfe/tests/forms_tests/tests/test_forms.py#L2115-L2123
 test_datetime_clean_initial_callable_disabled()] (the test can be adjusted
 to cover this case).

 As part of this ticket and in line with accessing data through the
 `BoundField` objects, I noticed that the code would also be simpler if the
 per-field logic of `changed_data()` were moved into a method of the
 `BoundField` class. It could be called something like `bf.did_change()`.
 This would be more appropriate because whether form data changed for a
 field is a property of its `BoundField` (as it depends on the underlying
 form data), as opposed to the unbound field.

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

Re: [Django] #32917: Add an internal _value_from_datadict() method to BaseForm

[Django]

#32917: Add an internal _value_from_datadict() method to BaseForm
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  dev
 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 Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14629

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

Re: [Django] #32798: StreamingHttpResponse raises SynchronousOnlyOperation in ASGI server

[Django]

#32798: StreamingHttpResponse raises SynchronousOnlyOperation in ASGI server
+-
 Reporter:  Ralph Broenink  |Owner:  Michael Brown
 Type:  Bug |   Status:  assigned
Component:  HTTP handling   |  Version:  3.2
 Severity:  Normal  |   Resolution:
 Keywords:  ASGI, async | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-

Comment (by th3hamm0r):

 Fyi: I stumbled over this error when running wagtail with asgi, as it is
 using `StreamingHttpResponse` for its db-backed CSV-export (see
 
https://github.com/wagtail/wagtail/blob/c6017abca042031fb2f7931b406a4c12e7a9e8a4/wagtail/admin/views/mixins.py#L201).

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

Re: [Django] #32915: ./manage runserver --nostatic still doesn't return a traceback

[Django]

#32915: ./manage runserver --nostatic still doesn't return a traceback
-+-
 Reporter:  Michael  |Owner:  Rohith P
 |  R
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  3.2
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Rohith P R):

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

Re: [Django] #32919: Micro-optimisations for lexing & parsing of templates.

[Django]

#32919: Micro-optimisations for lexing & parsing of templates.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * owner:  nobody => Keryn Knight
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 PR for any pending discussion, if this is deemed appropriate, is:
 https://github.com/django/django/pull/14627

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

[Django] #32919: Micro-optimisations for lexing & parsing of templates.

[Django]

#32919: Micro-optimisations for lexing & parsing of templates.
+
   Reporter:  Keryn Knight  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Template system   |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 |
+
 I'm bundling all of these proposed changes into one ticket because on
 their own they're all very small things and none of them move the needle
 individually. I do have a patchset for the changes I'm describing below
 which I'll tidy up and put into a PR for discussion.

 Outside of looking at the pstats output format, the only proper
 benchmarking I've done is with timeit ... on a laptop. And unfortunately
 the bits being discussed are all quick enough that it's easy enough to
 foresee that the differences are within the margin of error, especially
 given the results can be affected by the CPU throttling, or other tasks
 running concurrently (though I've tried to avoid that as much as
 possible). It's entirely possibly that I got the baseline results during a
 throttled period accidentally, etc. So I'm going to -- possibly wrongly --
 lean on the pstats output. But by all accounts, the theory should be
 sound, because it's "do less work"...

 Note that `DEBUG=False` for all of these, but it's irrelevant because I'm
 not going through the template loaders so there's no cached Loader in play
 (I'm just not getting the DebuxLexer as a result). All of the work is
 based on instantiating a Template from a string, never getting as far as
 rendering it.

 == Baseline

 To get a baseline of where things are, I've read the contents of the
 `admin/change_list.html` into a variable, to get the following:
 {{{
 In [3]: %timeit -r5 -n5000 Template(changelist)
 2.08 ms ± 29.1 µs per loop (mean ± std. dev. of 5 runs, 5000 loops each)
 }}}
 to try and boost the signal to noise of ms fluctuations, we'll also do:
 {{{
 def runtemplate(source=changelist, n=1):
 for x in range(n):
 t = Template(source)
 }}}
 and get the baseline for that:
 {{{
 In [2]: %timeit -r5 -n1 runtemplate(n=5000)
 10.5 s ± 335 ms per loop (mean ± std. dev. of 5 runs, 1 loop each)
 }}}

 From there, I've cprofiled (well, yappi actually) `runtemplate(n=1000)` to
 amortize any other setup/import/machinery costs and boost the lexing &
 parsing parts into the spotlight. I've cherry picked the relevant things
 that I'm putting forth for change, and for the purpose of extracting the
 distinct `get_nodes_by_type` methods being run, copy-pasted the default
 `Node.get_nodes_by_type` (sigh) to each.
 I've added in "percentage of time" in at the end of each line, calculated
 as `(tottime / overall time) * 100` (eg: `Lexer.create_token` is `(1.418 /
 30.018) * 100`) ... these are ideally going to go down in the general
 case, but with each subsequent change may go back up because something
 else changed position, so are a guide more than anything.

 {{{
 6776637 function calls (6946213 primitive calls) in 30.018 seconds
 Ordered by: internal time
ncalls   tottime  percall  cumtime  percall
 filename:lineno(function)
 1000/31000  2.4100.002   24.8010.001
 django/template/base.py:445(Parser.parse) (8%)
16   1.4180.0002.4360.000
 django/template/base.py:367(Lexer.create_token) (4.7%)
687159   1.2920.0001.2930.000   builtins:0(isinstance)
 (4.3%)
 2000/56000  1.1990.0015.0950.000
 django/template/base.py:962(NodeList.get_nodes_by_type) (4%)
131000   1.1000.0001.8350.000
 django/template/base.py:512(Parser.extend_nodelist) (3.7%)
  1000   1.0470.0014.2060.004
 django/template/base.py:353(Lexer.tokenize) (3.5%)
 59000   0.9110.0003.2200.000
 django/template/base.py:768(Variable.__init__) (3%)
423338   0.8530.0000.8530.000   __builtin__:0() (2.8%)
14   0.8200.0001.3450.000
 django/template/base.py:972(TextNode.get_nodes_by_type) (2.7%)
 371343/371373   0.7700.0001.2350.000   builtins:0(getattr)
 (2.6%)
 24000   0.1410.0000.2310.000
 django/template/base.py:1024(VariableNode.get_nodes_by_type) (0.5%)
 1   0.0590.0000.0970.000
 django/templatetags/i18n.py:72(TranslateNode.get_nodes_by_type) (0.2%)
  6000   0.0360.0000.0590.000
 django/template/defaulttags.py:434(URLNode.get_nodes_by_type) (0.1%)
  4000   0.0240.0000.0390.000
 django/templatetags/sta

Re: [Django] #30581: Allow constraints to be used for validation (in Python)

[Django]

#30581: Allow constraints to be used for validation (in Python)
-+-
 Reporter:  Carlton Gibson   |Owner:  Gagaro
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints, | Triage Stage:  Accepted
  validation |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Gagaro):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * version:  2.2 => 4.0
 * needs_tests:  0 => 1
 * 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/071.ccb9bb5c115a58db14ce11ededdf4394%40djangoproject.com.

Re: [Django] #32074: Python 3.10 compatibility

[Django]

#32074: Python 3.10 compatibility
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"0250340e372f652c4f276e6874d452d683c94dfe" 0250340]:
 {{{
 #!CommitTicketReference repository=""
 revision="0250340e372f652c4f276e6874d452d683c94dfe"
 Refs #32074 -- Used Enum.repr() format proposed for Python 3.10.

 The Python's Steering Council decided to revert changes in the Enum
 module (see https://bugs.python.org/issue44559) and moved them to
 Python 3.11.

 Follow up to 5d9b065d3f93de056588dfee6f1776294dd8bab2.

 Thanks Nick Pope for the review.
 }}}

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

Re: [Django] #32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and request.csrf_cookie_needs_reset can be combined

[Django]

#32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and
request.csrf_cookie_needs_reset can be combined
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  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: Shai Berger, Florian Apolloner (added)
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 Tentatively accepted. `csrf_cookie_needs_reset` is undocumented API but I
 found projects that use it, so we should at least add a short release
 note.

 Florian, Shai, can you take a look? Your opinions would be greatly
 appreciated. I've checked an extensive discussion in #20869 and
 [https://github.com/django/django/pull/5605 PR] but couldn't find any
 rationale for this duality.

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

Re: [Django] #32918: Increase logging of authentication flow

[Django]

#32918: Increase logging of authentication flow
+--
 Reporter:  James Tocknell  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  contrib.auth|  Version:
 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 Mariusz Felisiak):

 * status:  new => closed
 * type:  Uncategorized => New feature
 * resolution:   => duplicate
 * easy:  1 => 0


Comment:

 Thanks for this ticket, as far as I'm aware this is a duplicate of #20495
 (which is generally about increasing logging in the authentication but
 with concrete examples like failed login attempts). Please check this
 discussion.

 For the future, you'll reach a wider audience if you write to the
 DevelopersMailingList about your ideas. A trac ticket should contain a
 description of what do you want to log not only an idea ''"...increase the
 amount of logging"''.

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

[Django] #32918: Increase logging of authentication flow

[Django]

#32918: Increase logging of authentication flow
--+
   Reporter:  James Tocknell  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  contrib.auth|Version:
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+
 Currently there's very little logging within the authentication subsystem,
 which makes it much harder to trace why a particular path is happening (in
 my case why TestClient.force_login wasn't working, so I ended up
 scattering the django codebase with print functions). Would the developers
 be open to a patch to increase the amount of logging (which would be at
 the debug level)?

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

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

Re: [Django] #32915: ./manage runserver --nostatic still doesn't return a traceback

[Django]

#32915: ./manage runserver --nostatic still doesn't return a traceback
-+-
 Reporter:  Michael  |Owner:  Rohith P
 |  R
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  3.2
  commands)  |
 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/068.706610f44c6e6adeda32be16513f8909%40djangoproject.com.

Re: [Django] #10929: Support a default value for Sum (and possibly other aggregation functions)

[Django]

#10929: Support a default value for Sum (and possibly other aggregation 
functions)
-+-
 Reporter:  nolan|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  aggregate annotate   | Triage Stage:  Accepted
  default|
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


Comment:

 Some tests don't work on MySQL and Oracle.

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

Re: [Django] #32880: Improve logging documentation

[Django]

#32880: Improve logging documentation
-+-
 Reporter:  Daniele Procida  |Owner:  Daniele
 Type:   |  Procida
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  logging  | 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:"013a1824d3c57b7ffc5240bc03d219a4a290aa3d" 013a182]:
 {{{
 #!CommitTicketReference repository=""
 revision="013a1824d3c57b7ffc5240bc03d219a4a290aa3d"
 Refs #32880 -- Created a new logging how-to document.

 Moved how-to material from topic document into a new document, and
 added new material. Introduced minor improvements to logging
 reference document.
 }}}

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

Re: [Django] #32915: ./manage runserver --nostatic still doesn't return a traceback

[Django]

#32915: ./manage runserver --nostatic still doesn't return a traceback
-+-
 Reporter:  Michael  |Owner:  Rohith P
 |  R
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  3.2
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Rohith P R):

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