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:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Chris Jerdonek):

 > Ok, then lets make sure we have that situation tested as well and I
 think we can go ahead with it.

 I posted a preliminary PR for the purpose only of adding additional tests:
 https://github.com/django/django/pull/14485

 The PR includes tests of all combinations of masked and unmasked secrets,
 and masked and unmasked tokens (both via `POST` and the `X-CSRFToken`
 header). See `test_masked_unmasked_combinations()` in both
 `CsrfViewMiddlewareTests` and `CsrfViewMiddlewareUseSessionsTests`.

-- 
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.33b968b1834b9e73c2f443b07df519cd%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:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak):

 * 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/065.10ba6d94af3b12cb2e6aaedef0687651%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:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak):

 * severity:  Normal => Release blocker


Comment:

 Regression in 981a072dd4dec586f8fc606712ed9a2ef116.

-- 
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.58102985b203e35facd14d0c6fb411b5%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:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks, let's try.

-- 
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.77f18c33981859fa695c76968c36aa0f%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
-+-
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

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

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

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
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this report, however it looks like a support question and Trac
 is not a support channel. Moreover you're discussing `asgiref` behavior
 not Django itself. I would recommend to open
 [https://github.com/django/asgiref/issues an issue] in `asgiref`.

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

Re: [Django] #21292: A how-to or tutorial document for using authentication views and forms is needed

[Django]

#21292: A how-to or tutorial document for using authentication views and forms 
is
needed
-+---
 Reporter:  Daniele Procida  |Owner:  Uttam Singh
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by Jacob Walls):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


Comment:

 Clearing flags for any new attempt when ready.

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

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:  new
Component:  Uncategorized|  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
-+-

Comment (by Michael Manganiello):

 It seems this is not an issue only related to middlewares, but to how
 `sync_to_async` works in general? I am able to reproduce the same issue
 with this simple endpoint (when running Django using Gunicorn with Uvicorn
 workers):

 {{{
 import contextvars

 from asgiref.sync import sync_to_async
 from django.http import HttpResponse
 from django.urls import path

 current_context = contextvars.ContextVar('current_context')


 async def healthcheck(request):
 token = await sync_to_async(current_context.set,
 thread_sensitive=True)(id(request))
 await sync_to_async(current_context.reset,
 thread_sensitive=True)(token)
 return HttpResponse('OK')

 urlpatterns = [path('', healthcheck)]
 }}}

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

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:  new
Component:  Uncategorized|  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 Michael Manganiello:

Old description:

