Re: [Django] #32821: Use a with statement when using os.scandir()

[Django]

#32821: Use a with statement when using os.scandir()
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #32821: Use a with statement when using os.scandir()

[Django]

#32821: Use a with statement when using os.scandir()
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  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:

> I noticed that Django doesn't use a `with` statement when it uses
> `os.scandir()`, which is what the
> [https://docs.python.org/3/library/os.html#os.scandir.close Python docs
> advise as of 3.6]. Here is
> [https://github.com/django/django/blob/ecf8af79355c8daa67722bd0de946b351f7f613d/django/core/files/storage.py#L324-L328
> one example in the code]. There appear to be 7 uses of `os.scandir()` in
> all, with 5 in test code.
>
> Usage with the `with` statement looks like this:
>
> {{{#!python
> with os.scandir(path) as entries:
> for entry in entries:
> ...
> }}}
>
> Not using a `with` statement or closing the iterator can cause a
> `ResourceWarning`, e.g. when an exception is raised.

New description:

 I noticed that Django doesn't use a `with` statement (or call `close()`)
 when it uses `os.scandir()`, which is what the
 [https://docs.python.org/3/library/os.html#os.scandir.close Python docs
 advise as of 3.6]. Here is
 
[https://github.com/django/django/blob/ecf8af79355c8daa67722bd0de946b351f7f613d/django/core/files/storage.py#L324-L328
 one example in the code]. There appear to be 7 uses of `os.scandir()` in
 all, with 5 in test code.

 Usage with the `with` statement looks like this:

 {{{#!python
 with os.scandir(path) as entries:
 for entry in entries:
 ...
 }}}

 Not using a `with` statement or closing the iterator can cause a
 `ResourceWarning`, e.g. when an exception is raised.

--

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

[Django] #32821: Use a with statement when using os.scandir()

[Django]

#32821: Use a with statement when using os.scandir()
+
   Reporter:  Chris Jerdonek|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |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 noticed that Django doesn't use a `with` statement when it uses
 `os.scandir()`, which is what the
 [https://docs.python.org/3/library/os.html#os.scandir.close Python docs
 advise as of 3.6]. Here is
 
[https://github.com/django/django/blob/ecf8af79355c8daa67722bd0de946b351f7f613d/django/core/files/storage.py#L324-L328
 one example in the code]. There appear to be 7 uses of `os.scandir()` in
 all, with 5 in test code.

 Usage with the `with` statement looks like this:

 {{{#!python
 with os.scandir(path) as entries:
 for entry in entries:
 ...
 }}}

 Not using a `with` statement or closing the iterator can cause a
 `ResourceWarning`, e.g. when an exception is raised.

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

Re: [Django] #32819: Django forms - fields’ help text and errors should be associated with input

[Django]

#32819: Django forms - fields’ help text and errors should be associated with 
input
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:
  forms  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Thibaud Colas):

 * component:  contrib.admin => Forms


-- 
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/070.e12ee3a9f70e751bb9edc277094053f0%40djangoproject.com.

Re: [Django] #32820: Django forms - fields’ errors should be programmatically associated with fields

[Django]

#32820: Django forms - fields’ errors should be programmatically associated with
fields
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:
  forms  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Thibaud Colas:

Old description:

