←back to thread

Django 6.0 beta 1 released

(www.djangoproject.com)
106 points webology | 5 comments | 22 Oct 25 19:46 UTC | HN request time: 0.834s | source
Show context
tkcranny ◴[22 Oct 25 20:23 UTC] No.45674677[source]▶
Looks like Django 6 is getting an offical task system.

There’s no real world brokers or workers supported (at least built in), but still centralising around a standard interface might make things nicer than the celery tentacle monsters Django apps eventually tend to mutate into.

replies(3): >>45674764 #>>45675195 #>>45675539 #
1. ponytech ◴[22 Oct 25 21:12 UTC] No.45675195[source]▶
I don´t understand how you could use this new tasks system in production if there is no real workers when it's released? Are there any 3rd party yet?
replies(2): >>45675254 #>>45675332 #
2. HiPhish ◴[22 Oct 25 21:17 UTC] No.45675254[source]▶
I guess the idea is first to provide a generic interface to connect various backends to and let the community develop those. Users of Django should then be able to swap one out for another. Maybe one will emerge as a quasi-standard or maybe it will be like database backends where different backends serve different purposes.

At leas that's my guess.

3. ranger_danger ◴[22 Oct 25 21:23 UTC] No.45675332[source]▶
My understanding is that if you just need to return a response to the client as quickly as possible, but are ok with then processing your task directly after that, then it's still usable today.

But if you want to schedule a task further in the future, then a new backend will be needed for that.

replies(1): >>45675407 #
4. dabeeeenster ◴[22 Oct 25 21:29 UTC] No.45675407[source]▶
I think the bigger use case is being able to (backoff) retry failing API calls to 3rd party services. AFAIUI the new tasks package doesnt offer this in v1 which is a deal breaker for my project, at least.
replies(1): >>45675531 #
5. majorchord ◴[22 Oct 25 21:42 UTC] No.45675531{3}[source]▶
For me I think it works well as is because my use case is sending several different emails after POST'ing to a view, which, there is no need to make the user wait for in my case, as they don't care about the status of the mail delivery.

But I realize there are many other usecases too that will need proper workers.