Made a PR with a small paragraph:
https://github.com/django/django/pull/11814
I tried to be as succinct as possible but perhaps more words would be
better.
On Sun, 22 Sep 2019 at 20:44, Christian González <
christian.gonza...@nerdocs.at> wrote:
> Am 22.09.19 um 20:53 schrieb Cesar Canassa:
> > >
Am 22.09.19 um 20:53 schrieb Cesar Canassa:
> > Dispatching a signal to a handler is an implicit function call.
>
> I think that's a good one to include as well, some people get the
> impression that the signals are an async Celery-like process.
definitely. That's completely new to me e.g. I thoug
> Dispatching a signal to a handler is an implicit function call.
I think that's a good one to include as well, some people get the
impression that the signals are an async Celery-like process.
Best regards,
Cesar
On Sun, Sep 22, 2019 at 9:19 AM Aymeric Augustin <
aymeric.augus...@polytechnique
Hello,
Yes, I think the docs should be a better job at preventing people from getting
signal-happy without grasping all the consequences. I've faced that issue in a
big (> 1 million LoC) project as well.
Without getting too emotional, I think the docs could say that:
1. Signals are for executi
Hi Cesar,
I think the community consensus is exactly where you're at: signals are
only useful in limited cases. We've even resisted adding more signals to
Django core in recent years.
Although the Django documentation tends to be quite neutral I think a
single paragraph listing the pros and cons
Hello,
I would like to propose a small change to the Django signals documentation:
https://docs.djangoproject.com/en/2.2/topics/signals/
According to the documentation:
> Django includes a “signal dispatcher” which helps allow decoupled
applications get notified when actions occur elsewhere in
