Django includes a “signal dispatcher” which helps allow decoupled applications\nget notified when actions occur elsewhere in the framework. In a nutshell,\nsignals allow certain senders to notify a set of receivers that some action\nhas taken place. They’re especially useful when many pieces of code may be\ninterested in the same events.
\nDjango provides a set of built-in signals that let user\ncode get notified by Django itself of certain actions. These include some useful\nnotifications:
\ndjango.db.models.signals.pre_save &\ndjango.db.models.signals.post_save
Sent before or after a model’s save() method\nis called.
django.db.models.signals.pre_delete &\ndjango.db.models.signals.post_delete
Sent before or after a model’s delete()\nmethod or queryset’s delete()\nmethod is called.
django.db.models.signals.m2m_changed
Sent when a ManyToManyField on a model is changed.
django.core.signals.request_started &\ndjango.core.signals.request_finished
Sent when Django starts or finishes an HTTP request.
\nSee the built-in signal documentation for a complete list,\nand a complete explanation of each signal.
\nYou can also define and send your own custom signals; see below.
\nTo receive a signal, register a receiver function using the\nSignal.connect() method. The receiver function is called when the signal\nis sent. All of the signal’s receiver functions are called one at a time, in\nthe order they were registered.
receiver – The callback function which will be connected to this\nsignal. See Receiver functions for more information.
sender – Specifies a particular sender to receive signals from. See\nConnecting to signals sent by specific senders for more information.
weak – Django stores signal handlers as weak references by\ndefault. Thus, if your receiver is a local function, it may be\ngarbage collected. To prevent this, pass weak=False when you call\nthe signal’s connect() method.
dispatch_uid – A unique identifier for a signal receiver in cases\nwhere duplicate signals may be sent. See\nPreventing duplicate signals for more information.
Let’s see how this works by registering a signal that\ngets called after each HTTP request is finished. We’ll be connecting to the\nrequest_finished signal.
First, we need to define a receiver function. A receiver can be any Python\nfunction or method:
\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nNotice that the function takes a sender argument, along with wildcard\nkeyword arguments (**kwargs); all signal handlers must take these arguments.
We’ll look at senders a bit later, but right now look at the **kwargs\nargument. All signals send keyword arguments, and may change those keyword\narguments at any time. In the case of\nrequest_finished, it’s documented as sending no\narguments, which means we might be tempted to write our signal handling as\nmy_callback(sender).
This would be wrong – in fact, Django will throw an error if you do so. That’s\nbecause at any point arguments could get added to the signal and your receiver\nmust be able to handle those new arguments.
\nThere are two ways you can connect a receiver to a signal. You can take the\nmanual connect route:
\nfrom django.core.signals import request_finished\n\nrequest_finished.connect(my_callback)\nAlternatively, you can use a receiver() decorator:
signal – A signal or a list of signals to connect a function to.
\nHere’s how you connect with the decorator:
\nfrom django.core.signals import request_finished\nfrom django.dispatch import receiver\n\n@receiver(request_finished)\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nNow, our my_callback function will be called each time a request finishes.
Some signals get sent many times, but you’ll only be interested in receiving a\ncertain subset of those signals. For example, consider the\ndjango.db.models.signals.pre_save signal sent before a model gets saved.\nMost of the time, you don’t need to know when any model gets saved – just\nwhen one specific model is saved.
In these cases, you can register to receive signals sent only by particular\nsenders. In the case of django.db.models.signals.pre_save, the sender\nwill be the model class being saved, so you can indicate that you only want\nsignals sent by some model:
from django.db.models.signals import pre_save\nfrom django.dispatch import receiver\nfrom myapp.models import MyModel\n\n\n@receiver(pre_save, sender=MyModel)\ndef my_handler(sender, **kwargs):\n ...\nThe my_handler function will only be called when an instance of MyModel\nis saved.
Different signals use different objects as their senders; you’ll need to consult\nthe built-in signal documentation for details of each\nparticular signal.
\nIn some circumstances, the code connecting receivers to signals may run\nmultiple times. This can cause your receiver function to be registered more\nthan once, and thus called as many times for a signal event. For example, the\nready() method may be executed more than once\nduring testing. More generally, this occurs everywhere your project imports the\nmodule where you define the signals, because signal registration runs as many\ntimes as it is imported.
If this behavior is problematic (such as when using signals to\nsend an email whenever a model is saved), pass a unique identifier as\nthe dispatch_uid argument to identify your receiver function. This\nidentifier will usually be a string, although any hashable object will\nsuffice. The end result is that your receiver function will only be\nbound to the signal once for each unique dispatch_uid value:
from django.core.signals import request_finished\n\nrequest_finished.connect(my_callback, dispatch_uid="my_unique_identifier")\nYour applications can take advantage of the signal infrastructure and provide\nits own signals.
\n\nAll signals are django.dispatch.Signal instances.
Por exemplo:
\nimport django.dispatch\n\npizza_done = django.dispatch.Signal()\nThis declares a pizza_done signal.
There are two ways to send signals in Django.
\nTo send a signal, call either Signal.send() (all built-in signals use\nthis) or Signal.send_robust(). You must provide the sender argument\n(which is a class most of the time) and may provide as many other keyword\narguments as you like.
For example, here’s how sending our pizza_done signal might look:
class PizzaStore:\n ...\n\n def send_pizza(self, toppings, size):\n pizza_done.send(sender=self.__class__, toppings=toppings, size=size)\n ...\nBoth send() and send_robust() return a list of tuple pairs\n[(receiver, response), ... ], representing the list of called receiver\nfunctions and their response values.
send() differs from send_robust() in how exceptions raised by receiver\nfunctions are handled. send() does not catch any exceptions raised by\nreceivers; it simply allows errors to propagate. Thus not all receivers may\nbe notified of a signal in the face of an error.
send_robust() catches all errors derived from Python’s Exception class,\nand ensures all receivers are notified of the signal. If an error occurs, the\nerror instance is returned in the tuple pair for the receiver that raised the error.
The tracebacks are present on the __traceback__ attribute of the errors\nreturned when calling send_robust().
To disconnect a receiver from a signal, call Signal.disconnect(). The\narguments are as described in Signal.connect(). The method returns\nTrue if a receiver was disconnected and False if not.
The receiver argument indicates the registered receiver to disconnect. It\nmay be None if dispatch_uid is used to identify the receiver.