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

[Django]

#32818: Add pyproject.toml config for black formatter
-+-
 Reporter:  cooperlees   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  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
-+-

Comment (by Chris Jerdonek):

 I'm not for or against the idea, but out of curiosity, why wouldn't it be
 easier for you to keep the file in your own repo? That way you wouldn't
 need to file a PR anytime you wanted to make changes to the file. Is it
 because the file could potentially be different in multiple versions of
 Django, and you wouldn't want to have to store multiple versions of the
 file?

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

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

[Django]

#32818: Add pyproject.toml config for black formatter
+
   Reporter:  cooperlees|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Utilities |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Hi,

 I'm a maintainer of black (https://github.com/psf/black), a python code
 formatter. I know Django does not use black, but we selected to add it to
 our CI to test formatting a decent amount of files (~1900) that have
 formatting changes to try and find bugs when we make changes.

 You have some test files and docs generation files that we'd like to
 exclude. The test files have syntax errors on purpose it seems. The config
 should effect nothing the Django project cares about.

 I've done the PR and it's here:
 https://github.com/django/django/pull/14488

 (sorry if this is spammy and a waste of a ticket, but it was suggested I
 do so on the 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/053.b594058aee0b4ee0316c002e97ddd201%40djangoproject.com.

Re: [Django] #32817: Include in CsrfViewMiddleware's bad CSRF token message where the token is from

[Django]

#32817: Include in CsrfViewMiddleware's bad CSRF token message where the token 
is
from
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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
-+-
Description changed by Chris Jerdonek:

Old description:

> Currently, if `CsrfViewMiddleware` encounters a bad CSRF token, it will
> reject the request with a message like--
>
> * "CSRF token incorrect"
> * "CSRF token has incorrect length"
>
> I noticed that it would be relatively easy to include in these messages
> whether the token was obtained from `POST` data or a custom header, which
> would be useful for troubleshooting. The new messages could look e.g.
> like--
>
> * "CSRF token (from POST) incorrect"
> * "CSRF token (from 'X-CSRFToken' header) has incorrect length"
>
> The changes to `CsrfViewMiddlewareTestMixin` proposed in #32800 would
> make these cases easy to test.

New description:

 Currently, if `CsrfViewMiddleware` encounters a bad CSRF token, it will
 reject the request with a message like--

 * "CSRF token incorrect"
 * "CSRF token has incorrect length"

 I noticed that it would be relatively easy to include in these messages
 whether the token was obtained from `POST` data or a custom header, which
 would be useful for troubleshooting. The messages are specified
 
[https://github.com/django/django/blob/213850b4b9641bdcb714172999725ec9aa9c9e84/django/middleware/csrf.py#L411-L417
 here in the code]. The new messages could look e.g. like--

 * "CSRF token (from POST) incorrect"
 * "CSRF token (from 'X-CSRFToken' header) has incorrect length"

 The changes to `CsrfViewMiddlewareTestMixin` proposed in #32800 would make
 these cases easy to test.

--

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

[Django] #32817: Include in CsrfViewMiddleware's bad CSRF token message where the token is from

[Django]

#32817: Include in CsrfViewMiddleware's bad CSRF token message where the token 
is
from
+
   Reporter:  Chris Jerdonek|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  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 |
+
 Currently, if `CsrfViewMiddleware` encounters a bad CSRF token, it will
 reject the request with a message like--

 * "CSRF token incorrect"
 * "CSRF token has incorrect length"

 I noticed that it would be relatively easy to include in these messages
 whether the token was obtained from `POST` data or a custom header, which
 would be useful for troubleshooting. The new messages could look e.g.
 like--

 * "CSRF token (from POST) incorrect"
 * "CSRF token (from 'X-CSRFToken' header) has incorrect length"

 The changes to `CsrfViewMiddlewareTestMixin` proposed in #32800 would make
 these cases easy to test.

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

Re: [Django] #29186: "django.request" logging breaks "logging.handlers.SocketHandler"

[Django]

#29186: "django.request" logging breaks "logging.handlers.SocketHandler"
--+-
 Reporter:  direx |Owner:  HyunTae Hwang
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  2.0
 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
--+-

Old description:

> When setting up logging with Python's default `SocketHandler` then the
> log messages produced by `django.request` cause an exception in the
> logging system. This happens everywhere where Django passes an
> `extra={'request': request}` dictionary to log messages. The reason for
> this is that the request object cannot be pickled.
>
> Steps to reproduce (example):
>
> 1. `./manage.py startproject`
> 1. Add this logging config in settings:
> {{{
> LOGGING = {
> 'version': 1,
> 'disable_existing_loggers': False,
> 'handlers': {
> 'socket_handler': {
> 'class': 'logging.handlers.SocketHandler',
> 'host': '127.0.0.1',
> 'port': 9020,
> }
> },
> 'loggers': {
> 'django.request': {
> 'handlers': ['socket_handler'],
> 'level': 'INFO',
> 'propagate': False,
> },
> }
> }
> }}}
> 1. `./manage.py migrate`
> 1. `./manage.py runserver`
> 1. `wget http://127.0.0.1:8000/invalid -O /dev//null`
>
> The exception is this one:
>
> {{{
> --- Logging error ---
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/logging/handlers.py", line 633, in emit
> s = self.makePickle(record)
>   File "/usr/lib/python3.6/logging/handlers.py", line 605, in makePickle
> s = pickle.dumps(d, 1)
>   File "/usr/lib/python3.6/copyreg.py", line 65, in _reduce_ex
> raise TypeError("can't pickle %s objects" % base.__name__)
> TypeError: can't pickle BufferedReader objects
> Call stack:
>   File "/usr/lib/python3.6/threading.py", line 884, in _bootstrap
> self._bootstrap_inner()
>   File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
> self.run()
>   File "/usr/lib/python3.6/threading.py", line 864, in run
> self._target(*self._args, **self._kwargs)
>   File "/usr/lib/python3.6/socketserver.py", line 639, in
> process_request_thread
> self.finish_request(request, client_address)
>   File "/usr/lib/python3.6/socketserver.py", line 361, in finish_request
> self.RequestHandlerClass(request, client_address, self)
>   File "/usr/lib/python3.6/socketserver.py", line 696, in __init__
> self.handle()
>   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
> packages/django/core/servers/basehttp.py", line 154, in handle
> handler.run(self.server.get_app())
>   File "/usr/lib/python3.6/wsgiref/handlers.py", line 137, in run
> self.result = application(self.environ, self.start_response)
>   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
> packages/django/contrib/staticfiles/handlers.py", line 66, in __call__
> return self.application(environ, start_response)
>   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
> packages/django/core/handlers/wsgi.py", line 146, in __call__
> response = self.get_response(request)
>   File "/home/direx/virtualenv/django-2.0/lib/python3.6/site-
> packages/django/core/handlers/base.py", line 93, in get_response
> extra={'status_code': 404, 'request': request},
> Message: 'Not Found: %s'
> Arguments: ('/invalid',)
> }}}
>

> Of course these steps are only an example. This bug does not only apply
> to 404 errors, but also to CSRF verfication errors for instance. In fact
> all places where the `request` object is passed in as an `extra` logger
> argument.
>
> I see a few possible solutions for this issue:
>
> 1. Remove the `request` object from the `extra` log message dict. Right
> now I am not even sure why this is required.
> 1. Make the entire `request` object pickleable (probably not an easy
> task)
> 1. Pass in a reduced (pickable) version of the request object in the
> `extra` dict
> 1. Ship a compatible version of `SocketHandler`
>
> BTW: socket logging is explicitly mentioned in the Django docs:
>
> > The handler is the engine that determines what happens to each message
> in a logger. It describes a particular logging behavior, such as writing
> a message to the screen, to a file, **or to a network socket**.
>
> This bug also applies to older Django versions.

New description:

 Just wondering what the status of this is.  I get occasional errors like
 the following in my log file.  Looks like it's this same issue.  I'm
 running Django 3.1.8.


 

Re: [Django] #32815: Failed to reset ContextVars in sync/async middlewares

[Django]

#32815: Failed to reset ContextVars in sync/async middlewares
-+-
 Reporter:  Michael Manganiello  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 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 Michael Manganiello):

 Thanks for the feedback. I've filed
 https://github.com/django/asgiref/issues/267 to find the root cause.

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