> Related: [https://code.djangoproject.com/ticket/32819 #32819]. This could
> be worth fixing at the same time, although I would expect this issue
> shouldn’t require as breaking of a change to fix.
>
> Django currently displays errors above fields in its forms rendering:
>

> {{{
> 
>   This field is required.
> 
> 
>   Duration required:
>id="id_duration_required">
>   Help
> 
> }}}
>
> One thing this is missing is a way to programmatically indicate the field
> is in error – currently this can only be inferred visually because the
> error messages are displayed above the field. This is fail of WCAG 2.1
> level A [https://www.w3.org/WAI/WCAG21/Understanding/error-identification
> 3.3.1: Error Identification]. The most common way to do this
> programmatically is to use `aria-invalid="true"` on the field, as
> demonstrated in the non-normative
> [https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21 technique ARIA21]:
>
> {{{
>id="id_duration_required" aria-invalid="true">
> }}}
>
> Here is the result in VoiceOver on Safari – announcing "invalid data"
> after the field label and required state:
>
> Screenshot of the VoiceOver text-to-speech output, announcing "Email
> required: required invalid data edit text"

New description:

 Related: [https://code.djangoproject.com/ticket/32819 #32819]. This could
 be worth fixing at the same time, although I would expect this issue
 shouldn’t require as breaking of a change to fix.

 Django currently displays errors above fields in its forms rendering:


 {{{
 
   This field is required.
 
 
   Duration required:
   
   Help
 
 }}}

 One thing this is missing is a way to programmatically indicate the field
 is in error – currently this can only be inferred visually because the
 error messages are displayed above the field. This is fail of WCAG 2.1
 level A [https://www.w3.org/WAI/WCAG21/Understanding/error-identification
 3.3.1: Error Identification]. The most common way to do this
 programmatically is to use `aria-invalid="true"` on the field, as
 demonstrated in the non-normative
 [https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21 technique ARIA21]:

 {{{
   
 }}}

 Here is the result in VoiceOver on Safari – announcing "invalid data"
 after the field label and required state:

 [[Image(https://code.djangoproject.com/raw-attachment/ticket/32820/email-
 required-aria-invalid.png)]]

--

-- 
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/070.4901e43ba32f2487a0aa0be22dcea567%40djangoproject.com.

Re: [Django] #32820: Django forms - fields’ errors should be programmatically associated with fields

[Django]

#32820: Django forms - fields’ errors should be programmatically associated with
fields
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:
  forms  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Thibaud Colas):

 * Attachment "email-required-aria-invalid.png" added.

 Screenshot of the VoiceOver text-to-speech output, announcing "Email
 required: required invalid data edit text"

-- 
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/070.131f8c504b8f5f0d0b2c22a1ba6884bd%40djangoproject.com.

[Django] #32820: Django forms - fields’ errors should be programmatically associated with fields

[Django]

#32820: Django forms - fields’ errors should be programmatically associated with
fields
-+-
   Reporter:  Thibaud|  Owner:  nobody
  Colas  |
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  3.2
   Severity:  Normal |   Keywords:  accessibility, ui,
   Triage Stage: |  forms
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Related: [https://code.djangoproject.com/ticket/32819 #32819]. This could
 be worth fixing at the same time, although I would expect this issue
 shouldn’t require as breaking of a change to fix.

 Django currently displays errors above fields in its forms rendering:


 {{{
 
   This field is required.
 
 
   Duration required:
   
   Help
 
 }}}

 One thing this is missing is a way to programmatically indicate the field
 is in error – currently this can only be inferred visually because the
 error messages are displayed above the field. This is fail of WCAG 2.1
 level A [https://www.w3.org/WAI/WCAG21/Understanding/error-identification
 3.3.1: Error Identification]. The most common way to do this
 programmatically is to use `aria-invalid="true"` on the field, as
 demonstrated in the non-normative
 [https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21 technique ARIA21]:

 {{{
   
 }}}

 Here is the result in VoiceOver on Safari – announcing "invalid data"
 after the field label and required state:

 Screenshot of the VoiceOver text-to-speech output, announcing "Email
 required: required invalid data edit text"

-- 
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/055.86094edb8ea78611f2d42bb7b32ecb87%40djangoproject.com.

Re: [Django] #32819: Django forms - fields’ help text and errors should be associated with input

[Django]

#32819: Django forms - fields’ help text and errors should be associated with 
input
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:
  forms  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Description changed by Thibaud Colas:

Old description:

> With Django’s default field rendering, all field errors are rendered as a
> list above the field’s label, and help text is rendered after the field’s
> form element. Example with `as_p`:
>
> {{{
> 
>   This field is required.
> 
> 
>   Duration required:
>id="id_duration_required">
>   Help
> 
> }}}
>
> One problem for screen reader users is that the association between the
> errors and the field, and between the help text and the field, is only
> communicated visually. This is a failure of either WCAG 2.1 level A
> [https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html
> SC 1.3.1: Info and Relationships], or
> [https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions SC
> 3.3.2: Labels or Instructions]. More importantly, it just makes it harder
> than necessary for screen reader users to make use of help text, and to
> identify error messages.
>
> The fix is relatively straightforward – using `aria-describedby`, as
> documented in the (non-normative)
> [https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA1.html ARIA1 Using the
> aria-describedby property to provide a descriptive label for user
> interface controls] technique. Here is another well-known accessibility-
> oriented UI library that implements this technique: [https://design-
> system.service.gov.uk/components/text-input/#error-messages GOV.UK design
> system – text input with error message].
>
> Here is what implementing `aria-describedby` would look like in the same
> example as above:
>
> {{{
> 
>   This field is required.
> 
> 
>   Duration required:
>id="id_duration_required" aria-
> describedby="id_duration_required_errorlist
> id_duration_required_helptext">
>   Help
> 
> }}}
>
> We have additional `id` attributes, `aria-describedby`, and `errorlist`
> is no longer a ``. Result in VoiceOver:
>
> Screen recording of the VoiceOver text-to-speech output, announcing the
> field label, then error message, then help text.
>
> Unfortunately I tried to have this with the `errorlist` kept as a `ul`,
> but it wasn’t announced by VoiceOver. I haven’t heard of this limitation
> before so am not sure why that might be the case – I’d appreciate others
> taking a look if possible.

New description:

 With Django’s default field rendering, all field errors are rendered as a
 list above the field’s label, and help text is rendered after the field’s
 form element. Example with `as_p`:

 {{{
 
   This field is required.
 
 
   Duration required:
   
   Help
 
 }}}

 One problem for screen reader users is that the association between the
 errors and the field, and between the help text and the field, is only
 communicated visually. This is a failure of either WCAG 2.1 level A
 [https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html
 SC 1.3.1: Info and Relationships], or
 [https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions SC
 3.3.2: Labels or Instructions]. More importantly, it just makes it harder
 than necessary for screen reader users to make use of help text, and to
 identify error messages.

 The fix is relatively straightforward – using `aria-describedby`, as
 documented in the (non-normative)
 [https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA1.html ARIA1 Using the
 aria-describedby property to provide a descriptive label for user
 interface controls] technique. Here is another well-known accessibility-
 oriented UI library that implements this technique: [https://design-
 system.service.gov.uk/components/text-input/#error-messages GOV.UK design
 system – text input with error message].

 Here is what implementing `aria-describedby` would look like in the same
 example as above:

 {{{
 
   This field is required.
 
 
   Duration required:
   
   Help
 
 }}}

 We have additional `id` attributes, `aria-describedby`, and `errorlist` is
 no longer a ``. Result in VoiceOver:

 [[Image(https://code.djangoproject.com/raw-attachment/ticket/32819/email-
 required-ariadescribedby.gif)]]

 Unfortunately I tried to have this with the `errorlist` kept as a `ul`,
 but it wasn’t announced by VoiceOver. I haven’t heard of 

Re: [Django] #32819: Django forms - fields’ help text and errors should be associated with input

[Django]

#32819: Django forms - fields’ help text and errors should be associated with 
input
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:
  forms  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Thibaud Colas):

 * Attachment "email-required-ariadescribedby.gif" added.

 Screen recording of the VoiceOver text-to-speech output, announcing the
 field label, then error message, then help text.

-- 
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/070.7d19018de33f9d6342fa2141e9bfcc73%40djangoproject.com.

[Django] #32819: Django forms - fields’ help text and errors should be associated with input

[Django]

#32819: Django forms - fields’ help text and errors should be associated with 
input
-+-
   Reporter:  Thibaud|  Owner:  nobody
  Colas  |
   Type:  Bug| Status:  new
  Component: |Version:  3.2
  contrib.admin  |   Keywords:  accessibility, ui,
   Severity:  Normal |  forms
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 With Django’s default field rendering, all field errors are rendered as a
 list above the field’s label, and help text is rendered after the field’s
 form element. Example with `as_p`:

 {{{
 
   This field is required.
 
 
   Duration required:
   
   Help
 
 }}}

 One problem for screen reader users is that the association between the
 errors and the field, and between the help text and the field, is only
 communicated visually. This is a failure of either WCAG 2.1 level A
 [https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html
 SC 1.3.1: Info and Relationships], or
 [https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions SC
 3.3.2: Labels or Instructions]. More importantly, it just makes it harder
 than necessary for screen reader users to make use of help text, and to
 identify error messages.

 The fix is relatively straightforward – using `aria-describedby`, as
 documented in the (non-normative)
 [https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA1.html ARIA1 Using the
 aria-describedby property to provide a descriptive label for user
 interface controls] technique. Here is another well-known accessibility-
 oriented UI library that implements this technique: [https://design-
 system.service.gov.uk/components/text-input/#error-messages GOV.UK design
 system – text input with error message].

 Here is what implementing `aria-describedby` would look like in the same
 example as above:

 {{{
 
   This field is required.
 
 
   Duration required:
   
   Help
 
 }}}

 We have additional `id` attributes, `aria-describedby`, and `errorlist` is
 no longer a ``. Result in VoiceOver:

 Screen recording of the VoiceOver text-to-speech output, announcing the
 field label, then error message, then help text.

 Unfortunately I tried to have this with the `errorlist` kept as a `ul`,
 but it wasn’t announced by VoiceOver. I haven’t heard of this limitation
 before so am not sure why that might be the case – I’d appreciate others
 taking a look if possible.

-- 
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/055.c97c89d1a9d4fba088c70400eed8dc59%40djangoproject.com.

Re: [Django] #24900: KeyError when trying to migrate to a replaced migration

[Django]

#24900: KeyError when trying to migrate to a replaced migration
+-
 Reporter:  Carl Meyer  |Owner:  Jacob Walls
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.8
 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 Shai Berger):

 * 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/064.eb10e1f9bd919ab8f7ac999fa8e59be8%40djangoproject.com.

