[Django] #35310: Optimize automatic JSON encoding of data in test client

[Django]

#35310: Optimize automatic JSON encoding of data in test client
-+-
   Reporter:  Kasun  |  Owner:  Kasun Herath
  Herath |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Testing|Version:  dev
  framework  |
   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  |
-+-
 Test client post, put, patch and delete methods automatically encode
 request data to JSON if `content_type` parameter is set to
 `application/data`.

 Example
 {{{
 client.post(url, data=data, content_type="application/json")
 }}}
 Would automatically encode data as JSON.

 We could also check the headers for content_type header and do the
 automatic encoding to be consistent.

 example
 {{{
 client.post(url, data=data, headers={"content_type": "application/json"})
 }}}

 Can automatically encode data into JSON using the same mechanism.
-- 
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/0107018e45ed21ff-d3f5f0ea-c395-44b8-a1f6-82a685606bed-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch order_by| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Laurent Lyaudet):

 * 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/0107018e45e1768a-107e903a-054f-42be-ae93-a96f808a-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch order_by| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Laurent Lyaudet):

 I spent my night on it but I was able to make a patch, and I don't think
 there will be any regression.
 Consider the following models in some project
 TestNoOrderByForForeignKeyPrefetches and some app test_no_order_by
 models.py file:

 {{{#!python
 from django.core.management.base import BaseCommand
 from django.db import connection
 from django.db.models import Prefetch, QuerySet, RawQuerySet
 from django.db.models.fields.related_descriptors import (
 ForwardManyToOneDescriptor,
 ReverseOneToOneDescriptor,
 )

 from TestNoOrderByForForeignKeyPrefetches.test_no_order_by.models import
 A, B


 old_prefetch_init = Prefetch.__init__


 def new_prefetch_init(self, *args, **kwargs):
 result = old_prefetch_init(self, *args, **kwargs)
 if self.queryset is not None:
 self.queryset._do_not_modify_order_by = True
 return result


 Prefetch.__init__ = new_prefetch_init


 old_get_prefetch_querysets_forward_many_to_one =
 ForwardManyToOneDescriptor.get_prefetch_querysets
 old_get_prefetch_querysets_reverse_one_to_one =
 ReverseOneToOneDescriptor.get_prefetch_querysets


 def get_prefetch_querysets_forward_many_to_one(self, *args, **kwargs):
 result = old_get_prefetch_querysets_forward_many_to_one(self, *args,
 **kwargs)
 if not hasattr(result[0], '_do_not_modify_order_by'):
 result = (result[0].order_by(), *result[1:])
 return result


 def get_prefetch_querysets_reverse_one_to_one(self, *args, **kwargs):
 result = old_get_prefetch_querysets_reverse_one_to_one(self, *args,
 **kwargs)
 if not hasattr(result[0], '_do_not_modify_order_by'):
 result = (result[0].order_by(), *result[1:])
 return result


 ForwardManyToOneDescriptor.get_prefetch_querysets =
 get_prefetch_querysets_forward_many_to_one
 ReverseOneToOneDescriptor.get_prefetch_querysets =
 get_prefetch_querysets_reverse_one_to_one


 old_clone_queryset = QuerySet._clone


 def new_clone_queryset(self):
 result = old_clone_queryset(self)
 if hasattr(self, '_do_not_modify_order_by'):
 result._do_not_modify_order_by = True
 return result


 QuerySet._clone = new_clone_queryset


 old_clone_raw_queryset = RawQuerySet._clone


 def new_clone_raw_queryset(self):
 result = old_clone_raw_queryset(self)
 if hasattr(self, '_do_not_modify_order_by'):
 result._do_not_modify_order_by = True
 return result


 RawQuerySet._clone = new_clone_raw_queryset


 class Command(BaseCommand):
 help = "Test"

 def handle(self, *args, **options):
 B.objects.all().delete()
 A.objects.all().delete()

 a1 = A.objects.create(name="a1")
 a2 = A.objects.create(name="a2")
 a3 = A.objects.create(name="a3")
 a4 = A.objects.create(name="a4")
 a5 = A.objects.create(name="a5")
 a6 = A.objects.create(name="a6")
 a7 = A.objects.create(name="a7")

 b1 = B.objects.create(a=a1, name="b1")
 b2 = B.objects.create(a=a2, name="b2")
 b3 = B.objects.create(a=a3, name="b3")
 b4 = B.objects.create(a=a4, name="b4")
 b5 = B.objects.create(a=a5, name="b5")
 b6 = B.objects.create(a=a6, name="b6")
 b7 = B.objects.create(a=a7, name="b7")

 bs = list(B.objects.all().prefetch_related("a"))
 a_s = list(A.objects.all().prefetch_related("bs"))
 bs = list(B.objects.all().prefetch_related(
 Prefetch(
 "a",
 queryset=A.objects.order_by("-name")
 ),
 ))
 a_s = list(A.objects.all().prefetch_related(
 Prefetch(
 "bs",
 queryset=B.objects.order_by("-name")
 ),
 ))
 print(connection.queries)
 }}}

 If you launch the command with python3 manage.py test_no_order_by_command,
 you will see that there are 8 SELECT after the 14 INSERT and that there is
 only 7 ORDER BY on them as requested.

 I will prepare a PR.
