Custom signals in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a custom signal is sent without any receivers?

Consider a Django custom signal defined and sent, but no receiver functions are connected to it. What is the behavior when the signal is sent?

Django

from django.dispatch import Signal

my_signal = Signal()

my_signal.send(sender=None)

A The signal send method returns an empty list, and no error occurs.

B A RuntimeError is raised because no receivers are connected.

C The signal send method returns None and logs a warning.

D The signal send method raises a TypeError due to missing sender argument.

💡 Hint

Think about what happens if no one is listening when you shout.

When a Django signal is sent but no receivers are connected, the send method returns an empty list indicating no receivers handled the signal. No error is raised.

📝 Syntax

intermediate

Which option correctly defines a custom Django signal with providing arguments?

You want to create a custom Django signal that sends two arguments: 'user' and 'action'. Which code snippet correctly defines this signal?

A my_signal = Signal(provides=['user', 'action'])

B my_signal = Signal(providing=['user', 'action'])

C my_signal = Signal(args=['user', 'action'])

D my_signal = Signal(providing_args=['user', 'action'])

💡 Hint

Check the exact keyword argument name for declaring arguments in Django signals.

The correct keyword argument to specify the arguments a signal provides is 'providing_args'. Other options are invalid and cause errors.

🔧 Debug

advanced

Why does this custom signal receiver not get called?

Given the code below, why does the receiver function never execute when the signal is sent?

Django

from django.dispatch import Signal, receiver

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

@receiver(my_signal)
def my_receiver(sender, **kwargs):
    print('Received:', kwargs.get('data'))

# Somewhere else in code
my_signal.send(sender=None, data='Hello')

A The signal must be sent with a sender class, not None.

B The receiver is not connected because the module defining it was never imported.

C The signal send call is missing the required sender argument.

D The receiver function signature is incorrect; it must accept 'data' explicitly.

💡 Hint

Think about how Django connects signals and when decorators run.

Django connects signal receivers when the module containing them is imported. If the module is not imported, the receiver is never registered and won't be called.

❓ state_output

advanced

What is the output of this custom signal with multiple receivers?

Given the code below, what will be printed when the signal is sent?

Django

from django.dispatch import Signal, receiver

my_signal = Signal(providing_args=['value'])

@receiver(my_signal)
def receiver_one(sender, **kwargs):
    print('One:', kwargs.get('value'))
    return 'one'

@receiver(my_signal)
def receiver_two(sender, **kwargs):
    print('Two:', kwargs.get('value'))
    return 'two'

results = my_signal.send(sender=None, value=42)
print(results)

A [(<function receiver_one at ...>, 'one'), (<function receiver_two at ...>, 'two')]

B [('receiver_one', 'one'), ('receiver_two', 'two')]

C [(receiver_one, 'one'), (receiver_two, 'two')]

D [(<function receiver_one>, 'one'), (<function receiver_two>, 'two')]

💡 Hint

Recall what the send method returns: a list of tuples with receiver references and their return values.

The send method returns a list of tuples. Each tuple contains the receiver function object (with memory address) and its return value. The printed output shows function references with memory addresses.

🧠 Conceptual

expert

Which statement about Django custom signals is TRUE?

Select the only true statement about Django custom signals.

A Custom signals must always specify a sender class; None is not allowed.

B Signal receivers can modify the sender argument before other receivers are called.

C The send method returns a list of tuples with each receiver and its return value.

D Django automatically connects custom signals to model save events.

💡 Hint

Think about what the send method returns after notifying receivers.

The send method returns a list of tuples, each containing a receiver function and its return value. Other options are false: sender can be None, receivers cannot modify sender for others, and Django does not auto-connect custom signals to model events.

Practice

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