Re: [Django] #27021: Add explicit support for Q object annotations

[Django]

#27021: Add explicit support for Q object annotations
-+-
 Reporter:  Josh Smeaton |Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * 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/066.39ebfca7a1d220785f34961aeabf6dfb%40djangoproject.com.

Re: [Django] #24900: KeyError when trying to migrate to a replaced migration

[Django]

#24900: KeyError when trying to migrate to a replaced migration
+---
 Reporter:  Carl Meyer  |Owner:  Jacob Walls
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.8
 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 Jacob Walls):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14495 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/064.d62562173912adad29b1e9dcce216358%40djangoproject.com.

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   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
-+-

Comment (by GitHub ):

 In [changeset:"9812b486b5237933559c1bea8a11eff2b0d2af49" 9812b486]:
 {{{
 #!CommitTicketReference repository=""
 revision="9812b486b5237933559c1bea8a11eff2b0d2af49"
 Refs #32668 -- Simplified start_at/start_after logic in runtests.py's
 setup().
 }}}

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

Re: [Django] #32640: Non-manager instance assigned to model class' objects is silently ignored

[Django]

#32640: Non-manager instance assigned to model class' objects is silently  
ignored
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 |  Berger
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 Shai Berger):

 * needs_tests:  1 => 0


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

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

Re: [Django] #24900: KeyError when trying to migrate to a replaced migration

