Re: [Django] #32567: Issues with ":" and "|" characters in URLs when using LiveServerTestCase on Windows

[Django]

#32567: Issues with ":" and "|" characters in URLs when using 
LiveServerTestCase on
Windows
-+-
 Reporter:  Tim G|Owner:  Tim G
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  windows, | Triage Stage:  Accepted
  liveservertestcase, path   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Tim G
 * needs_better_patch:  0 => 1
 * 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/066.0682c1a3b517aad0acdf815508fb86cb%40djangoproject.com.

Re: [Django] #32567: Issues with ":" and "|" characters in URLs when using LiveServerTestCase on Windows

[Django]

#32567: Issues with ":" and "|" characters in URLs when using 
LiveServerTestCase on
Windows
-+-
 Reporter:  Tim G|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  windows, | Triage Stage:  Accepted
  liveservertestcase, path   |
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


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

Re: [Django] #32898: get_or_create() with filter() has surprising behaviour

[Django]

#32898: get_or_create() with filter() has surprising behaviour
-+-
 Reporter:  Jamie Cockburn   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * type:  Uncategorized => New feature
 * component:  Uncategorized => Database layer (models, ORM)


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

Re: [Django] #32898: get_or_create() with filter() has surprising behaviour

[Django]

#32898: get_or_create() with filter() has surprising behaviour
+--
 Reporter:  Jamie Cockburn  |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Uncategorized   |  Version:  3.2
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this report, however I don't see anything surprising or
 confusing in the current behavior, implicit parameters passing would be
 really unexpected. I also don't see much value in clarifying that
 parameters are no passed implicitly. You can start a discussion on
 DevelopersMailingList if you don't agree.

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

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

Re: [Django] #32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and csrf_cookie_set logic isn't right

[Django]

#32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and
csrf_cookie_set logic isn't right
+--
 Reporter:  Chris Jerdonek  |Owner:  Chris Jerdonek
 Type:  Bug |   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)
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #32901: BaseForm.__getitem__() does unneeded work in the happy path

[Django]

#32901: BaseForm.__getitem__() does unneeded work in the happy path
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  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):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #32899: enhance JSONResponse safe=True kwarg docs

[Django]

#32899: enhance JSONResponse safe=True kwarg docs
--+
 Reporter:  Thomas Grainger   |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.2
 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: Simon Willison (added)


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

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

Re: [Django] #32899: enhance JSONResponse safe=True kwarg docs

[Django]

#32899: enhance JSONResponse safe=True kwarg docs
--+
 Reporter:  Thomas Grainger   |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.2
 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:  Simon Willison => (none)
 * status:  assigned => new
 * stage:  Unreviewed => Accepted


Comment:

 Agreed, we can enhance this warning. Thomas, would you like to submit a
 patch?

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

Re: [Django] #32661: An exception should be raised when trying to save datetime/time object and the UTC offset isn't known. (was: An exception should be raised when trying to save an aware datetime/ti

[Django]

#32661: An exception should be raised when trying to save datetime/time object 
and
the UTC offset isn't known.
-+-
 Reporter:  Armin Stepanjan  |Owner:  Abhyudai
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  timezone, datetime,  | Triage Stage:  Accepted
  datetimefield, timefield, models   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

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

Re: [Django] #32899: enhance JSONResponse safe=True kwarg docs

[Django]

#32899: enhance JSONResponse safe=True kwarg docs
-+-
 Reporter:  Thomas Grainger  |Owner:  Simon
 Type:   |  Willison
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.2
 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 Jacob Walls:

Old description:

> currently JSONResponse documents a `safe` kwarg
>
> ```
>   Data to be dumped into json. By default only ``dict`` objects
>   are allowed to be passed due to a security flaw before EcmaScript
> 5. See
>   the ``safe`` parameter for more information.
> ```
>
> EcmaScript 5 is mostly dead, but there are other advantages to only
> sending dicts, see https://twitter.com/simonw/status/1410682522908856320

