Sure ā In fact, Iāve been arguing only this week that Django doesnāt in fact move slowly. The example being that thereās no way Iād go back to using 4.2 now, even though itās still a supported version: we canāt be moving that slowly. The glacial point is more that thereās always a group of early adopters who are keen (desperate, almost) for it go (even) faster. Weāve all felt that at times. Itās to that mood that the point is, itās coming, inevitably. Or such. (Like all metaphors, it only goes so far.)
Of these the one that stands out to me is caching. We want to be able to use a fully async flow. We have the request-reponse cycle. The ORM is core to Django, so that. And then folks are going to want to cache. Email? ā Background worker. Templates? CPU bound (but thereās some interest in streamingā¦) Etc. So ORM and caching.
Whoa, whoa, whoa! Donāt accuse me of being generous. Iām self-interested and grateful that the work is being done as well, as consistently, and for as long as it has.
I was brought up to believe that ādonationsā should be private. But Iāve heard that shamelessly promoting the fact that youāve given is the best way to get other people to give as well. Youāre not the only one to tell me that my posts pushed you over the tipping point. I am glad that the calculated shamelessness was worth it; I felt like I needed to wash my hands after writing it.
Django should be raising much more. Itās too valuable to be resource constrained.
Anyone know someone who got into Bitcoin in 2009-2010?
I do think there are some opportunities to parallelize any database requests that occur when rendering a complex template, but maybe the opportunities donāt outweigh the complexity required to implement that.
hi
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
ā In fact, Iāve been arguing only this week that Django doesnāt in fact move slowly. The example being that thereās no way Iād go back to using 4.2 now, even though itās still a supported version: we canāt be moving that slowly. The glacial point is more that thereās always a group of early adopters who are keen (desperate, almost) for it go (even) faster. Weāve all felt that at times. Itās to that mood that the point is, itās coming, inevitably. Or such. (Like all metaphors, it only goes so far.)