[Django]

#24900: KeyError when trying to migrate to a replaced migration
+---
 Reporter:  Carl Meyer  |Owner:  Jacob Walls
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.8
 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 Jacob Walls):

 * owner:  nobody => Jacob Walls
 * 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/064.44e78d75b113d4f881ac65eb0a684679%40djangoproject.com.

Re: [Django] #32716: ManifestStaticFilesStorage crashes with max_post_process_passes = 0.

[Django]

#32716: ManifestStaticFilesStorage crashes with max_post_process_passes = 0.
-+-
 Reporter:  Markus Bertheau  |Owner:  Arya
 |  Khaligh
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  staticfiles  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Arya Khaligh):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/14493

 Submitted pull request in https://github.com/django/django/pull/14493.

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

Re: [Django] #32810: django.utils.formats.number_format calculates a value for use_l10n which isn't re-used for calls to get_format

[Django]

#32810: django.utils.formats.number_format calculates a value for use_l10n which
isn't re-used for calls to get_format
-+-
 Reporter:  Keryn Knight |Owner:  Mateo
 Type:   |  Radman
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"d6f3b5858991e9609eaefc139dc605b36f9a07b3" d6f3b58]:
 {{{
 #!CommitTicketReference repository=""
 revision="d6f3b5858991e9609eaefc139dc605b36f9a07b3"
 Fixed #32810 -- Optimized django.utils.formats.number_format() a bit.

 Pre-calculate use_l10n for get_format() calls.
 }}}

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

