On 08/15/2011 01:17 PM, Dan Fairs wrote:
Deprecate pre_init and post_init signals. I wonder if these are
actually used in third-party code. These signals are not the easiest
to use, as they get the field values in *args, or in **kwargs, or part
in *args, part in **kwargs. Django core uses them in generic foreign
keys:
To leap in here - we use post_init in our application, so there's at least
*one* consumer out there! We use them to populate attributes on a model which
depend on other system state, including data in that model itself. In our case,
we actually only care about the instance passed in kwargs.
Really stupid question, but why not just override __init__? Third party
code, where you can't modify the __init__?
But, maybe these signals do not need to be deprecated to get the speed
gain. We could check if pre_init or post_init is used at all in the
Django instance. This would be done by using global variables
has_pre_init_listeners and has_post_init_listeners in
django/db/models/base.py. These variables are set when first listener is
registered to pre_init and post_init signals. If there is one (for any
model), then do the normal signal sending. So, instead of doing:
singnals.pre_init.send(sender=...)
do
if has_pre_init_listeners:
signals.pre_init.send(sender=...)
That way, if there is no listeners at all defined, the overhead should
be non-measurable. Hopefully this is the common case.
Currently, the signal.send() calls add about 0.02 seconds to 10000
objects (on my old laptop). If there is any listener on pre_init or
post_init, the overhead of that is 0.05 seconds, no matter if the
listener is interested in the current model or not. That is, a listener
for T1 will add 0.05 seconds to initializations of T2. There is a
further small penalty for signals actually interested in the current
model. It is something like 0.03 seconds if I remember correctly.
- 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.