-- 
Ticket URL: 
Django 
The We

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch order_by| 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 Charette):

 Please refrain from assuming bad faith from triagers regarding the
 resolution of this ticket. The provided resolution was a reflected based
 on your report details and in no way based on your persona.

 What do you suggest should happen for the thousands of projects out there
 that rely on `prefetch_related` to return results in a way that respects
 `Meta.ordering`? We can't simply make the behaviour of `prefetch_related`
 inconsistent with the normal behaviour or related manager access because
 it performs poorly when defined against an non-indexed field. I think the
 documentation warning I referred to is unfortunately all we can do to warn
 about this behaviour. Either use `Meta.ordering` and be prepared to deal
 with its implicit footguns or don't use it and use `order_by` where
 appropriate.

 Whether `Meta.ordering` should exist in the first place is debatable as
 it's at the origin of many unexpected behaviour with other features of the
 ORM (aggregation comes to mind) but making `prefetch_related` special case
 it would not only be backward incompatible but inconsistent with how the
 rest of the framework treats it.
-- 
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/0107018e45219a8c-4cf523eb-82b6-49f8-828a-923a60e82a0b-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch order_by| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Laurent Lyaudet):

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

-- 
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/0107018e44af63f1-9cef1a2c-b83c-4cc4-8727-47ee8a66d872-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  prefetch order_by| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Laurent Lyaudet):

 Again a fast and without thought answer.
 I already know for this solution with Prefetch.
 Continue bashing good ideas because you don't like people giving them.
 I'll applaude at the end.

 There is no way it is useful to keep an order by when you do a query

 SELECT * FROM a WHERE a.id IN (.100 or more ids here) ORDER BY name;

 then add the result in the cache of B objects.
 What you reject without thought yields a speed-up of 10 to 15 % on very
 big prefetches...
-- 
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/0107018e44aea931-c52f5858-1587-478c-bac0-3dc851f82f5b-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  prefetch order_by| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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

Comment:

 `Meta.ordering` is working as expected, please
 [https://docs.djangoproject.com/en/5.0/ref/models/options/#ordering refer
 to its documentation] and associated warning

 > Ordering is not a free operation. Each field you add to the ordering
 incurs a cost to your database. Each foreign key you add will implicitly
 include all of its default orderings as well.

 If you don't want this implicit behaviour then don't use `Meta.ordering`.
 If you want to keep using it but not for particular prefetches than use
 `Prefetch` objects with a queryset that explicitly calls `order_by()` to
 disable ordering.

 {{{#!python
 B.objects.prefetch_related(Prefetch("a", A.objects.order_by()))
 }}}
-- 
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/0107018e449d29fd-40c001e8-74dd-4a3a-924e-0a2a190708ae-00%40eu-central-1.amazonses.com.

[Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
   Reporter:  Laurent|  Owner:  nobody
  Lyaudet|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  5.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  prefetch order_by
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 I don't know if the "bug" is still here with Django 5.
 But on my version of Django, I have the following "bug" :
 Assume you have the following code :

 {{{#!python
 class A(models.Model):
 name = models.CharField(max_length=200)

 class Meta:
 ordering = ["name"]


 class B(models.Model):
 a = models.ForeignKey(A, related_name="bs", on_delete=models.CASCADE)


 a1 = A.objects.create(name="a1")
 a2 = A.objects.create(name="a2")
 a3 = A.objects.create(name="a3")
 a4 = A.objects.create(name="a4")
 a5 = A.objects.create(name="a5")
 a6 = A.objects.create(name="a6")
 a7 = A.objects.create(name="a7")

 b1 = B.objects.create(a=a1)
 b2 = B.objects.create(a=a2)
 b3 = B.objects.create(a=a3)
 b4 = B.objects.create(a=a4)
 b5 = B.objects.create(a=a5)
 b6 = B.objects.create(a=a6)
 b7 = B.objects.create(a=a7)

 bs = B.objects.all().prefetch_related("a")
 }}}

 The prefetch of as will use the order by and add useless charge on the DB
 server.
 There may be other cases than ForeignKey where the order by is useless.
 But since OneToOne inherits from ForeignKey, I don't see anything else
 right now.

 Hence, I request this enhancement, please :)
 #ClimateChangeBrake

 Best regards,
 Laurent Lyaudet
