On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On Apr 12, 10:27 pm, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: >> > So perhaps we do need the signal inheritance behavior to be opt-in when >> > connecting the signal handler. I think I'd like to see a deprecation >> > path so that eventually the inheritance behavior is the default, and you >> > have to opt out of it, as I think in most cases it's the desired behavior. >> >> Unfortunately this seems to be the only backwards compatible way >> forward. I don't know how to do the technical details... from >> __future__ import pre_save? :) > > Could we force the caller to define the wanted signal inheritance mode > when .connect() is called? The inherit mode must be one of True,False > or None. Default of None means no inheritance (as now) but it will be > deprecated.
I took a swing at a similar implementation here: https://github.com/votizen/django/tree/fe0f92b0f50bcd47742638ff3b8ff94af83ff9c5 (Tracking branch: https://github.com/votizen/django/tree/virtual_signals ) I haven't tried to address performance yet, but I've read all of https://code.djangoproject.com/ticket/16679 and think it's possible to keep sane overhead. > Another problem is that delete fires the same signal multiple times in > the inheritance chain. We can't remove the parent signal for backwards > compatibility reasons, nor can we fire them as then inheriting > listeners will see the delete signals multiple times. I think I solved this my the simple expedient of seen_receivers here: https://github.com/votizen/django/blob/270666cc701dff1eb1a8e5e649634aee5980b737/django/dispatch/dispatcher.py#L249 Basically we can group up the receivers so that they are fired at most once. ... > Another option is to continue as currently: model signals aren't > handled coherently, and there is no signal inheritance. Django users > have managed to survive thus far with the current signals > implementation, so maybe it doesn't need fixing? I'm less of a fan of signals than I used to be, but I think this line of reasoning is wrong - mostly people don't notice when their signal handlers are doing the wrong thing. The lack of visibility makes it difficult. I have definitely seen bugs caused by this misbehavior. (I'm not in favor of removing signals entirely, for what it's worth - I still don't see a better way in some cases - but I do think more visibility would be useful.) > Any opinions on the above transition phase idea? Other ideas? Is the > "define signal inheritance on connect" the wanted behavior in 1.7 or > should it be something else? I think this is the right approach - but I'm not sure why you said "1.7" here. You mean 1.5 or done with the deprecation path by 1.7? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
