James, All you're talking about is adding this to your test cases right?
# Work around Django #34063 until 4.2. request.body # ... continue C. On Fri, 30 Dec 2022 at 10:04, James Bennett <ubernost...@gmail.com> wrote: > On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson > <carlton.gib...@gmail.com> wrote: > > 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. > > It's also broken in 4.0 and 4.1. I just posted the first trace I got > back from my test matrix, which happened to be a Django 3.2 run. > > > 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. > > I strongly disagree with this -- Django has been claiming support for > async views/middlewares, and for testing them with AsyncClient, since > 3.1. Telling people that actually it was badly broken to the point of > almost unusability until 4.2 and thus not to use any of those versions > that claimed to have the support is... suboptimal. Especially given, > as I noted, the difficulty for Django novices of even figuring out > what the heck is going on when they try to test an async view and get > a weird exception. > > Or to put it another way: if I submitted patches against the 3.2, 4.0, > and 4.1 branches for docs/topics/testing/tools.txt that put a big > "WARNING! BROKEN! DO NOT USE!" on all mentions of AsyncClient, I doubt > those patches would be well-received. But that's basically what those > releases of Django *need* at this point. It's intolerably misleading > to end users of the framework to have docs for those versions claiming > that you can write async code and test it with the AsyncClient when... > well, you can't, really, unless you know the precise way that it's > broken and put explicit workarounds for the brokenness in all your > views and middlewares. > > > You're wanting to add async support to your third-party library: super; > just say it's 4.2+ and move on. > > And telling library authors not to even think about doing async > support until Django 4.2 comes out (approximately two and a half years > after Django itself claimed to officially support this stuff), and > that they have to cut off all older versions of Django when they do so > *despite those versions officially claiming to support async* just > seems like a recipe for those authors deciding not to trust or waste > their time on Django. > > So I *really* think this one needs an exception to the backports > policy. Async is too important, and Django's reputation is too > important, to leave 3.2, 4.0, and 4.1 as badly broken as they > currently are. > > -- > 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/CAL13Cg8ZjzR%3Dzd4PwY%2Bmg1pUMXzPDUx_0ZPetCam5xEM7xqS1w%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/CAJwKpyQzd%2BUBKWECbHwZvZ37zRRwYh4w9LAMsZFMzqLPvTM5cA%40mail.gmail.com.