-- 
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/0107018e441bdcfa-821fa4bc-9163-4caf-bafe-cec82c9d0649-00%40eu-central-1.amazonses.com.

Re: [Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

[Django]

#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
-+
 Reporter:  Sergey Fedoseev  |Owner:  Tom L.
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tom L.):

 * owner:  Vadim Fabrichnov => Tom L.

-- 
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/0107018e43f4d30b-51f2b237-bfa2-4bc1-abbc-787c27332ed2-00%40eu-central-1.amazonses.com.

Re: [Django] #25068: Metaclass conflict when doing createmigrations in ModelState.render

[Django]

#25068: Metaclass conflict when doing createmigrations in ModelState.render
-+-
 Reporter:  kosz85   |Owner:  Tom L.
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  metaclass conflict   | Triage Stage:  Accepted
  createmigrations   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom L.):

 * owner:  Ethan J. Howell => Tom L.

-- 
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/0107018e43f311e0-28a53f0a-9dbe-4e28-8af0-6e8c57473183-00%40eu-central-1.amazonses.com.

Re: [Django] #35308: FileNotFoundError escapes from run_formatters()

[Django]

#35308: FileNotFoundError escapes from run_formatters()
---+--
 Reporter:  Jacob Walls|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  4.2
 Severity:  Normal |   Resolution:
 Keywords:  black  | 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:

> Two members of my team have now run into
> [https://forum.djangoproject.com/t/black-library-error/20897/3 this
> issue] described on the Django forum.
>
> In essence, it's not safe to assume that just because
> `shutil.which("black")` returns a path that `subprocess.run()` can
> execute that path.
>
> Some [https://docs.python.org/3/library/shutil.html#shutil.which
> complications] with `shutil.which(..., path=None)`:
> - Reads a path variable from one or two fallbacks (either os.environ() or
> os.defpath)
> - Behavior is different on Windows
> - Behavior is different on Windows with Python 3.12.0
> - Behavior is different on Windows with Python 3.12.1
>
> My impression of the feature was that it was aiming at a frictionless
> experience -- format if you have a working black install, don't if you
> don't.
>
> Suggesting we should catch `FileNotFoundError` (at least) and at most log
> out an explanation why the file wasn't formatted. Users who only have a
> copy of black in abandoned environments are unlikely to care about their
> files not being formatted. :-)

New description:

 A couple coworkers of mine have now run into
 [https://forum.djangoproject.com/t/black-library-error/20897/3 this issue]
 described on the Django forum.

 In essence, it's not safe to assume that just because
 `shutil.which("black")` returns a path that `subprocess.run()` can execute
 that path.

 Some [https://docs.python.org/3/library/shutil.html#shutil.which
 complications] with `shutil.which(..., path=None)`:
 - Reads a path variable from one or two fallbacks (either os.environ() or
 os.defpath)
 - Behavior is different on Windows
 - Behavior is different on Windows with Python 3.12.0
 - Behavior is different on Windows with Python 3.12.1

 My impression of the feature was that it was aiming at a frictionless
 experience -- format if you have a working black install, don't if you
 don't.

 Suggesting we should catch `FileNotFoundError` (at least) and at most log
 out an explanation why the file wasn't formatted. Users who only have a
 copy of black in abandoned environments are unlikely to care about their
 files not being formatted. :-)

--
-- 
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/0107018e43cb624d-79aadedc-84e9-4890-848a-188bfaf2a283-00%40eu-central-1.amazonses.com.

[Django] #35308: FileNotFoundError escapes from run_formatters()

[Django]

