Re: [Django] #13080: Documentation bug for Signal.connect
Django
---------------------------------+------------------------------------
Reporter: george.sakkis@… | Owner: nobody
Type: Bug | Status: new
Component: Documentation | Version: 1.2-beta
Severity: Normal | Resolution:
Keywords: signals | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
Changes (by mitar):
* cc: mmitar@… (added)
* ui_ux: => 0
* easy: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/13080#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
---------------------------------+------------------------------------
Reporter: george.sakkis@… | Owner: nobody
Type: Bug | Status: new
Component: Documentation | Version: 1.2-beta
Severity: Normal | Resolution:
Keywords: signals | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
Comment (by jdunck):
Replying to [comment:3 mrmachine]:
> 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 `dispatch_uid` 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.
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.
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/13080#comment:7>
Django
---------------------------------+------------------------------------
Reporter: george.sakkis@… | Owner: nobody
Type: Bug | Status: new
Component: Documentation | Version: 1.2-beta
Severity: Normal | Resolution:
Keywords: signals | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
* cc: berker.peksag@… (added)
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/6671
--
Ticket URL: <https://code.djangoproject.com/ticket/13080#comment:8>
Django
Reporter: george.sakkis@… | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: signals | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* version: 1.2-beta => master
* type: Bug => Cleanup/optimization
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/13080#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: george.sakkis@… | Owner: nobody
Cleanup/optimization |
Component: Documentation | Version: master
Keywords: signals | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"995d09ead492a1c3d71d781c7846f622b3f71186" 995d09e]:
{{{
#!CommitTicketReference repository=""
revision="995d09ead492a1c3d71d781c7846f622b3f71186"
Fixed #13080 -- Corrected accepted values of sender parameter in
Signal.connect() docstring.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13080#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: george.sakkis@… | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Documentation | Version: master
Severity: Normal | Resolution: fixed
Keywords: signals | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"ab92351bc6b58316250c1748cc6dbf55cdba03d2" ab92351b]:
{{{
#!CommitTicketReference repository=""
revision="ab92351bc6b58316250c1748cc6dbf55cdba03d2"
[1.10.x] Fixed #13080 -- Corrected accepted values of sender parameter in
Signal.connect() docstring.
Backport of 995d09ead492a1c3d71d781c7846f622b3f71186 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13080#comment:11>