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.)