New description:

 currently JSONResponse documents a `safe` kwarg

 {{{
   Data to be dumped into json. By default only ``dict`` objects
   are allowed to be passed due to a security flaw before EcmaScript 5.
 See
   the ``safe`` parameter for more information.
 }}}

 EcmaScript 5 is mostly dead, but there are other advantages to only
 sending dicts, see https://twitter.com/simonw/status/1410682522908856320

--

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

Re: [Django] #32661: An exception should be raised when trying to save an aware datetime/time object even when the UTC offset isn't known.

[Django]

#32661: An exception should be raised when trying to save an aware datetime/time
object even when the UTC offset isn't known.
-+-
 Reporter:  Armin Stepanjan  |Owner:  Abhyudai
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  timezone, datetime,  | Triage Stage:  Accepted
  datetimefield, timefield, models   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 `datetime`/`time` objects with `tzinfo` which don't declare `utcoffset`
 should be treated as naive. Closing as invalid per Aymeric's
 [https://github.com/django/django/pull/14583#issuecomment-873395340
 comment]:
 {{{
 This code has been working well for over 10 years so let's be careful.
 Here's my analysis.

 The docs say:

 > A datetime object d is aware if both of the following hold:
 >
 > 1. d.tzinfo is not None
 > 2. d.tzinfo.utcoffset(d) does not return None
 >
 > Otherwise, d is naive.

 This hasn't changed this Python 2.7. (I didn't check further back.)

 This was explicitly the implementation before
 432678dbc1dd4f80203468d83bb0eb6c20ed5247.

 Also, the documentation of datetime.utcoffset, `value.utcoffset()`
 literally implemented as `None if value.tzinfo is None else
 value.tzinfo.utcoffset(value)`.

 As a consequence of the above, each of the following propositions are
 strictly equivalent:

 ...

 Therefore I believe the change proposed here is wrong for at least three
 reasons:

 - Any logic changes in this area will diverge from the definition in the
 Python docs.
 - The proposed logic is redundant — if `value.tzinfo is None`, then
 `value.utcoffset() is None`: this is the first six words of the
 documentation of datetime.utcoffset: "If tzinfo is None, returns None"; I
 don't see how adding this redundant logic is an improvement.
 - The proposed logic is wrong — if you wanted to go back to the previous
 implementation, you should use `and` instead of `or` in `is_naive`.

 Finally, I believe that have two one-liner convenience functions
 implemented as `value.utcoffset() is None` and `value.utcoffset() is not
 None` is fine. I don't see the need for adding a level of indirection and
 the overhead of a function call here.
 }}}

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

Re: [Django] #32900: Migrations questioner uses bad grammar

[Django]

#32900: Migrations questioner uses bad grammar
--+
 Reporter:  Christian Ullrich |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Jacob Walls):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks, this has also occurred to me. For the example you quoted in full,
 perhaps: "Quit, so that a default in models.py can be added later." And
 something similarly passive for the other cases, avoiding the use of "you"
 entirely.

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

Re: [Django] #32226: QuerySet.explain(format='json') outputs repr'd JSON on PostgreSQL

[Django]

#32226: QuerySet.explain(format='json') outputs repr'd JSON on PostgreSQL
-+-
 Reporter:  Adam Johnson |Owner:  Wu
 |  Haotian
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Tim McCurrach):

 * 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/068.246fda6ace6bc67b7b4b45bbe4cfe4f6%40djangoproject.com.

Re: [Django] #32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and csrf_cookie_set logic isn't right

[Django]

#32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and
csrf_cookie_set logic isn't right
+--
 Reporter:  Chris Jerdonek  |Owner:  Chris Jerdonek
 Type:  Bug |   Status:  assigned
Component:  CSRF|  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):

 The code under question was originally added 5 years in this large-ish
 commit here:
 
