Django: Ticket #13080: Documentation bug for Signal.connecthttps://code.djangoproject.com/ticket/13080
<p>
Signal.connect says about the optional sender keyword "Must either be of type Signal, or None to receive events from any sender", but actually sender can be any any python object.
</p>
en-usDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gifhttps://code.djangoproject.com/ticket/13080
Trac 1.2Russell Keith-MageeThu, 11 Mar 2010 01:30:55 GMTstage changedhttps://code.djangoproject.com/ticket/13080#comment:1
https://code.djangoproject.com/ticket/13080#comment:1
<ul>
<li><strong>stage</strong>
changed from <em>Unreviewed</em> to <em>Accepted</em>
</li>
</ul>
<p>
To clarify: This is a comment about the docstring on Signal.connect, line 59 of django/dispatch/dispatcher.py
</p>
<p>
(Note for future reference -- if you're going to make a bug report, it helps to point out *where* the bug is)
</p>
TicketRussell Keith-MageeThu, 18 Mar 2010 12:00:03 GMThttps://code.djangoproject.com/ticket/13080#comment:2
https://code.djangoproject.com/ticket/13080#comment:2
<p>
See <a class="closed ticket" href="https://code.djangoproject.com/ticket/13132" title="#13132: [signals] Storing id()s instead of actual instances considered harmful (closed: wontfix)">#13132</a> for a related issue that requires clarification when the documentation surrounding sender is updated.
</p>
TicketTai LeeWed, 02 Mar 2011 00:55:23 GMTcc sethttps://code.djangoproject.com/ticket/13080#comment:3
https://code.djangoproject.com/ticket/13080#comment:3
<ul>
<li><strong>cc</strong>
<em>real.human@…</em> added
</li>
</ul>
<p>
Actually, it can't be any python object. It seems to only work somewhat reliably with classes, and even then you might experience double registration which is why we have the <code>dispatch_uid</code> argument. This seems buggy to me. It doesn't seem like a very good system if we have to provide a second argument to make it work if you happen to experience double registration problems. It should work as specified, or not, and preferably with "any python object" as the docstrings indicate. This would make it possible to connect receiver functions to signals sent by specific model instances, or senders that have nothing to do with models at all using a string literal sender.
</p>
TicketLuke PlantMon, 04 Apr 2011 16:27:28 GMTtype sethttps://code.djangoproject.com/ticket/13080#comment:4
https://code.djangoproject.com/ticket/13080#comment:4
<ul>
<li><strong>type</strong>
set to <em>Bug</em>
</li>
</ul>
TicketLuke PlantMon, 04 Apr 2011 17:33:22 GMTseverity sethttps://code.djangoproject.com/ticket/13080#comment:5
https://code.djangoproject.com/ticket/13080#comment:5
<ul>
<li><strong>severity</strong>
set to <em>Normal</em>
</li>
</ul>
TicketMitarSat, 03 Dec 2011 15:51:13 GMTcc changed; ui_ux, easy sethttps://code.djangoproject.com/ticket/13080#comment:6
https://code.djangoproject.com/ticket/13080#comment:6
<ul>
<li><strong>cc</strong>
<em>mmitar@…</em> added
</li>
<li><strong>ui_ux</strong>
unset
</li>
<li><strong>easy</strong>
unset
</li>
</ul>
TicketJeremy DunckMon, 04 Jun 2012 19:19:15 GMThttps://code.djangoproject.com/ticket/13080#comment:7
https://code.djangoproject.com/ticket/13080#comment:7
<p>
Replying to <a class="ticket" href="https://code.djangoproject.com/ticket/13080#comment:3" title="Comment 3">mrmachine</a>:
</p>
<blockquote class="citation">
<p>
Actually, it can't be any python object. It seems to only work somewhat reliably with classes, and even then you might experience double registration which is why we have the <code>dispatch_uid</code> argument. This seems buggy to me. It doesn't seem like a very good system if we have to provide a second argument to make it work if you happen to experience double registration problems. It should work as specified, or not, and preferably with "any python object" as the docstrings indicate. This would make it possible to connect receiver functions to signals sent by specific model instances, or senders that have nothing to do with models at all using a string literal sender.
</p>
</blockquote>
<p>
It would be better, but it isn't practical. "It doesn't seem like a very good system if we have to provide a second argument to make it work if you happen to experience double registration problems" - the issue is that the identity of an object in python is basically its memory address. dispatch_uid is to provide a canonical, well-known name for the given receiver. If dispatch_uid is not given, then if receiver happens to be two different objects (as happens when the same module is imported with different pathing, or when the receiver is a dynamically-created function), then there isn't a practical way to know it's the same receiver.
</p>
<p>
Additionally, we settled on a const-string as the fallback because performance overhead in the signals system is critical. pre_init and post_init are fatally performance-sensitive design choices, and dominate any consideration of changes in signals. String comparison is the simplest way to perform the needed human-readable, performance-sensitive equality comparison.
</p>
TicketBerker PeksagMon, 30 May 2016 01:29:09 GMTcc, has_patch changedhttps://code.djangoproject.com/ticket/13080#comment:8
https://code.djangoproject.com/ticket/13080#comment:8
<ul>
<li><strong>cc</strong>
<em>berker.peksag@…</em> added
</li>
<li><strong>has_patch</strong>
set
</li>
</ul>
<p>
<a class="ext-link" href="https://github.com/django/django/pull/6671"><span class="icon">​</span>https://github.com/django/django/pull/6671</a>
</p>
TicketSimon CharetteMon, 30 May 2016 01:56:36 GMTversion, type, stage changedhttps://code.djangoproject.com/ticket/13080#comment:9
https://code.djangoproject.com/ticket/13080#comment:9
<ul>
<li><strong>version</strong>
changed from <em>1.2-beta</em> to <em>master</em>
</li>
<li><strong>type</strong>
changed from <em>Bug</em> to <em>Cleanup/optimization</em>
</li>
<li><strong>stage</strong>
changed from <em>Accepted</em> to <em>Ready for checkin</em>
</li>
</ul>
TicketTim Graham <timograham@…>Mon, 30 May 2016 12:15:26 GMTstatus changed; resolution sethttps://code.djangoproject.com/ticket/13080#comment:10
https://code.djangoproject.com/ticket/13080#comment:10
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
In <a class="changeset" href="https://code.djangoproject.com/changeset/995d09ead492a1c3d71d781c7846f622b3f71186" title="Fixed #13080 -- Corrected accepted values of sender parameter in ...">995d09e</a>:
</p>
<div class="message"><p>
Fixed <a class="closed ticket" href="https://code.djangoproject.com/ticket/13080" title="#13080: Cleanup/optimization: Documentation bug for Signal.connect (closed: fixed)">#13080</a> -- Corrected accepted values of sender parameter in Signal.connect() docstring.<br />
</p>
</div>
TicketTim Graham <timograham@…>Mon, 30 May 2016 12:15:37 GMThttps://code.djangoproject.com/ticket/13080#comment:11
https://code.djangoproject.com/ticket/13080#comment:11
<p>
In <a class="changeset" href="https://code.djangoproject.com/changeset/ab92351bc6b58316250c1748cc6dbf55cdba03d2" title="[1.10.x] Fixed #13080 -- Corrected accepted values of sender parameter ...">ab92351b</a>:
</p>
<div class="message"><p>
[1.10.x] Fixed <a class="closed ticket" href="https://code.djangoproject.com/ticket/13080" title="#13080: Cleanup/optimization: Documentation bug for Signal.connect (closed: fixed)">#13080</a> -- Corrected accepted values of sender parameter in Signal.connect() docstring.<br />
</p>
<p>
Backport of <a class="changeset" href="https://code.djangoproject.com/changeset/995d09ead492a1c3d71d781c7846f622b3f71186/" title="Fixed #13080 -- Corrected accepted values of sender parameter in ...">995d09ead492a1c3d71d781c7846f622b3f71186</a> from master<br />
</p>
</div>
Ticket