Is DEP009 ("async-capable Django") still relevant?

hi :waving_hand:t3:
just jumping in to share what i’ve experienced and what i can do to help (or have done)

i’ve had problems with CBV and GCBVs, specially since view auth mixins are sync only, tho i did make my own version for these.

i might also add MiddlewareMixin to this list, i know it’s async capable, but at the cost of at least one sync_to_async call for each middleware for each request
i did make a fully async version of this, and made async version of a few of django’s built-in mixins (csrf is a monster i haven’t tamed yet), as well as the decorator_from_middleware tool

tho currently i’m questioning how much this would actually effect performance, so most of it is not merged yet

django-valkey has had async clients for some time (tho with their own issues), which can be used as a testing opportunity for django’s core
god willing the next release of django-valkey will resolve the main issue with async caching and i can officially support it

but there are things that a 3rd-party can’t fixed, such as the test signal i mentioned in this discussion

also as sarah boyce mentioned before some internal form support like the one discussed in #36194 (add async support to ManyToManyField) – Django would ease 3rd-party support

for future work maybe i do async cache middleware and async session middleware next