#35308: FileNotFoundError escapes from run_formatters()
-+
   Reporter:  Jacob Walls|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  4.2
   Severity:  Normal |   Keywords:  black
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Two members of my team have now run into
 [https://forum.djangoproject.com/t/black-library-error/20897/3 this issue]
 described on the Django forum.

 In essence, it's not safe to assume that just because
 `shutil.which("black")` returns a path that `subprocess.run()` can execute
 that path.

 Some [https://docs.python.org/3/library/shutil.html#shutil.which
 complications] with `shutil.which(..., path=None)`:
 - Reads a path variable from one or two fallbacks (either os.environ() or
 os.defpath)
 - Behavior is different on Windows
 - Behavior is different on Windows with Python 3.12.0
 - Behavior is different on Windows with Python 3.12.1

 My impression of the feature was that it was aiming at a frictionless
 experience -- format if you have a working black install, don't if you
 don't.

 Suggesting we should catch `FileNotFoundError` (at least) and at most log
 out an explanation why the file wasn't formatted. Users who only have a
 copy of black in abandoned environments are unlikely to care about their
 files not being formatted. :-)
-- 
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/0107018e43c411e5-765707fc-ba07-4f4f-a5cc-90813b34c8e8-00%40eu-central-1.amazonses.com.

[Django] #35307: make async generic views

[Django]

#35307: make async generic views
-+
   Reporter:  amirreza   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Generic views  |Version:  dev
   Severity:  Normal |   Keywords:  async, generic
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 hello
 i'm very new to async so this might be very dumb or maybe not, i didn't
 find anything about it with google so might as well see

 i think we should add async generic class based views

 my reasons:
 1- easy to use
 2- makes writing docs and tutorials on async django easier
 3- it can be used as a standard on how to write async class based views
 4- can attract more devs to use and contribute to async django

 also i think seprating normal gcbv and async ones can make the code easier
 to debug
 also leaves less un-used code in classes
 and makes learning this much easier for beginners

 anyways i hope this is not dumb :) and can help django improve
-- 
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/0107018e43bb0237-b075f139-fc26-4530-a1f6-6ccdb35b4f87-00%40eu-central-1.amazonses.com.

[Django] #35306: Localisation of dates very confusing - why can't it be turned off anymore?

[Django]

#35306: Localisation of dates very confusing - why can't it be turned off 
anymore?
-+-
   Reporter: |  Owner:  nobody
  richardthegit  |
   Type:  Bug| Status:  new
  Component: |Version:  5.0
  Internationalization   |   Keywords:  LANGUAGE_CODE,
   Severity:  Normal |  DATE_FORMAT
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The doc:

 https://docs.djangoproject.com/en/5.0/ref/settings/#language-code

 specifically states:

 "USE_I18N must be active for this setting to have any effect."

 This is not true. If `USE_I18N` is `False` and a language can not be
 determined (e.g. the locale middleware is not active), the `date` template
 filter will use the value of `LANGUAGE_CODE`.

 I think the handling of date formatting is now very confusing, and the doc
 for `DATE_FORMAT`, `DATETIME_FORMAT`, etc is at best incomplete because
 it's very difficult to understand when (if ever) these settings are
 actually used now that the `USE_L10N` setting has been fully deprecated.

 I'm not raising this as a doc issue because I think this system is now
 somewhat broken. Personally I think that `USE_L10N` should be brought
 back; there needs to be a way to turn off localisation of dates (and
 numbers) separately to translations - they're not the same thing.

 I know I can force a particular locale to be used via `LANGUAGE_CODE`, but
 I specifically want my format to be used, and the existing `DATE_FORMAT`,
 etc settings seems like the right way to do that. I just need a way to
 force their use, which used to be simply setting `USE_L10N = True`.
-- 
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/0107018e4345b9b5-549931c7-e97a-4786-a71a-1bc0a0c74098-00%40eu-central-1.amazonses.com.

Re: [Django] #24076: Query may fail with pytz exception

[Django]

#24076: Query may fail with pytz exception
---+
 Reporter:  lvella |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.6
 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 Adam Zapletal):

 * cc: Adam Zapletal (added)

Comment:

 I wonder if this issue can be closed with no documentation changes for the
 following reasons:

 1. The `__date__gte` lookup (mentioned in comment 1) and others for
 `DateTimeField` have been implemented for a long time.
 2. `pytz` has been removed as of Django 5.0.
 3. Support for time zones has now been core to Django for almost 12 years.
 4. The documentation for the lookup mentioned above seems sufficient to me
 to help future users wondering how to compare a `DateTimeField` with a
 `datetime.date`:
 https://docs.djangoproject.com/en/dev/ref/models/querysets/#date.

 However, I'd be happy to work on a documentation patch if someone can
 provide an idea of what is needed to close 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/0107018e42915eb7-ae49bf1a-ed09-4809-b035-b97bfba6ac13-00%40eu-central-1.amazonses.com.

