Django includes a “signal dispatcher” which helps allow decoupled applications
get notified when actions occur elsewhere in the framework. In a nutshell,
signals allow certain senders to notify a set of receivers that some action has
taken place. They’re especially useful when many pieces of code may be interested
in the same events.
Notice that the function takes a sender argument, along with wildcard keyword
arguments (**kwargs); all signal handlers must take these arguments.
We'll look at senders a bit later, but right now look at the **kwargs argument.
All signals send keyword arguments, and may change those keyword arguments at any
time. In the case of request_finished, it's documented as sending no arguments,
which means we might be tempted to write our signal handling as my_callback
This would be wrong -- in fact, Django will throw an error if you do so. That's
because at any point arguments could get added to the signal and your receiver
must be able to handle those new arguments.
def emit_post_sync_signal(created_models, verbosity, interactive, db):
# Emit the post_sync signal for every application.
for app in models.get_apps():
app_name = app.__name__.split('.')[-2]
if verbosity >= 2:
print("Running post-sync handlers for application %s" % app_name)