Django: Ticket #16386: Handle subclasses in signal dispatcher <p> Currently the signal dispatcher stores just the identity of the passed object instead. Because of that the <tt>_live_receivers</tt> method can only perform equality tests. The result is that the moment you use Python inheritance for models, the signals stop working. </p> <p> You can work around that by setting sender to <tt>None</tt> but it adds a bit of an overhead due to the fact that your handler is called for each and every object and there are places where you can't change how signals are connected (like the generic relations). </p> <p> Therefore I propose modifying the <tt>_make_id</tt> function a bit so when passed a type (class) or a list/tuple of types it returns it verbatim without identity casting. Then <tt>_live_receivers</tt> could test for <tt>issubclass</tt> dealing with classes. </p> <p> While this would technically result in a different behavior from what Django 1.3 does, I doubt it would be a problem. I don't think there are many cases when you want a signal from a base class but not from subclasses and the few remaining uses can manually test for that in the handler. </p> en-us Django Trac 1.0 aaugustin Thu, 07 Jul 2011 07:52:58 GMT stage changed; needs_better_patch, needs_tests, needs_docs set <ul> <li><strong>needs_better_patch</strong> unset </li> <li><strong>stage</strong> changed from <em>Unreviewed</em> to <em>Design decision needed</em> </li> <li><strong>needs_tests</strong> unset </li> <li><strong>needs_docs</strong> unset </li> </ul> <p> I agree that in most cases, inherited classes should behave like their parent classes with regard to signals, but the backwards incompatibility can't be simply ignored. </p> Ticket jacob Mon, 01 Apr 2013 22:01:59 GMT status changed; resolution set <ul> <li><strong>status</strong> changed from <em>new</em> to <em>closed</em> </li> <li><strong>resolution</strong> set to <em>wontfix</em> </li> </ul> <p> I can't really think of a way forward that includes solid backwards compatibility, and this isn't a big enough improvement to warrant breakage or migration. So unfortunately I think we're stuck with it as is. </p> <p> If someone can think of a way forward that is backwards-compatible, then feel free to reopen (and say how!), but otherwise it's not gonna happen. </p> Ticket