[Django] #35305: No-op rename of field with `db_column` drops and recreates constraints

[Django]

#35305: No-op rename of field with `db_column` drops and recreates constraints
+
   Reporter:  Jacob Walls   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Migrations|Version:  4.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 |
+
 With this model:
 {{{
 class MyModel(models.Model):
 foo = models.BooleanField(db_column="foobar")

 class Meta:
 constraints = [
 models.UniqueConstraint(
 fields=["foo"],
 name="unique_foo",
 ),
 ]
 }}}

 Suppose I wish to improve the name of the field so it agrees with the
 database column name:

 {{{
 class MyModel(models.Model):
 foobar = models.BooleanField(db_column="foobar")

 class Meta:
 constraints = [
 models.UniqueConstraint(
 fields=["foobar"],
 name="unique_foo",
 ),
 ]
 }}}

 That change generates a migration with this SQL, assuming you answer "was
 the field ... renamed..." with Yes:
 {{{
 BEGIN;
 --
 -- Remove constraint unique_foo from model mymodel
 --
 ALTER TABLE "models_mymodel" DROP CONSTRAINT "unique_foo";
 --
 -- Rename field foo on mymodel to foobar
 --
 -- (no-op)
 --
 -- Create constraint unique_foo on model mymodel
 --
 ALTER TABLE "models_mymodel" ADD CONSTRAINT "unique_foo" UNIQUE
 ("foobar");
 COMMIT;
 }}}

 Suggesting that we compare on `db_column` if present to allow this kind of
 change to be a no-op with respect to constraints.
-- 
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/0107018e42878eb6-a2fa0d1a-ae19-4853-95c1-269a715f62d5-00%40eu-central-1.amazonses.com.

Re: [Django] #35298: LANGUAGE_CODE: zh-Hant does not work for some translations on the admin site.

[Django]

#35298: LANGUAGE_CODE: zh-Hant does not work for some translations on the admin
site.
-+-
 Reporter:  twFroggen|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  5.0
  Internationalization   |
 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 Natalia Bidart):

 Replying to [comment:3 twFroggen]:
 > Replying to [comment:2 Natalia Bidart]:
 > Thank you for your reply. I visited the Transifex website and noticed
 that, as you mentioned, the zh-Hant translation is not 100% complete.
 However, I have a question: I found some strings in the Django source code
 that are present in the .po files, but they are not correctly translated.
 Why is that?

 Translations are completed by volunteers from our community who donate
 their time when they can. If you notice any incorrect or missing
 translations, and if you have the availability to contribute, we encourage
 you to join the translation team for your language. Please reach out in
 the  [https://forum.djangoproject.com/c/internals/i18n/14 ​Django Forum's
 Internationalization category] to be added to the language team of your
 choice and help improve these translations.

 Thanks!
-- 
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/0107018e4260d2a3-f9cf8b48-5600-44cd-b364-c88c6fa5ccf7-00%40eu-central-1.amazonses.com.

Re: [Django] #35298: LANGUAGE_CODE: zh-Hant does not work for some translations on the admin site.

[Django]