https://github.com/django/django/commit/5112e65ef2df1dbb95ff83026b6a962fb2688661

 Indeed, part of my proposed fix involves restoring the initial
 `csrf_cookie_set` lines prior to that commit (`csrf_cookie_set` was called
 `csrf_processing_done` before this commit).

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

Re: [Django] #32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and csrf_cookie_set logic isn't right

[Django]

#32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and
csrf_cookie_set logic isn't right
+--
 Reporter:  Chris Jerdonek  |Owner:  Chris Jerdonek
 Type:  Bug |   Status:  assigned
Component:  CSRF|  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):

 I believe the fix should look something like this:

 {{{
 diff --git a/django/middleware/csrf.py b/django/middleware/csrf.py
 index c2a9470ab1..bf97e50146 100644
 --- a/django/middleware/csrf.py
 +++ b/django/middleware/csrf.py
 @@ -437,15 +437,14 @@ class CsrfViewMiddleware(MiddlewareMixin):
  return self._accept(request)

  def process_response(self, request, response):
 -if not getattr(request, 'csrf_cookie_needs_reset', False):
 -if getattr(response, 'csrf_cookie_set', False):
 -return response
 -
 -if not request.META.get("CSRF_COOKIE_USED", False):
 +# Prevent the cookie from being set twice.
 +if getattr(response, 'csrf_cookie_set', False):
  return response
 +if (getattr(request, 'csrf_cookie_needs_reset', False) or
 +request.META.get("CSRF_COOKIE_USED")):
 +# Set the CSRF cookie even if it's already set so that the
 +# expiry timer gets renewed.
 +self._set_token(request, response)
 +response.csrf_cookie_set = True

 -# Set the CSRF cookie even if it's already set, so we renew
 -# the expiry timer.
 -self._set_token(request, response)
 -response.csrf_cookie_set = True
  return response
 }}}

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

Re: [Django] #32800: CsrfViewMiddleware unnecessarily masks CSRF cookie

[Django]

#32800: CsrfViewMiddleware unnecessarily masks CSRF cookie
-+-
 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
-+-

Comment (by Chris Jerdonek):

 I'm going to resolve #32902 before fixing the remainder of this ticket.

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

[Django] #32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and csrf_cookie_set logic isn't right

[Django]

#32902: CsrfViewMiddleware.process_response()'s csrf_cookie_needs_reset and
csrf_cookie_set logic isn't right
--+
   Reporter:  Chris Jerdonek  |  Owner:  Chris Jerdonek
   Type:  Bug | Status:  assigned
  Component:  CSRF|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 the `csrf_cookie_needs_reset` and `csrf_cookie_set` logic
 inside `CsrfViewMiddleware.process_response()` isn't right:
 
https://github.com/django/django/blob/fa35c8bdbc6aca65d94d6280fa463d5bc7baa5c0/django/middleware/csrf.py#L439-L451

 Consequently--

 1. `self._set_token(request, response)` can get called twice in some
 circumstances, even if `response.csrf_cookie_set` is true at the
 beginning, and
 2. the cookie can fail to be reset in some circumstances, even if
 `csrf_cookie_needs_reset` is true at the beginning.

 (I previously let `secur...@djangoproject.com` know about this issue, and
 they said it was okay to resolve this publicly.)

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

[Django] #32901: BaseForm.__getitem__() does unneeded work in the happy path

[Django]

#32901: BaseForm.__getitem__() does unneeded work in the happy path
-+-
   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  |
-+-
 I noticed that in the "happy path," `BaseForm.__getitem__()` does unneeded
 work:
 
https://github.com/django/django/blob/fa35c8bdbc6aca65d94d6280fa463d5bc7baa5c0/django/forms/forms.py#L150-L164

 It can just return `self._bound_fields_cache[name]` at the beginning and
 handle `KeyError`, instead of accessing `self.fields` followed by checking
 for the presence of `name` in `self._bound_fields_cache` before doing so
 each time.

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