> When using a middleware that can process both sync and async requests,
> and trying to set and reset a ContextVar (in different methods of its
> request lifecycle), Python fails with error:
> `ValueError:  0x7f9a8b9ad900> at 0x7f9a68575180> was created in a different Context`
>
> This is a simple middleware example to reproduce the mentioned issue:
>
> {{{
> import contextvars
>
> current_context = contextvars.ContextVar('current_context')
>
> @sync_and_async_middleware
> class TemplateResponseMiddleware(BaseMiddleware):
> def process_view(self, request, view_func, view_args, view_kwargs):
> request.META['_CONTEXT_RESET_TOKEN'] =
> current_context.set(id(request))
>
> def process_template_response(self, request, response):
> current_context.reset(request.META['_CONTEXT_RESET_TOKEN'])
> response.context_data['mw'].append(self.__class__.__name__)
> return response
> }}}
>
> This use case is what the OpenTelemetry integration uses for spans to be
> traced in Django: https://github.com/open-telemetry/opentelemetry-python-
> contrib/blob/main/instrumentation/opentelemetry-instrumentation-
> django/src/opentelemetry/instrumentation/django/middleware.py
>
> * In `process_request`, a `ContextVar` is set, and the generated token is
> persisted in the `request.META` object.
> * In `process_response`, the `ContextVar` is reset, by using the
> persisted token.
>
> This approach works correctly for synchronous requests. However, as part
> of adding ASGI support to the Django integration for OpenTelemetry (in
> https://github.com/open-telemetry/opentelemetry-python-contrib/pull/391),
> we found that the `ContextVar` triggers the mentioned error when we want
> to reset it to its previous value. OpenTelemetry inherits from
> `MiddlewareMixin`, but I'm attaching a diff for a simple test scenario
> that reproduces the issue, using the new Middleware format.
>
> The main suspects here are the calls to `sync_to_async`, which adapt the
> middleware methods to the async flow. However, both those calls
> explicitly set `thread_sensitive=True`.
>

> Traceback for the attached test scenario:
>
> {{{
> $ ./runtests.py -k
> MiddlewareSyncAsyncTests.test_async_process_template_response
> # ...
> ERROR: test_async_process_template_response
> (middleware_exceptions.tests.MiddlewareSyncAsyncTests)
> --
> Traceback (most recent call last):
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> packages/asgiref/sync.py", line 222, in __call__
> return call_result.result()
>   File "/usr/lib/python3.9/concurrent/futures/_base.py", line 438, in
> result
> return self.__get_result()
>   File "/usr/lib/python3.9/concurrent/futures/_base.py", line 390, in
> __get_result
> raise self._exception
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> packages/asgiref/sync.py", line 287, in main_wrap
> result = await self.awaitable(*args, **kwargs)
>   File "/mnt/data/Proyectos/third_party/django/django/test/utils.py",
> line 423, in inner
> return await func(*args, **kwargs)
>   File
> "/mnt/data/Proyectos/third_party/django/tests/middleware_exceptions/tests.py",
> line 319, in test_async_process_template_response
> response = await self.async_client.get(
>   File "/mnt/data/Proyectos/third_party/django/django/test/client.py",
> line 911, in request
> self.check_exception(response)
>   File "/mnt/data/Proyectos/third_party/django/django/test/client.py",
> line 580, in check_exception
> raise exc_value
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> packages/asgiref/sync.py", line 458, in thread_handler
> raise exc_info[1]
>   File
> "/mnt/data/Proyectos/third_party/django/django/core/handlers/exception.py",
> line 38, in inner
> response = await get_response(request)
>   File
> "/mnt/data/Proyectos/third_party/django/django/core/handlers/base.py",
> line 249, in _get_response_async
> response = await middleware_method(request, response)
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> 

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:  new
Component:  Uncategorized|  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 Michael Manganiello:

Old description:

> When using a middleware that can process both sync and async requests,
> and trying to set and reset a ContextVar (in different methods of its
> request lifecycle), Python fails with error:
> `ValueError:  0x7f9a8b9ad900> at 0x7f9a68575180> was created in a different Context`
>
> This is a simple middleware example to reproduce the mentioned issue:
>
> {{{
> @sync_and_async_middleware
> class TemplateResponseMiddleware(BaseMiddleware):
> def process_view(self, request, view_func, view_args, view_kwargs):
> request.META['_CONTEXT_RESET_TOKEN'] =
> current_context.set(id(request))
>
> def process_template_response(self, request, response):
> current_context.reset(request.META['_CONTEXT_RESET_TOKEN'])
> response.context_data['mw'].append(self.__class__.__name__)
> return response
> }}}
>
> This use case is what the OpenTelemetry integration uses for spans to be
> traced in Django: https://github.com/open-telemetry/opentelemetry-python-
> contrib/blob/main/instrumentation/opentelemetry-instrumentation-
> django/src/opentelemetry/instrumentation/django/middleware.py
>
> * In `process_request`, a `ContextVar` is set, and the generated token is
> persisted in the `request.META` object.
> * In `process_response`, the `ContextVar` is reset, by using the
> persisted token.
>
> This approach works correctly for synchronous requests. However, as part
> of adding ASGI support to the Django integration for OpenTelemetry (in
> https://github.com/open-telemetry/opentelemetry-python-contrib/pull/391),
> we found that the `ContextVar` triggers the mentioned error when we want
> to reset it to its previous value. OpenTelemetry inherits from
> `MiddlewareMixin`, but I'm attaching a diff for a simple test scenario
> that reproduces the issue, using the new Middleware format.
>
> The main suspects here are the calls to `sync_to_async`, which adapt the
> middleware methods to the async flow. However, both those calls
> explicitly set `thread_sensitive=True`.
>

> Traceback for the attached test scenario:
>
> {{{
> $ ./runtests.py -k
> MiddlewareSyncAsyncTests.test_async_process_template_response
> # ...
> ERROR: test_async_process_template_response
> (middleware_exceptions.tests.MiddlewareSyncAsyncTests)
> --
> Traceback (most recent call last):
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> packages/asgiref/sync.py", line 222, in __call__
> return call_result.result()
>   File "/usr/lib/python3.9/concurrent/futures/_base.py", line 438, in
> result
> return self.__get_result()
>   File "/usr/lib/python3.9/concurrent/futures/_base.py", line 390, in
> __get_result
> raise self._exception
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> packages/asgiref/sync.py", line 287, in main_wrap
> result = await self.awaitable(*args, **kwargs)
>   File "/mnt/data/Proyectos/third_party/django/django/test/utils.py",
> line 423, in inner
> return await func(*args, **kwargs)
>   File
> "/mnt/data/Proyectos/third_party/django/tests/middleware_exceptions/tests.py",
> line 319, in test_async_process_template_response
> response = await self.async_client.get(
>   File "/mnt/data/Proyectos/third_party/django/django/test/client.py",
> line 911, in request
> self.check_exception(response)
>   File "/mnt/data/Proyectos/third_party/django/django/test/client.py",
> line 580, in check_exception
> raise exc_value
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> packages/asgiref/sync.py", line 458, in thread_handler
> raise exc_info[1]
>   File
> "/mnt/data/Proyectos/third_party/django/django/core/handlers/exception.py",
> line 38, in inner
> response = await get_response(request)
>   File
> "/mnt/data/Proyectos/third_party/django/django/core/handlers/base.py",
> line 249, in _get_response_async
> response = await middleware_method(request, response)
>   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
> packages/asgiref/sync.py", line 423, in __call__
> ret = await asyncio.wait_for(future, 

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:  new
Component:  Uncategorized|  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
-+-
Changes (by Michael Manganiello):

 * Attachment "django-issue-32815.diff" added.

 Test scenario (diff over main commit f10c52afab)

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

[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:  new
  Component:  Uncategorized|Version:  3.2
   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|
---+
 When using a middleware that can process both sync and async requests, and
 trying to set and reset a ContextVar (in different methods of its request
 lifecycle), Python fails with error:
 `ValueError:  at 0x7f9a68575180> was created in a different Context`

 This is a simple middleware example to reproduce the mentioned issue:

 {{{
 @sync_and_async_middleware
 class TemplateResponseMiddleware(BaseMiddleware):
 def process_view(self, request, view_func, view_args, view_kwargs):
 request.META['_CONTEXT_RESET_TOKEN'] =
 current_context.set(id(request))

 def process_template_response(self, request, response):
 current_context.reset(request.META['_CONTEXT_RESET_TOKEN'])
 response.context_data['mw'].append(self.__class__.__name__)
 return response
 }}}

 This use case is what the OpenTelemetry integration uses for spans to be
 traced in Django: https://github.com/open-telemetry/opentelemetry-python-
 contrib/blob/main/instrumentation/opentelemetry-instrumentation-
 django/src/opentelemetry/instrumentation/django/middleware.py

 * In `process_request`, a `ContextVar` is set, and the generated token is
 persisted in the `request.META` object.
 * In `process_response`, the `ContextVar` is reset, by using the persisted
 token.

 This approach works correctly for synchronous requests. However, as part
 of adding ASGI support to the Django integration for OpenTelemetry (in
 https://github.com/open-telemetry/opentelemetry-python-contrib/pull/391),
 we found that the `ContextVar` triggers the mentioned error when we want
 to reset it to its previous value. OpenTelemetry inherits from
 `MiddlewareMixin`, but I'm attaching a diff for a simple test scenario
 that reproduces the issue, using the new Middleware format.

 The main suspects here are the calls to `sync_to_async`, which adapt the
 middleware methods to the async flow. However, both those calls explicitly
 set `thread_sensitive=True`.


 Traceback for the attached test scenario:

 {{{
 $ ./runtests.py -k
 MiddlewareSyncAsyncTests.test_async_process_template_response
 # ...
 ERROR: test_async_process_template_response
 (middleware_exceptions.tests.MiddlewareSyncAsyncTests)
 --
 Traceback (most recent call last):
   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
 packages/asgiref/sync.py", line 222, in __call__
 return call_result.result()
   File "/usr/lib/python3.9/concurrent/futures/_base.py", line 438, in
 result
 return self.__get_result()
   File "/usr/lib/python3.9/concurrent/futures/_base.py", line 390, in
 __get_result
 raise self._exception
   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
 packages/asgiref/sync.py", line 287, in main_wrap
 result = await self.awaitable(*args, **kwargs)
   File "/mnt/data/Proyectos/third_party/django/django/test/utils.py", line
 423, in inner
 return await func(*args, **kwargs)
   File
 "/mnt/data/Proyectos/third_party/django/tests/middleware_exceptions/tests.py",
 line 319, in test_async_process_template_response
 response = await self.async_client.get(
   File "/mnt/data/Proyectos/third_party/django/django/test/client.py",
 line 911, in request
 self.check_exception(response)
   File "/mnt/data/Proyectos/third_party/django/django/test/client.py",
 line 580, in check_exception
 raise exc_value
   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
 packages/asgiref/sync.py", line 458, in thread_handler
 raise exc_info[1]
   File
 "/mnt/data/Proyectos/third_party/django/django/core/handlers/exception.py",
 line 38, in inner
 response = await get_response(request)
   File
 "/mnt/data/Proyectos/third_party/django/django/core/handlers/base.py",
 line 249, in _get_response_async
 response = await middleware_method(request, response)
   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
 packages/asgiref/sync.py", line 423, in __call__
 ret = await asyncio.wait_for(future, timeout=None)
   File "/usr/lib/python3.9/asyncio/tasks.py", line 442, in wait_for
 return await fut
   File "/home/mike/.virtualenvs/django/lib/python3.9/site-
 packages/asgiref/current_thread_executor.py", line 22, in run
 result = 

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

[Django]

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

Comment (by Andrew Godwin):

 Yeah, this is an unfortunate confluence of the way that generators get
 called (and where they get called) in the response stack - they're called
 as sync generators, not async, but also are run in an async thread.

 I suspect we should probably look at running any response generators
 inside sync_to_async, unless we can detect they're an asynchronous
 generator somehow and then use `async for` instead of `for`?

-- 
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.22cfec55c27be4aab1957b011ad409a0%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:  assigned
Component:  Database layer   |  Version:  dev
  (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 Jacob Walls):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14483 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/065.da9460de6dc88a371e609e69fb0f728c%40djangoproject.com.

Re: [Django] #32813: Display development server address after server bind

[Django]

#32813: Display development server address after server bind
-+-
 Reporter:  fmwviormv|Owner:  fmwviormv
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  development server,  | Triage Stage:
  automatic port |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * owner:  nobody => fmwviormv
 * 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.6538c9ef0475690a420bb32210561a43%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:
 |  Unreviewed
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 => Keryn Knight
 * 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.431e5d0ea0e39860db63d2977eaef7ad%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:  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 Takayuki Hirayama):

 * owner:  nobody => Takayuki Hirayama
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e8810646db0f141e358df027672a859f%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:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  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
-+-
Changes (by Keryn Knight):

 * Attachment "textnode_test.py" added.

 ad-hoc tests

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

[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:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Template system   |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 A pull request will be forthcoming shortly, should this be accepted (all
 tests pass against current `main`)

 Currently, when rendering a `TextNode` within any `NodeList` or `ForNode`
 (at least), it is always rendered via `Node.render_annotated(context)`  -
 the generic version for handling any exceptions which occur during
 rendering for which it might be preferable to augment the exception with
 additional debug data.

 This additional layer of complexity isn't free, and for `TextNode` I don't
 think it's necessary. The only way `TextNode.render(context)` can fail
 that I can think of is ending up at a `MemoryError` which is presumably
 not usefully recoverable for rendering a debug page or whatever, anyway.
 It'd be interesting to know if my mental model is wrong :)

 For rendering any single `TextNode` it's pretty cheap, but the more of
 them there are, the more compound costs stacks up, even if the interleaved
 nodes are just comment nodes (block or line).

 By way of example, below are some benchmarks with both timeit and cprofile
 instrumented. Using yappi in lieu of cProfile also shows similar outcomes,
 but is even slower. For the most complex template I had to give up waiting
 on it.

 = Wildly simplistic contrived example

 Render a  single `TextNode` containing the HTML for the standard
 html5boilerplate.

 == Using timeit (single textnode)

  before patch:
 {{{
 Running timeit for
 single_textnode
 10 loops -> 0.7104 secs
 }}}

  after patch:
 {{{
 Running timeit for
 single_textnode
 10 loops -> 0.6781 secs
 }}}
 Note that this is small enough to fluctuate quite a bit both before and
 after, so YMMV.

 == Using cProfile (single textnode)

 For the purposes of being able to determine precisely (under cProfile)
 different render_annotated calls for more complex templates (further
 down), I copy-pasted the `Node.render_annotated` definition to the
 `TextNode`, hence the line number offset of `984` ...

  before patch:
 {{{
 Running cProfile for
 single_textnode
 352 function calls in 1.398 seconds

 Ordered by: standard name

 ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 ...
 100.0140.0000.0140.000 base.py:981(render)
 100.0300.0000.0440.000 base.py:984(render_annotated)
 ...
 }}}

  after patch (`render` is never called):
 {{{
 Running cProfile for
 single_textnode
 342 function calls in 1.407 seconds

 Ordered by: standard name

 ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 ...
 100.0140.0000.0140.000 base.py:984(render_annotated)
 ...
 }}}

 = Realistic template:

 For a more realistic use case, the same situation but with
 `contrib/admin/templates/admin/change_list.html` which should be a decent
 excerciser:

 == using timeit (many textnodes + other noisy nodes)

   admin changelist + faked context, before patch:
 {{{
 Running timeit for
 admin_changelist
 10 loops -> 158.4 secs
 }}}

  same changelist template + context, after patch:
 {{{
 Running timeit for
 admin_changelist
 10 loops -> 160.9 secs
 }}}

 As I mentioned earlier, it fluctuates enough to not really be that useful,
 see?

 == using cProfile

   admin changelist + faked context, before patch:
 {{{
 Running cProfile for
 admin_changelist
 493564702 function calls (457763995 primitive calls) in 307.297 seconds

 Ordered by: standard name
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 ...
 10201.7630.0001.7630.000 base.py:981(render)
 10203.8510.0005.6140.000 base.py:984(render_annotated)
 ...
 }}}

  same changelist template + context, after patch:
 {{{
 Running cProfile for
 admin_changelist
 483364697 function calls (447563990 primitive calls) in 300.721 seconds

 Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 ...
 10201.7290.0001.7290.000 base.py:984(render_annotated)
 ...
 }}}

 = The patch itself

 It's dirt simple, which seems right for the amount of time it saves (ie:
 not much really) but not for the amount of energy I've burnt off my laptop
 

Re: [Django] #31867: Inconsistency rendering hidden fields with view-only permissions in admin

[Django]

#31867: Inconsistency rendering hidden fields with view-only permissions in 
admin
-+-
 Reporter:  Antoine Humbert  |Owner:  Antoine
 |  Humbert
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  admin hidden field   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Jacob Walls):

 * needs_better_patch:  1 => 0


Comment:

 Author made requested updates.

-- 
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/072.4c9290a954fd826579550f9e6d663142%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:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mateo Radman):

 * owner:  nobody => Mateo Radman
 * 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.69ead20c0a5b81ba91d83269e6b0ace2%40djangoproject.com.

Re: [Django] #32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig on custom admin setup

[Django]

#32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig 
on
custom admin setup
---+--
 Reporter:  Ron|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  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 Simon Meers):

 I was able to reproduce this by using an `apps.py` module inside an
 **app** instead of the **project** -- I initially missed the
 `myproject/apps.py` in the docs and assumed it belonged in `myapp/apps.py`
 which generates the `declares more than one default AppConfig`
 `RuntimeError`.

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

Re: [Django] #31356: Update IRC links in documentation.

[Django]

#31356: Update IRC links in documentation.
-+-
 Reporter:  Adam Johnson |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"b6e32903834e41299c1bdf801f639b737af146e4" b6e3290]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6e32903834e41299c1bdf801f639b737af146e4"
 [3.2.x] Refs #31356 -- Changed IRC links to the Libera.Chat webchat.

 Follow up to 66491f08fe86629fa25977bb3a06959f65e7.
 Backport of f10c52afabac25f2c10aca26d32dbe7e0e46082e 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/068.22ee27ef0eed3dae4aba60458b760d17%40djangoproject.com.

Re: [Django] #31356: Update IRC links in documentation.

[Django]

#31356: Update IRC links in documentation.
-+-
 Reporter:  Adam Johnson |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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
-+-

Comment (by GitHub ):

 In [changeset:"f10c52afabac25f2c10aca26d32dbe7e0e46082e" f10c52a]:
 {{{
 #!CommitTicketReference repository=""
 revision="f10c52afabac25f2c10aca26d32dbe7e0e46082e"
 Refs #31356 -- Changed IRC links to the Libera.Chat webchat.

 Follow up to 66491f08fe86629fa25977bb3a06959f65e7.
 }}}

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

[Django] #32813: Display development server address after server bind

[Django]

#32813: Display development server address after server bind
-+-
   Reporter:  fmwviormv  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  dev
  (Management commands)  |   Keywords:  development server,
   Severity:  Normal |  automatic port
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently Django will display server name and port before actual binding;
 so there is a problem with port 0 (automatic port):

 {{{
 $ ./manage.py runserver 127.0.0.1:0
 ...
 Starting development server at http://127.0.0.1:0/
 Quit the server with CONTROL-C.
 }}}

 in this case port number is chosen automatically by operating system
 dynamically;
 so there is no way we can find it before binding.
 Django should display port number after binding (real port number):

 {{{
 $ ./manage.py runserver 127.0.0.1:0
 ...
 Starting development server at http://127.0.0.1:25837/
 Quit the server with CONTROL-C.
 }}}

 I also have a pull-request in github:
 https://github.com/django/django/pull/14250

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

Re: [Django] #32809: Filtering with Q and OR gets duplicated entries

[Django]

#32809: Filtering with Q and OR gets duplicated entries
-+-
 Reporter:  Ismael Jerez |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  queryset, Q, | Triage Stage:
  filtering, OR, annotation, |   |  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:   => needsinfo


Comment:

 Thanks for extra details, however the described behavior is expected,
 [https://code.djangoproject.com/ticket/28292#comment:1 documented], and
 has not been changed in Django 3.2. Django < 3.2 behaves the same.

 Please reopen the ticket if you can debug your issue and provide way to
 reproduce a regression in Django 3.2

-- 
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/072.270ea8ce18f88f43c5a88bb3e00406d3%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:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_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/067.89f0bcf12514a227f35d2ee8b8ed670d%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 Mariusz Felisiak ):

 In [changeset:"ffc0d57a04141b6bc8f1263849cfcc9566cf63a8" ffc0d57a]:
 {{{
 #!CommitTicketReference repository=""
 revision="ffc0d57a04141b6bc8f1263849cfcc9566cf63a8"
 Refs #32668 -- Refactored away module_found_in_labels 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.49bf7a6c58132aa8b5011085ab144593%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 Mariusz Felisiak ):

 In [changeset:"90f41c2d9165e6e5b7c8f2229f8d01ecc4b99281" 90f41c2]:
 {{{
 #!CommitTicketReference repository=""
 revision="90f41c2d9165e6e5b7c8f2229f8d01ecc4b99281"
 Refs #32668 -- Made setup()'s test_labels argument optional in
 runtests.py.
 }}}

-- 
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.ad327c7980c60af5ebe0490466c36fc1%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 Mariusz Felisiak ):

 In [changeset:"0d2816133c7e81966bec36b2e3af2fa1ff4f12c2" 0d281613]:
 {{{
 #!CommitTicketReference repository=""
 revision="0d2816133c7e81966bec36b2e3af2fa1ff4f12c2"
 Refs #32668 -- Simplified get_test_modules() in runtests.py.

 This simplifies runtests.py's get_test_modules() in a few ways.  For
 example, it changes the function to yield strings instead of returning
 pairs of strings, which simplifies the calling code.

 This commit also changes SUBDIRS_TO_SKIP from a list to a dict since
 the directories to skip depend on the parent directory.
 }}}

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

Re: [Django] #32808: DiscoverRunner.build_suite() does not restore self.test_loader.testNamePatterns

[Django]

#32808: DiscoverRunner.build_suite() does not restore
self.test_loader.testNamePatterns
-+-
 Reporter:  Chris Jerdonek   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  3.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"62e8f369c3bdb7dbfe76d128437c0a9c0715a067" 62e8f369]:
 {{{
 #!CommitTicketReference repository=""
 revision="62e8f369c3bdb7dbfe76d128437c0a9c0715a067"
 Fixed #32808 -- Prevented DiscoverRunner.build_suite() from mutating test
 loader patterns.

 Thanks Chris Jerdonek for the report and reviews.
 }}}

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

Re: [Django] #32809: Filtering with Q and OR gets duplicated entries

[Django]

#32809: Filtering with Q and OR gets duplicated entries
-+-
 Reporter:  Ismael Jerez |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, Q, | Triage Stage:
  filtering, OR, annotation, |   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ismael Jerez):

 Forgot to mention that the bug is only happening when the second Q filter
 is used but not with simple '__icontains' filters concatenated by OR
 expressions.

-- 
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/072.f78b35d80996062df21382fda1206e35%40djangoproject.com.

Re: [Django] #32809: Filtering with Q and OR gets duplicated entries

[Django]

#32809: Filtering with Q and OR gets duplicated entries
-+-
 Reporter:  Ismael Jerez |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, Q, | Triage Stage:
  filtering, OR, annotation, |   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ismael Jerez):

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


Comment:

 Hi again:

 I am sorry for not being able to reproduce this before. Here is a simple
 example:

 1) models.py:
 {{{
 from django.contrib.auth.models import User
 from django.db import models


 class Example(models.Model):
 example_attr = models.CharField(max_length=100)
 users = models.ManyToManyField(User)
 }}}

 2) I created two User's instances from admin site:
 - username = 'admin'
 - username = 'other'

 And two Group's instances from admin site:
 - name = 'Group1'
 - name = 'Group2'

 Associate Group1 and Group2 to users 'admin' and 'other' from admin site
 too.

 3) Now the code:
 {{{
 from example.models import Example
 from django.db.models import Q
 from django.contrib.auth.models import User, Group

 example = Example.objects.create(example_attr='have a nice day')
 user1 = User.objects.get(username='admin')
 user2 = User.objects.get(username='other')
 example.users.add(user1, user2)
 filters = Q(example_attr__icontains='a') |
 
Q(users__in=User.objects.filter(groups__in=[Group.objects.get(name='Group1').pk]))
 print(Example.objects.count()) # This prints "1"
 print(Example.objects.filter(filters).count()) # This prints "2"
 }}}

 Hope this helps to reproduce the bug.

 This bug is happening since Django 3.2.0 until 3.2.4.


 Thanks in advance,
 Ismael.

-- 
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/072.43a29428a39000efe79d75c7e5998635%40djangoproject.com.