Re: [Django] #32640: Non-manager instance assigned to model class' objects is silently ignored

[Django]

#32640: Non-manager instance assigned to model class' objects is silently  
ignored
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 |  Berger
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Shai Berger):

 * 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/063.7f3f36dbd3b9bb2f0ba312ae447b91c4%40djangoproject.com.

Re: [Django] #32818: Add pyproject.toml config for black formatter

[Django]

#32818: Add pyproject.toml config for black formatter
-+-
 Reporter:  Cooper Lees  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:  invalid
 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 Mariusz Felisiak):

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


Comment:

 I really don't understand why this needs to be added to Django. You should
 be able to add a black configurations to your CI.

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

Re: [Django] #32810: django.utils.formats.number_format calculates a value for use_l10n which isn't re-used for calls to get_format

[Django]

#32810: django.utils.formats.number_format calculates a value for use_l10n which
isn't re-used for calls to get_format
-+-
 Reporter:  Keryn Knight |Owner:  Mateo
 Type:   |  Radman
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  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 Mateo Radman):

 * has_patch:  0 => 1


Comment:

 Thanks Keryn, very good catch.
 Fixed in https://github.com/django/django/pull/14492

-- 
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.94ba6f33cb237325d1d381e9050bcec7%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
-+-

Comment (by Tom Carrick):

 Johannes, I originally saw a couple of use-cases:

 1. There is some before update trigger that changes the data. If I
 understand it, `db_returning` should cover this (I had no idea it existed
 as it's not documented).
 2.  You are creating an API (or not an API) with a bulk update feature,
 and you want to return the results to the user without making another
 query to gather 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/065.3e3b9bf1f3424f69c3423e88a3117376%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
-+-

Comment (by Johannes Maron):

 Hi there, I implemented the `returning` support in the past. I believe
 this feature is possible, however, I think we need to be sure how this
 differs from setting `db_returning` on the fields itself. In case you
 didn't know (it's not documented yet) You have multiple return values by
 setting that attribute to true. I would be curious if you could provide a
 more detailed use case. Best, Joe

 FYI, this might be somewhat related to #30032 and #470

-- 
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.3dc8e98e0eb57b903cae0642841e825b%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 Johannes Maron):

 * cc: Johannes Maron (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.9a99ad9f56b415ac295e96e0798f2e6c%40djangoproject.com.

Re: [Django] #470: Add Field.db_default for defining database defaults

[Django]

#470: Add Field.db_default for defining database defaults
-+-
 Reporter:  jws  |Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  normal   |   Resolution:
 Keywords:  sql schema   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Johannes Maron):

 * cc: Johannes Maron (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/061.7f97c3c8966fb9501715f39b2a67c88e%40djangoproject.com.