Django includes a “signal dispatcher” which helps decoupled applications get\nnotified when actions occur elsewhere in the framework. In a nutshell, signals\nallow certain senders to notify a set of receivers that some action has\ntaken place. They’re especially useful when many pieces of code may be\ninterested in the same events.
\nFor example, a third-party app can register to be notified of settings\nchanges:
\nfrom django.apps import AppConfig\nfrom django.core.signals import setting_changed\n\n\ndef my_callback(sender, **kwargs):\n print("Setting changed!")\n\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n setting_changed.connect(my_callback)\nDjango’s built-in signals let user code get notified of\ncertain actions.
\nYou can also define and send your own custom signals. See\nDefining and sending signals below.
\n\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\nright now look at the **kwargs argument. All signals send keyword\narguments, and may change those keyword arguments 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.
kwargs – Wildcard keyword arguments to pass to a\nfunction.
Here’s how you connect with the decorator:
\nfrom django.core.signals import request_finished\nfrom django.dispatch import receiver\n\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.
예시:
\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. When sender\nis passed as a lazy reference to <app label>.<model>, this method always\nreturns None.
The receiver argument indicates the registered receiver to disconnect. It\nmay be None if dispatch_uid is used to identify the receiver.