Opened 3 years ago

Closed 16 months ago

#16386 closed New feature (wontfix)

Handle subclasses in signal dispatcher

Reported by: patrys Owned by: nobody
Component: Core (Other) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Currently the signal dispatcher stores just the identity of the passed object instead. Because of that the _live_receivers method can only perform equality tests. The result is that the moment you use Python inheritance for models, the signals stop working.

You can work around that by setting sender to None 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).

Therefore I propose modifying the _make_id function a bit so when passed a type (class) or a list/tuple of types it returns it verbatim without identity casting. Then _live_receivers could test for issubclass dealing with classes.

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.

Attachments (0)

Change History (2)

comment:1 Changed 3 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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.

comment:2 Changed 16 months ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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.

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.