On Apr 12, 9:58 pm, Carl Meyer <[email protected]> wrote: > So this is an argument against firing the init signals multiple times, > for each superclass, but it's not an argument against changing the > signal framework to include superclass receivers, as proposed in #9318; > that would not change the performance characteristics for the > no-receivers situation. > > (I see that this choice also has implications for the performance > improvement patch in #16679, but it looks like we have a workable option > there either way).
Maybe the solution here is to handle __init__ signals specially - no inheritance there, and you could then add the signals directly to model._meta.pre/post_init_signals. Speed would improve, and as far as I understand these signals are not needed for anything else than fields doing special setup for related variables (ImageField setting width and height for example). Of course, if the receivers caching from #16679 would get in then the init signals wouldn't be a speed problem. But I would hope that #16679 would not be needed at all if init signals were handled specially, as other signals do not have any meaningful overhead (warning: haven't benchmarked). #16679 is making a complex piece of code even more complex. > Yes, this is similar to the audit-trail handler I mentioned, and I agree > that it is a significant backwards-compatibility problem for either option. > > 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? :) - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