Re: [Django] #32814: Improve performance of TextNode rendering by providing a special-case of render_annotated

[Django]

#32814: Improve performance of TextNode rendering by providing a special-case of
render_annotated
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * has_patch:  0 => 1


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

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

Re: [Django] #32355: Drop support for Python 3.6 & 3.7.

[Django]

#32355: Drop support for Python 3.6 & 3.7.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  4.0
 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:"213850b4b9641bdcb714172999725ec9aa9c9e84" 213850b]:
 {{{
 #!CommitTicketReference repository=""
 revision="213850b4b9641bdcb714172999725ec9aa9c9e84"
 Refs #32355 -- Used addClassCleanup() in tests.

 Inspired by Adam Johnson talk on DjangoCon Europe 2021.
 }}}

-- 
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.52749c3726c1cc71e92ad476a72e12f2%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:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * status:  new => assigned


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

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

Re: [Django] #32339: Accessibility issues with Django forms as_table, as_ul, as_p rendering helpers

[Django]

#32339: Accessibility issues with Django forms as_table, as_ul, as_p rendering
helpers
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  forms, wcag|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Jacob Rief):

 I'm strongly in favor of adding a new method `as_div()` together with
 configurable CSS classes to the form renderer. Indeed I do this myself on
 many of my own forms.
 We then maybe also should let the `__str__()`-method use that new
 `as_div()` method instead of `as_table()`.

 – just my two cents, Jacob

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

