Hey James. Grrr. 😬
I don't think this justifies an exception to the backport policy. It's not significantly different from any of any number of other fixes that folks ask for a backport for and we say no. Fielding "but you backported that one" isn't an extra task that's going to be helpful. When I looked at the trace you posted in IRC yesterday, my first thought was "3.2?". I think supporting Django 3.2 at this point isn't worth the effort. Yes, sure it's not EOL for another year or so but if folks want to use async they should be on the latest version. There's significant changes still in each version, and sticking on the old LTS is asking for trouble. (I certainly don't see making exceptions to the backport policy to help out such to be a good idea. The old LTS is for frozen apps, not new development.) You're wanting to add async support to your third-party library: super; just say it's 4.2+ and move on. Folks who aren't on the LTS will be updating shortly enough anyway. A little-bit of carrot never hurt. Kind Regards, Carlton On Fri, 30 Dec 2022 at 01:44, James Bennett <ubernost...@gmail.com> wrote: > https://code.djangoproject.com/ticket/34063 > > The short summary of that ticket is that there was a significant > behavioral difference between django.test.Client and > django.test.AsyncClient: with AsyncClient, any view or middleware > which attempted to access request.POST without first accessing > request.body would raise an exception with an obscure message about > trying to read too much data from the request body. This was fixed > last month: > > > https://github.com/django/django/commit/c4eaa67e2b880db778c9fe6d9854fbdfcc16ecd2 > > However, it does not explicitly fall under any of the criteria for > backporting to older releases > ( > https://docs.djangoproject.com/en/dev/internals/release-process/#supported-versions > ) > so at the moment, the fix will only be available from Django 4.2 > onward, and no previous Django versions will receive a backported > version of the fix (though the bug is present back to at least Django > 3.2, and I suspect but haven't confirmed all the way back to the > introduction of AsyncClient in Django 3.1). > > I'd like to argue for an exception to the normal backport policy, and > for #34063 to be backported to Django 4.1, 4.0, and 3.2 LTS. > > My reasoning here is that async support is an incredibly important > part of the Python web ecosystem right now, and there is no good > alternative to django.test.AsyncClient for testing some kinds of async > code -- although the normal django.test.Client can hit URLs served by > async views, it does not always trigger async code paths inside Django > when doing so. For example, I came across #34063 while trying to test > a middleware that supports both sync and async usage; only AsyncClient > reliably exercises the async code path of such a middleware, but that > triggers the bug unless I add throwaway accesses of request.body. > > Especially for authors of reusable applications/libraries that try to > support a broad range of Django versions, many of whom (like me!) are > finally getting around to async support, this is an unpleasant > situation, since it will require the request.body workaround to be > left in place in all such code for at least another 16 months or so > (which is when Django 3.2 LTS will finally drop out of upstream > support). And that's presuming such authors even know to put in the > workaround -- it took me quite a bit of debugging and following up on > irrelevant search results before I finally found #34063, and that's as > someone who has deep familiarity with Django -- someone less > experienced at delving into Django's internals to figure out root > causes and likely search terms would probably have had an even worse > time of it. > > Finally, if it had been discovered prior to any of the releases in > which AsyncClient has been present, this would have been a clear > release blocker; it's quite a serious bug that seems to have gone > unnoticed for so long largely by accident (and, ironically, by > under-testing of the testing tools). > > So I think the right thing to do, to help with Django's transition > into async support and to avoid imposing unnecessary burdens of > debugging on application and library authors, is to backport the fix > from #34063 to the full set of currently-supported Django releases: > 4.1, 4.0, and 3.2 LTS. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAL13Cg-Pexnfd7ynnOWEoLkmfM5gYhcMfHgkYzOG7nH8sWA9sQ%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpySV2ebB9j-p%3Dd%3DEQeO3mCbHPvgwYC%2BUptjjgatahUWkDA%40mail.gmail.com.
