Unless Django is doing something nasty like introspecting the names of the parameters, I don't see why it matters that this is a Django signal handler. I didn't see anything in the docs you linked that enforced a particular set of parameters, and modifying the code locally and running the tests works fine. This is just about how Python handles parameters and kwargs.

The reason why I care about this is because it makes one kind of problem (bad parameters being passed) throw a different kind of exception (a key error), and it is moving information that I would expect to see in the parameter list into the function body.

```python
Python 2.7.5 (default, May 12 2013, 12:00:47) 
[GCC 4.8.0 20130502 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(a, **kwargs):
...     c = kwargs['c']
...     print 'a=%d, c=%d' % (a, c)
... 
>>> def bar(a, c, **kwargs):
...     print 'a=%d, c=%d' % (a, c)
... 
>>> foo(1, c=2)
a=1, c=2
>>> bar(1, c=2)
a=1, c=2
>>> foo(1, b=10, c=2)
a=1, c=2
>>> bar(1, b=10, c=2)
a=1, c=2
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
KeyError: 'c'
>>> bar(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: bar() takes exactly 2 arguments (1 given)
```

Again, the things I said above could be invalidated by Django being nasty and really really caring about the parameters in the defined function but since the tests still pass for me with the modification I suggested above, I don't think that is the case. This isn't a huge issue for this function, but I feel it is a style thing that we should be consistent about.