[Fixed]-TypeError: __init__() got an unexpected keyword argument 'providing_args'

by

18👍

✅

Based on the comments, you’re running Django 4.0 with an old version of AllAuth. So you just need to update AllAuth and should be fine.

However, other people who have upgraded AllAuth and are running Django 4.0 but still seeing this error may have custom AllAuth or other signals registered that include the providing_args argument.

In this case, you need to search your project for any signals (such as those often overridden in AllAuth: user_logged_in or email_changed) and remove the providing_args=['request', 'user', 'signup'] or other variation from the Signal parenthesis.

See below for more information, and an example diff showing how you could move each providing_args argument to a commented line.

Django deprecated the ability to use the providing_args argument to django.dispatch.Signal in Django 3.1. See bullet in the Misc section of the 3.1 release notes.

It was removed because this argument doesn’t do anything other than act as documentation. If that seems strange, it is because it is strange. Arguments should indicate data getting passed. This is probably why it was deprecated.

Django 4.0 went ahead and removed this altogether, making any code that calls Signal() with the providing_args argument now trigger the TypeError you encountered:

TypeError: Signal.__init__() got an unexpected keyword argument 'providing_args'

AllAuth removed the use of this argument in September of 2020. (See original report on this issue here and the referenced diff)

The person asking the question in this thread was running AllAuth 0.42.0 which does not include this change and is thus incompatible with Django 4.0.

As of today, the last version of Django AllAuth 0.42.0 is compatible with is Django 3.2.9.

👤Rob

7👍

I solved the same problem by replacing

check_request_enabled = Signal(providing_args=["request"])

to

check_request_enabled = Signal("request")

and now its working perfectly.

👤Nishith Shetty

3👍

This is for anyone who faces the same issue on Django 4.0 and is not using AllAuth.

I ran into a similar issue. However, I was not using AllAuth.
The problem is that Django 4.0 does not have any providing_args parameter, so the signal is declared this way.

from django.dispatch import Signal

model_delete_signal = Signal()

Now, you can send any arguments when sending the signal, which will be received in kwargs in the receiver.

For example, I sent the following instance argument while sending the signal in my custom delete function

model_delete_signal.send(sender='session_delete', instance=self)

and received it this way inside the receiver

@receiver(session_delete)
def delete_session(sender, **kwargs):
    instance = kwargs['instance']

Note that, the solution is the same for any Django versions that don’t have providing_args parameter in Singal()

👤Muhammad Zubair

1👍

i don’t know why this happening but (it works on my machine) i solved the same problem by replacing

user_logged_in = Signal(providing_args=["request", "user"])

with

user_logged_in = Signal()

in /usr/local/lib/python3.9/site-packages/allauth/account/signals.py

👤Oussama Tachi

1👍

You can use Signal without argument in new version of Django 4. like this

from django.dispatch import Signal, receiver
notification=Signal()
@receiver(notification)
def show_notification(sender, **kwargs):
    print("sender,", sender)
    print("Kwargs", kwargs)
    print("Notification")

and after where you use this Signal write like this

notification.send(sender=None, request=request, user=['Sakib', 'Malik'])
👤Sakib Malik

1👍

There are better explanations to the question but this is what worked for me…

According to Django

The purely documentational providing_args argument for Signal is deprecated. If you rely on this argument as documentation, you can move the text to a code comment or docstring.

Just comment out the following code from signals.py file in your local project storage:

user_logged_in = Signal(providing_args=["request", "user"])

# Typically followed by `user_logged_in` (unless, e-mail verification kicks in)
user_signed_up = Signal(providing_args=["request", "user"])

password_set = Signal(providing_args=["request", "user"])
password_changed = Signal(providing_args=["request", "user"])
password_reset = Signal(providing_args=["request", "user"])

email_confirmed = Signal(providing_args=["request", "email_address"])
email_confirmation_sent = Signal(
    providing_args=["request", "confirmation", "signup"])

email_changed = Signal(
    providing_args=[
        "request", "user",
        "from_email_address", "to_email_address"])
email_added = Signal(providing_args=["request", "user", "email_address"])
email_removed = Signal(providing_args=["request", "user", "email_address"])

You can find this in /usr/local/lib/python3.10/site-packages/allauth/account/signals.py

👤Abhishek Yadav

0👍

From the django documentation for django 3.1:

The purely documentational providing_args argument for Signal is deprecated. If you rely on this argument as documentation, you can move the text to a code comment or docstring.

👤Pierre.Sassoulas

0👍

First check your signals.py file, where you use Signal() function

SignalName = Signal(providing_args=["request", "user"])

In Signal() function don’t give providing_args as parameter, give arguments like

SignalName = Signal(["request", "user"])
👤Shivam Rathour

Leave a comment