Opened 15 years ago

Closed 8 years ago

Last modified 8 years ago

#13080 closed Cleanup/optimization (fixed)

Documentation bug for Signal.connect

Reported by: george.sakkis@… Owned by: nobody
Component: Documentation Version: dev
Severity: Normal Keywords: signals
Cc: real.human@…, mmitar@…, berker.peksag@… 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

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.

Change History (11)

comment:1 by Russell Keith-Magee, 15 years ago

Triage Stage: UnreviewedAccepted

To clarify: This is a comment about the docstring on Signal.connect, line 59 of django/dispatch/dispatcher.py

(Note for future reference -- if you're going to make a bug report, it helps to point out *where* the bug is)

comment:2 by Russell Keith-Magee, 15 years ago

See #13132 for a related issue that requires clarification when the documentation surrounding sender is updated.

comment:3 by Tai Lee, 14 years ago

Cc: real.human@… added

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.

comment:4 by Luke Plant, 14 years ago

Type: Bug

comment:5 by Luke Plant, 14 years ago

Severity: Normal

comment:6 by Mitar, 13 years ago

Cc: mmitar@… added
Easy pickings: unset
UI/UX: unset

in reply to:  3 comment:7 by Jeremy Dunck, 12 years ago

Replying to 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.

comment:8 by Berker Peksag, 8 years ago

Cc: berker.peksag@… added
Has patch: set

comment:9 by Simon Charette, 8 years ago

Triage Stage: AcceptedReady for checkin
Type: BugCleanup/optimization
Version: 1.2-betamaster

comment:10 by Tim Graham <timograham@…>, 8 years ago

Resolution: fixed
Status: newclosed

In 995d09e:

Fixed #13080 -- Corrected accepted values of sender parameter in Signal.connect() docstring.

comment:11 by Tim Graham <timograham@…>, 8 years ago

In ab92351b:

[1.10.x] Fixed #13080 -- Corrected accepted values of sender parameter in Signal.connect() docstring.

Backport of 995d09ead492a1c3d71d781c7846f622b3f71186 from master

Note: See TracTickets for help on using tickets.
Back to Top