Re: [Django] #32338: Accessibility issues with Django forms RadioSelect and CheckboxSelectMultiple

[Django]

#32338: Accessibility issues with Django forms RadioSelect and
CheckboxSelectMultiple
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  forms, wcag|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Description changed by Mariusz Felisiak:

Old description:

> In the Forms API, there are issues with the default rendering of fields
> that rely on widgets based on multiple radio or checkbox inputs:
> `RadioSelect` and `CheckboxSelectMultiple`. This is with the default
> rendering of those widgets, and with the custom rendering examples in the
> official documentation. Here is a form I set up for my testing of the
> default rendering:
>
> - Live form: http://django-admin-
> tests.herokuapp.com/forms/example_form/p/
> - Form fields definitions:
> https://github.com/thibaudcolas/django_admin_tests/blob/main/django_admin_tests/forms.py
> - Template:
> https://github.com/thibaudcolas/django_admin_tests/blob/main/django_admin_tests/templates/django_admin_tests/example_form.html
>
> == RadioSelect issues
>
> 1. The fields aren’t semantically grouped, only visually, so the grouping
> isn’t apparent to assistive technlogies. It’s important that related
> fields are grouped, and that the group has a label attached to it. If I
> was auditing this professionally I would classify this as a fail for
> [https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html
> SC 1.3.1 - Info and Relationships] of WCAG 2.1, as the grouping and label
> are somewhat there, just not done with the appropriate semantics.
> 2. Speaking of label – currently the group of fields is labeled by
> preceding it with `Radio choice
> required:`. This overrides the label of the first field within
> the group (and only labels the first field, not the whole group). This is
> a fail for [https://www.w3.org/WAI/WCAG21/Understanding/labels-or-
> instructions.html 3.3.2: Labels or Instructions] and/or SC 1.3.1.
> 3. Wrapping the fields each in their own list item makes the navigation
> more tedious, as screen readers will first announce list items numbering,
> and only then their content.
>
> Here is a screenshot demonstrating the label issue with macOS VoiceOver’s
> rotor. Note how the first field has the wrong label due to the markup.
>
> [[Image(https://code.djangoproject.com/raw-attachment/ticket/32338/radio-
> select-first-input-label.png)]]
>
> == CheckboxSelectMultiple issues
>
> Almost identical to the above,
>
> - Lack of a fieldset means no semantic grouping.
> - The label isn’t associated with anything for this widget, so is less
> problematic but no more correct.
> - Wrapping the fields in list items also makes the form more verbose than
> it should be (and the semantics issues are the same).
>
> == Documentation issues
>
> Additionally to the above, there are a few occurences of custom
> radio/checkbox markup in the documentation that will lead to the same
> issues:
>
> - https://docs.djangoproject.com/en/3.1/ref/forms/widgets/#radioselect
> - https://docs.djangoproject.com/en/3.1/intro/tutorial04/#write-a
> -minimal-form
>
> == Proposed solution
>
> Essentially following [https://www.w3.org/TR/WCAG20-TECHS/H71 technique
> H71] of WCAG. The ideal solution is identical for both widgets, and also
> for documentation code snippets:
>
> 1. Wrap the group of fields in a `fieldset`, including the group’s label,
> the inputs, the help text, and any errors.
> 2. Use a `legend` as the first item in the `fieldset` for the group’s
> label, rather than a `label`.
> 3. Replace the list markup with un-semantic div, or remove altogether. If
> the list markup is needed for backwards compatibility, it could also use
> `role="presentation"` so assistive technologies ignore the list &
> listitem semantics, but I would only recommend that as a temporary
> workaround.
>
> Here is sample markup to implement the above. The `div` aren’t needed,
> I’ve only added them to preserve the vertical layout of the current
> implementation:
>
> {{{
> 
> Radio choice required:
>  name="radio_choice_required" value="one" required=""
> id="id_radio_choice_required_0">
>  One
>  name="radio_choice_required" value="two" required=""
> id="id_radio_choice_required_1">
>  Two
>  name="radio_choice_required" value="three" required=""
> id="id_radio_choice_required_2">
>  Three
>  

Re: [Django] #32338: Accessibility issues with Django forms RadioSelect and CheckboxSelectMultiple

[Django]

#32338: Accessibility issues with Django forms RadioSelect and
CheckboxSelectMultiple
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  forms, wcag|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d8c17aa10c7f41e692fb6f5d0bf2fab7a90b9374" d8c17aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="d8c17aa10c7f41e692fb6f5d0bf2fab7a90b9374"
 Refs #32338 -- Improved accessibility of RadioSelect examples in docs.

 Co-authored-by: Thibaud Colas 
 }}}

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