#35298: LANGUAGE_CODE: zh-Hant does not work for some translations on the admin
site.
-+-
 Reporter:  twFroggen|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  5.0
  Internationalization   |
 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 twFroggen):

 Replying to [comment:2 Natalia Bidart]:
 Thank you for your reply. I visited the Transifex website and noticed
 that, as you mentioned, the zh-Hant translation is not 100% complete.
 However, I have a question: I found some strings in the Django source code
 that are present in the .po files, but they are not correctly translated.
 Why is that?



 > Hello twFroggen!
 >
 > Thank you for your report. Please note that the issue you are describing
 is caused by the English string not having an available translation for
 the language you are using.
 > Translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations
 Transifex], the normal workflow is to translate strings using the
 Transifex platform (https://explore.transifex.com/django/django-docs/),
 and then periodically, we fetch the translations from Transifex to put
 them in this repo.
 >
 > For more information and help, you can post in the
 [https://forum.djangoproject.com/c/internals/i18n/14 Django Forum].
-- 
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/0107018e424d6554-0451cf89-7ae5-479a-b68b-5fa967f12cbf-00%40eu-central-1.amazonses.com.

Re: [Django] #35284: PositiveIntegerField description is confusing

[Django]

#35284: PositiveIntegerField description is confusing
-+-
 Reporter:  Jon Ribbens  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  5.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Comment (by Jon Ribbens):

 Replying to [comment:12 Natalia Bidart]:
 > Replying to [comment:11 Jon Ribbens]:
 > > Actually it conveys the precise opposite information, it suggests that
 it is foreseen that in the future, the behaviour may change so that zero
 will not be accepted, and so if you want to store zeroes you should not be
 using this field type. It is saying "we don't think this field should
 accept zeroes, but we haven't been able to fix it yet because of backwards
 compatibility considerations, so that change is still on the to-do list".
 >
 > I understand that this is how ''you'' read the sentence, but we disagree
 on what it means.

 Which pretty much by definition means it's unclear, which is what I said
 all along. I'm not sure why you want it to remain unclear, but as I said,
 I can't force you to improve things.
-- 
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/0107018e422882a3-cf28d89b-ac4a-4483-8554-49bebba2d884-00%40eu-central-1.amazonses.com.

Re: [Django] #35304: IntegerField trailing decimal and zeros

[Django]

#35304: IntegerField trailing decimal and zeros
---+--
 Reporter:  Piotr Kotarba  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  5.0
 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 David Sanders):

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

Comment:

 Hi there 👋

 Trac is for reporting bugs with Django. If you just want to start a
 discussion on something you'll need to head over to Discord or the Forum,
 details here: https://www.djangoproject.com/community/

 Thanks!
-- 
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/0107018e42287ce3-d8b1b9a9-30fe-42c1-a189-e329ca09d382-00%40eu-central-1.amazonses.com.

[Django] #35304: IntegerField trailing decimal and zeros

[Django]

#35304: IntegerField trailing decimal and zeros
-+
   Reporter:  Piotr Kotarba  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Forms  |Version:  5.0
   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 have a little concern in regard of stripping trailing decimal and zeros.

 IntegerField Uses NumberInput as widget, which allows to pass Numbers with
 trailing zeros.
 For example, below numbers are valid:
 10
 10.00
 10,00

 Shouldn't IntegerField accept only Integers?

 Below method uses _lazy_re_compile to get rid of them.

 {{{
 def to_python(self, value):
 """
 Validate that int() can be called on the input. Return the result
 of int() or None for empty values.
 """
 value = super().to_python(value)
 if value in self.empty_values:
 return None
 if self.localize:
 value = formats.sanitize_separators(value)
 # Strip trailing decimal and zeros.
 try:
 value = int(self.re_decimal.sub('', str(value)))
 except (ValueError, TypeError):
 raise ValidationError(self.error_messages['invalid'],
 code='invalid')
 return value
 }}}


 I have found related issue:
 https://code.djangoproject.com/ticket/24229

 The reason of this functionality as I understand was:
 "Django forms are useful for validating user input beyond just HTML
 forms."
 "One issue, MS Excel represents all numbers in cells as floats, even
 integers. So for this to work, a float with value 1.0 should be cleaned by
 forms.IntegerField as 1. "

 I am sceptic to this solution, and as Django main purpose is to be used on
 HTML, it shouldn't have such functionality in its core.
 Also I think that this issue was created when there was no inputs, and
 HTML looked different as well. Lots have changed since then.

 What do you think?
-- 
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/0107018e420e814a-89119f2a-9b9f-4b48-bac7-d26c040b4f43-00%40eu-central-1.amazonses.com.

Re: [Django] #15059: Additional Documentation for the objects in the admin templates

[Django]

#15059: Additional Documentation for the objects in the admin templates
-+-
 Reporter:  mlakewood|Owner:  Hassan
 Type:   |  Mian
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  admin templates  | Triage Stage:  Accepted
  override   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan Cheley):

 * cc: Ryan Cheley (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/0107018e4209a0e5-8ad8c946-d31d-41cc-b9ed-5850c495a6b2-00%40eu-central-1.amazonses.com.

Re: [Django] #34900: Python 3.13 compatibility.

[Django]

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

 In [changeset:"b231bcd19e57267ce1fc21d42d46f0b65fdcfcf8" b231bcd1]:
 {{{#!CommitTicketReference repository=""
 revision="b231bcd19e57267ce1fc21d42d46f0b65fdcfcf8"
 Refs #34900 -- Fixed SafeMIMEText.set_payload() crash on Python 3.13.

 Payloads with surrogates are passed to the set_payload() since
 
https://github.com/python/cpython/commit/f97f25ef5dfcdfec0d9a359fd970abd139cf3428
 }}}
-- 
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/0107018e41f42dc4-1aba624a-d25f-486a-9633-1a863a359392-00%40eu-central-1.amazonses.com.

Re: [Django] #19515: Increase the max_length of Redirect.old_path/new_path

[Django]

#19515: Increase the max_length of Redirect.old_path/new_path
-+-
 Reporter:  s.shanabrook@…   |Owner:  Michael
 Type:   |  Howitz
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.redirects|  Version:  dev
 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
-+-
Comment (by Mariusz Felisiak):

 Blocked by #28661.
-- 
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/0107018e41ec3c7f-52f5727c-7bdc-4298-856f-b910f198f58c-00%40eu-central-1.amazonses.com.

Re: [Django] #33996: Inconsistent behavior of CheckConstraints validation on None values.

[Django]

#33996: Inconsistent behavior of CheckConstraints validation on None values.
-+-
 Reporter:  James Beith  |Owner:  David
 |  Sanders
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (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 GitHub ):

 In [changeset:"36a000858b5eee13b039aaad490c33b037a1dc05" 36a00085]:
 {{{#!CommitTicketReference repository=""
 revision="36a000858b5eee13b039aaad490c33b037a1dc05"
 Refs #33996 -- Updated CheckConstraint validation on NULL values on Oracle
 23c+.

 Oracle 23c supports comparing boolean 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/0107018e41e4d507-4da1faf6-93f6-40a2-a052-e534c50d8548-00%40eu-central-1.amazonses.com.

Re: [Django] #35294: Queryset explain can be truncated.

[Django]

#35294: Queryset explain can be truncated.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  explain  | 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 Gordon Wrigley):

 Thank you.
-- 
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/0107018e41a29c65-a8cfda2f-b484-48b4-93be-5ba62ec79f57-00%40eu-central-1.amazonses.com.

Re: [Django] #35294: Queryset explain can be truncated.

[Django]

#35294: Queryset explain can be truncated.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  explain  | 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 ):

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

Comment:

 In [changeset:"cbf1e87398a58737e27e1b680283903caf661f90" cbf1e87]:
 {{{#!CommitTicketReference repository=""
 revision="cbf1e87398a58737e27e1b680283903caf661f90"
 Fixed #35294 -- Fixed TEXT format of QuerySet.explain() for long plans.

 co-authored-by: Gordon 
 co-authored-by: Simon Charette 
 }}}
-- 
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/0107018e418542d3-df237ba6-c2f4-490c-89b3-a877e19dba01-00%40eu-central-1.amazonses.com.

Re: [Django] #35233: Push templates checks down to backend engine classes

[Django]

#35233: Push templates checks down to backend engine classes
-+-
 Reporter:  Adam Johnson |Owner:  Giannis
 Type:   |  Terzopoulos
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 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 Giannis Terzopoulos):

 * has_patch:  0 => 1

Comment:

 Thank you for the explanation. I opened a PR for this
 [https://github.com/django/django/pull/17981 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/0107018e4181a670-aa6a5c28-d5f8-4264-af22-86b9887c87dc-00%40eu-central-1.amazonses.com.

Re: [Django] #35303: Add async implementations to contrib.auth backends

[Django]

#35303: Add async implementations to contrib.auth backends
--+--
 Reporter:  Jon Janzen|Owner:  Jon Janzen
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  5.0
 Severity:  Normal|   Resolution:
 Keywords:  async auth| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Carlton Gibson):

 * cc: Carlton Gibson (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/0107018e4101fd89-244a5a6b-da8c-4217-a0f9-cda819ad38f0-00%40eu-central-1.amazonses.com.

Re: [Django] #35276: Push cache backend checks down to backend classes

[Django]

#35276: Push cache backend checks down to backend classes
--+
 Reporter:  Adam Johnson  |Owner:  Almaz
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (System checks)  |  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 Pro100-Almaz):

 Yes, I am still working on 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/0107018e40f4a048-4197e369-f814-4da5-b0c5-47ad9fb6e00b-00%40eu-central-1.amazonses.com.