From the docs:

> Notice that the function takes a sender argument, along with wildcard keyword arguments (**kwargs); all signal handlers must take these arguments.
> 
> We’ll look at senders a bit later, but right now look at the **kwargs argument. All signals send keyword arguments, and may change those keyword arguments at any time. In the case of request_finished, it’s documented as sending no arguments, which means we might be tempted to write our signal handling as my_callback(sender).
> 
> This would be wrong – in fact, Django will throw an error if you do so. That’s because at any point arguments could get added to the signal and your receiver must be able to handle those new arguments.


We could do it your way--that's valid Python, but I think receivers is a special case. This is how I did it with Django 1.3. I looked around for uses of signals and receivers to see if the world is different now, but didn't find much. In Kuma, there's a single signal/receiver and the receiver function signature is `def build_json_data_handler(sender, instance, **kwargs):`.

I checked 2 Scoops and Practical Django Projects and didn't see any evidence of what you're suggesting.

I'll change it if you can find precedent in Django style somewhere. Otherwise I think it's better to stick to what the docs say.