#24816 closed Cleanup/optimization (fixed)
Clarify docs about preventing duplicate signals
Reported by: | Timothy Makobu | Owned by: | Jason Held |
---|---|---|---|
Component: | Documentation | Version: | 3.1 |
Severity: | Normal | Keywords: | signals |
Cc: | django@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hello,
In the docs here https://docs.djangoproject.com/en/1.8/topics/signals/#preventing-duplicate-signals It implies that a receiver can be called multiple times for the same event. When would this happen? Is it still a problem in 1.8?
Change History (10)
comment:1 by , 9 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 9 years ago
Component: | Core (Other) → Documentation |
---|
The reason timkofu
has raised this ticket was because coming into IRC to find out what the circumstances were didn't yield definitive results, and while the phrasing of the original ticket may have left you thinking it was a question for django-users, it's not, really. Given I was the one suggesting opening a ticket to get the docs improved, I'm going to chime in.
I have no idea what In some circumstances, the code connecting receivers to signals may run multiple times might mean, these days, given much of the problem stemmed (IIRC) from the old project layout allowing for multiple import paths, and the lack of something like AppConfig.ready.
If it is still a problem, as has been alluded to, the nature of how multiple runs might be encountered ought to be documented rather than just hand-waving it away as "in some circumstances" and leaving the user wondering why they need dispatch_uid
. There used to be a whole Wiki page devoted to the issue; I'd hope if it's still an issue, some of the explanation therein could be subsumed into the actual docs.
(Or just drop the whole bit entirely and document signals as taking a dispatch_uid everywhere, given that is essentially the solution (and has been for as long as I can remember))
I'm reclassifying this as documentation improvement, in the hope that it could be re-opened on that basis.
comment:3 by , 9 years ago
Cc: | added |
---|
comment:4 by , 9 years ago
Resolution: | invalid |
---|---|
Status: | closed → new |
Summary: | Preventing duplicate signals → Clarify docs about preventing duplicate signals |
Triage Stage: | Unreviewed → Accepted |
comment:5 by , 4 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:7 by , 4 years ago
Patch needs improvement: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Version: | 1.8 → 3.1 |
The ticket tracker is for tracking known problems, not asking questions. If you want to ask a question about usage, please use the Django-users mailing list.
However; to answer your question: Yes, it is still a problem, and no, there isn't much we can do about it (other than what is already listed in in the docs). The problem is that due to Python's import process, it's possible for the same module to be imported twice, resulting in a handler being registered twice.