Re: [Django] #32338: Accessibility issues with Django forms RadioSelect and CheckboxSelectMultiple

[Django]

#32338: Accessibility issues with Django forms RadioSelect and
CheckboxSelectMultiple
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  forms, wcag|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"32b366a86482b06db417aec67e42ca23d69da48a" 32b366a8]:
 {{{
 #!CommitTicketReference repository=""
 revision="32b366a86482b06db417aec67e42ca23d69da48a"
 [3.2.x] Refs #32338 -- Improved accessibility of RadioSelect examples in
 docs.

 Co-authored-by: Thibaud Colas 

 Backport of d8c17aa10c7f41e692fb6f5d0bf2fab7a90b9374 from main
 }}}

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

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

Re: [Django] #32816: QuerysetEqual Test error on the polls app.

[Django]

#32816: QuerysetEqual Test error on the polls app.
-+-
 Reporter:  MesteRobot   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Polls, Test, | Triage Stage:
  QuerysetEqual  |  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:   => invalid
 * has_patch:  1 => 0
 * component:  Testing framework => Documentation


Comment:

 Tutorial works for me. It looks that you're using docs for Django 3.2+
 with older version of Django.

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

[Django] #32816: QuerysetEqual Test error on the polls app.

[Django]

#32816: QuerysetEqual Test error on the polls app.
-+-
   Reporter: |  Owner:  nobody
  MesteRobot |
   Type:  Bug| Status:  new
  Component:  Testing|Version:  3.2
  framework  |   Keywords:  Polls, Test,
   Severity:  Normal |  QuerysetEqual
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello.

 I walk through the polls app tutorial ... I found an error in the code on
 part5 of the tutorial;

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 def test_past_question(self):
 """
 Questions with a pub_date in the past are displayed on the
 index page.
 """
 question = create_question("Past question.", -30)
 response = self.client.get(reverse("polls:index"))
 self.assertQuerysetEqual(
 response.context["latest_question_list"],
 [question]
 )

 def test_future_question_and_past_question(self):
 """
 Even if both past and future questions exist, only past questions
 are displayed.
 """
 question = create_question(question_text="Past question.",
 days=-30)
 create_question(question_text="Future question.", days=30)
 response = self.client.get(reverse('polls:index'))
 self.assertQuerysetEqual(
 response.context['latest_question_list'],
 [question],
 )


 def test_two_past_questions(self):
 """
 The questions index page may display multiple questions.
 """
 question1 = create_question(question_text="Past question 1.",
 days=-30)
 question2 = create_question(question_text="Past question 2.",
 days=-5)
 response = self.client.get(reverse('polls:index'))
 self.assertQuerysetEqual(
 response.context['latest_question_list'],
 [question2, question1],
 )
 }}}
 }}}


 when i run the test i saw this error message:

 {{{
 Creating test database for alias 'default'...
 System check identified no issues (0 silenced).
 .F.FF...
 ==
 FAIL: test_future_question_and_past_question
 (polls.tests.QuestionIndexViewTest)
 --
 Traceback (most recent call last):
   File "D:\Samples\Django\mysite-project\polls\tests.py", line 58, in
 test_future_question_and_past_question
 self.assertQuerysetEqual(
   File "C:\Users\Mr.Robot\AppData\Roaming\Python\Python39\site-
 packages\django\test\testcases.py", line 1052, in assertQuerysetEqual
 return self.assertEqual(list(items), values, msg=msg)
 AssertionError: Lists differ: [''] !=
 []

 First differing element 0:
 ''
 

 - ['']
 ?  -  -

 + []

 ==
 FAIL: test_past_question (polls.tests.QuestionIndexViewTest)
 --
 Traceback (most recent call last):
   File "D:\Samples\Django\mysite-project\polls\tests.py", line 43, in
 test_past_question
 self.assertQuerysetEqual(
   File "C:\Users\Mr.Robot\AppData\Roaming\Python\Python39\site-
 packages\django\test\testcases.py", line 1052, in assertQuerysetEqual
 return self.assertEqual(list(items), values, msg=msg)
 AssertionError: Lists differ: [''] !=
 []

 First differing element 0:
 ''
 

 - ['']
 ?  -  -

 + []

 ==
 FAIL: test_two_past_question (polls.tests.QuestionIndexViewTest)
 --
 Traceback (most recent call last):
   File "D:\Samples\Django\mysite-project\polls\tests.py", line 67, in
 test_two_past_question
 self.assertQuerysetEqual(
   File "C:\Users\Mr.Robot\AppData\Roaming\Python\Python39\site-
 packages\django\test\testcases.py", line 1052, in assertQuerysetEqual
 return self.assertEqual(list(items), values, msg=msg)
 AssertionError: Lists differ: ['', ''] != [, ]

 First differing element 0:
 ''
 

 - ['', '']
 ?  --  --

 + [, ]

 --
 Ran 8 tests in 0.126s

 FAILED (failures=3)
 Destroying test database for alias 'default'...
 }}}

 So i search the web for solution and i found that on stackoverflow.com:
 

Re: [Django] #32812: prefetch_related() crashes with values_list(named=True).

[Django]

#32812: prefetch_related() crashes with values_list(named=True).
-+-
 Reporter:  pirelle  |Owner:  Takayuki
 |  Hirayama
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak ):

 In [changeset:"8ec5b7403d4821e080b03134943320988a41632e" 8ec5b74]:
 {{{
 #!CommitTicketReference repository=""
 revision="8ec5b7403d4821e080b03134943320988a41632e"
 [3.2.x] Fixed #32812 -- Restored immutability of named values from
 QuerySet.values_list().

 Regression in 981a072dd4dec586f8fc606712ed9a2ef116.

 Thanks pirelle for the report.

 Backport of 0393b9262dcf1b8302d35a8a470e14837ca1300b from main
 }}}

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

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

Re: [Django] #32812: prefetch_related() crashes with values_list(named=True).

[Django]

#32812: prefetch_related() crashes with values_list(named=True).
-+-
 Reporter:  pirelle  |Owner:  Takayuki
 |  Hirayama
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   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
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"0393b9262dcf1b8302d35a8a470e14837ca1300b" 0393b926]:
 {{{
 #!CommitTicketReference repository=""
 revision="0393b9262dcf1b8302d35a8a470e14837ca1300b"
 Fixed #32812 -- Restored immutability of named values from
 QuerySet.values_list().

 Regression in 981a072dd4dec586f8fc606712ed9a2ef116.

 Thanks pirelle for the report.
 }}}

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

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

[Django]

#32800: CsrfViewMiddleware unnecessarily masks CSRF cookie
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  CSRF  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


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

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