Skip to main content

Django Unified Signals

Continuous Integration codecov

This package extends behavior of the Django Signals, by unifying the data passed when the signal is sent. That way both: the sender and the receiver can be sure that the data passed is always of the same type.

Django Signals are not very strict on the data that can be passed with send method. Basically anything can be passed as the arguments and receivers need to be aware of that from the project documentation. It gets even worse when on one side the signal send params change and the receivers' maintainers may not be aware of that. It gets even worse, when using send_robust method, which ignores all exceptions and any errors may pass without being noticed.

Using this package you have to define the message type class which object
is always expected to be passed when sending the signal. That way receiver knows what type of message will be received. This package automates the process of checking if the send message is following the contract.

Installation

The package is available on PyPI:

pip install django-unified-signals

Usage

Let's start by defining the message structure. It can be any class you want. In the example we will use dataclass:

import dataclasses

@dataclasses.dataclass
class UserMessage:
    name: str
    age: int

Now that we have the message structure defined, we can create the signal:

from unified_signals import UnifiedSignal

user_deactivated_signal = UnifiedSignal(UserMessage)

It extends the standard django.dispatch.Signal class, so it can be used in the same way.

user_deactivated_signal.send(sender, UserMessage(name='John', age=30))

The receiver can be defined in the same way as for the standard Django Signal:

@receiver(user_deactivated_signal)
def handle_user_deactivated(sender, message: UserMessage, **kwargs):
    print(message.name)
    print(message.age)
    ...

The difference is that the message is always of the same type, so the receiver can be sure that the message is always of the same type. If the message is not of the expected type when sending the signal, the unified_signals.exceptions.UnifiedSignalMessageTypeError exception will be raised.

user_deactivated_signal.send(sender, 'not a message') # raises UnifiedSignalMessageTypeError

Contributing

Commits must follow Conventional Commits (feat:, fix:, chore:, etc.) — enforced locally via pre-commit install (installs both the pre-commit and commit-msg hooks). They drive automated version bumps and changelog generation via python-semantic-release.

Releasing

Run the Release workflow manually from the Actions tab (targets master) whenever the changes on master are ready to ship. It computes the next version from commit history, bumps pyproject.toml, updates CHANGELOG.md, tags the commit, and publishes a GitHub Release. Publishing to PyPI is still done manually.

Release files for django-unified-signals 0.4.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for django-unified-signals 0.4.1
File Size Uploaded
django_unified_signals-0.4.1.tar.gz 5.5 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for django-unified-signals 0.4.1
File Interpreter ABI Platform
django_unified_signals-0.4.1-py3-none-any.whl Python 3 none any Details

Total release size: 10.2 kB

Release files / django_unified_signals-0.4.1.tar.gz

Download URL django_unified_signals-0.4.1.tar.gz
Size 5.5 kB
Tags Source
SHA-256 checksum
How to use checksums
1870f635e21b22bcf42460fdd7f74df504d1317e79533dbf9277dcd3d5dc30e4
BLAKE2b-256 checksum
How to use checksums
488e39b980fac21d6ef57305d6733b9caf1014f6f090d12942f99aefba0600b7
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 19, 2026.

Transparency log

Release files / django_unified_signals-0.4.1-py3-none-any.whl

Download URL django_unified_signals-0.4.1-py3-none-any.whl
Size 4.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
b89322062581cade2cfa24460a40e7e8679e45c054f3b3dff00474d763f2fe52
BLAKE2b-256 checksum
How to use checksums
fb6ba15b4c7a43e381cab7355f120e658540e4f6add93751121470434512c705
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 19, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.4.1 This release

2 release files

0.4.0

2 release files

0.2.1

2 release files

0.2.0

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page