Bird
Raised Fist0
Djangoframework~10 mins

Custom signals in Django - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to import the Django signal dispatcher.

Django
from django.dispatch import [1]
Drag options to blanks, or click blank then click option'
ASignal
Breceiver
Csend
Dconnect
Attempts:
3 left
💡 Hint
Common Mistakes
Importing 'receiver' instead of 'Signal'.
Trying to import 'send' which is a method, not a class.
2fill in blank
medium

Complete the code to define a new custom signal named order_completed.

Django
order_completed = [1]()
Drag options to blanks, or click blank then click option'
ASignal
Breceiver
Csend
Dconnect
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'receiver' which is a decorator, not a signal.
Trying to call 'send' which is a method to send signals.
3fill in blank
hard

Fix the error in the receiver function decorator to connect it to the order_completed signal.

Django
@[1](order_completed)
def notify_user(sender, **kwargs):
    print('Order completed!')
Drag options to blanks, or click blank then click option'
ASignal
Breceiver
Csend
Dconnect
Attempts:
3 left
💡 Hint
Common Mistakes
Using '@Signal' which is a class, not a decorator.
Using '@send' which is a method, not a decorator.
4fill in blank
hard

Fill both blanks to send the order_completed signal with the sender as the Order class.

Django
order_completed.[1](sender=[2])
Drag options to blanks, or click blank then click option'
Asend
BOrder
Cconnect
Dreceiver
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'connect' instead of 'send' to trigger the signal.
Passing an instance instead of the class as sender.
5fill in blank
hard

Fill all three blanks to define a receiver function that listens to order_completed and prints the order ID from kwargs.

Django
@[1](order_completed)
def handle_order(sender, **[2]):
    print(f"Order ID: [3]['order_id']")
Drag options to blanks, or click blank then click option'
Areceiver
Bkwargs
Dargs
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'args' instead of 'kwargs' to get keyword arguments.
Forgetting the '@receiver' decorator.

Practice

(1/5)
1. What is the main purpose of custom signals in Django?
easy
A. To create new database tables dynamically
B. To speed up database queries automatically
C. To replace Django's URL routing system
D. To allow different parts of an app to communicate without being tightly connected

Solution

  1. Step 1: Understand what custom signals do

    Custom signals let different parts of a Django app send messages to each other without direct links.
  2. Step 2: Compare options to this purpose

    Only To allow different parts of an app to communicate without being tightly connected describes this communication purpose; others describe unrelated features.
  3. Final Answer:

    To allow different parts of an app to communicate without being tightly connected -> Option D
  4. Quick Check:

    Custom signals = loose communication [OK]
Hint: Custom signals help parts talk without tight links [OK]
Common Mistakes:
  • Thinking signals speed up queries
  • Confusing signals with URL routing
  • Believing signals create database tables
2. Which of the following is the correct way to define a custom signal in Django?
easy
A. my_signal = signal(["instance", "created"])
B. my_signal = Signal(providing_args=["instance", "created"])
C. my_signal = Signal(args=["instance", "created"])
D. my_signal = Signal(provides=["instance", "created"])

Solution

  1. Step 1: Recall Django's Signal class syntax

    The correct way is to create a Signal object with providing_args as a list of argument names.
  2. Step 2: Check each option's syntax

    Only my_signal = Signal(providing_args=["instance", "created"]) uses Signal with providing_args correctly; others use wrong parameter names or lowercase Signal.
  3. Final Answer:

    my_signal = Signal(providing_args=["instance", "created"]) -> Option B
  4. Quick Check:

    Signal(providing_args=...) is correct syntax [OK]
Hint: Use Signal(providing_args=[...]) to define custom signals [OK]
Common Mistakes:
  • Using lowercase 'signal' instead of 'Signal'
  • Using 'args' or 'provides' instead of 'providing_args'
  • Passing arguments without a list
3. Given this code snippet, what will be printed when my_signal.send(sender=None, instance='obj1', created=True) is called?
from django.dispatch import Signal, receiver

my_signal = Signal(providing_args=["instance", "created"])

@receiver(my_signal)
def my_receiver(sender, **kwargs):
    print(f"Received: {kwargs['instance']}, Created: {kwargs['created']}")
medium
A. Received: obj1, Created: True
B. Received: None, Created: True
C. Received: obj1, Created: False
D. Error: missing sender argument

Solution

  1. Step 1: Understand signal sending and receiver

    The signal is sent with instance='obj1' and created=True. The receiver prints these values from kwargs.
  2. Step 2: Match printed output to sent values

    The print statement uses kwargs['instance'] and kwargs['created'], so it prints 'obj1' and 'True'.
  3. Final Answer:

    Received: obj1, Created: True -> Option A
  4. Quick Check:

    Signal send values print correctly [OK]
Hint: Receiver prints kwargs values sent by signal [OK]
Common Mistakes:
  • Confusing sender with instance
  • Assuming created is False by default
  • Thinking sender is required in print
4. What is wrong with this code that tries to connect a receiver to a custom signal?
from django.dispatch import Signal

my_signal = Signal(providing_args=["data"])

def receiver_func(sender, data):
    print(f"Data: {data}")

my_signal.connect(receiver_func)
medium
A. The receiver function must accept **kwargs, not just named arguments
B. Signal must be imported from django.signals, not django.dispatch
C. The connect method requires a sender argument
D. providing_args should be a tuple, not a list

Solution

  1. Step 1: Check receiver function signature

    Receivers must accept sender and **kwargs to handle all signal arguments flexibly.
  2. Step 2: Identify mismatch in receiver parameters

    The receiver only accepts sender and data, missing **kwargs, which causes errors when extra arguments are sent.
  3. Final Answer:

    The receiver function must accept **kwargs, not just named arguments -> Option A
  4. Quick Check:

    Receiver needs **kwargs for signal args [OK]
Hint: Receiver functions always need **kwargs parameter [OK]
Common Mistakes:
  • Forgetting **kwargs in receiver signature
  • Importing Signal from wrong module
  • Assuming connect requires sender argument
  • Confusing list and tuple for providing_args
5. You want to create a custom signal that notifies when a user profile is updated, sending the user instance and a flag if the update was major. Which of these is the best way to define and send this signal?
hard
A. Define signal with no providing_args and send with user=user_obj, major_update=True
B. Define signal with providing_args=['user'] and send with user=user_obj, major_update=True
C. Define signal with providing_args=['user', 'major_update'] and send with user=user_obj, major_update=True
D. Define signal with providing_args=['user', 'major_update'] but send only user=user_obj

Solution

  1. Step 1: Define signal with all expected arguments

    Since you want to send both user and major_update, both must be listed in providing_args.
  2. Step 2: Send signal with matching arguments

    When sending, include both user and major_update to match the signal definition and receiver expectations.
  3. Final Answer:

    Define signal with providing_args=['user', 'major_update'] and send with user=user_obj, major_update=True -> Option C
  4. Quick Check:

    Signal args must match send args [OK]
Hint: Match providing_args and send arguments exactly [OK]
Common Mistakes:
  • Omitting arguments in providing_args
  • Sending arguments not declared in providing_args
  • Defining signal without providing_args but sending args