Deprecate providing_args argument from Signal

[Jon Dufresne]

The argument is and always has been purely documentational. It provides no functionality or checking. Therefore, these values are stored in memory for no real use.

Documentation can be handled just as easily by a code comment or real documentation articles.

On a more practical level, I rarely signals, so I recently had to look up their interface. Seeing this providing_args argument required me to think about how to best use it, only to realize it actually goes unused. We can remove this cognitive distraction from the docs.

It has caused other small confusion in the past: #19579.

[Jon Dufresne]

​https://github.com/django/django/pull/12513

[Carlton Gibson]

On a more practical level, I rarely signals, so I recently had to look up their interface. Seeing this providing_args argument required me to think about how to best use it, only to realize it actually goes unused. We can remove this cognitive distraction from the docs.

Amen to this sentiment. We put every single user through the exact same mental cycle, for, I agree, very little.

​Comment from 2008 on the mailing list:

We went back and forth trying to balance features and performance and decided to remove the functionality still referenced in the docstring. At the moment, the providing_args parameter is purely for documentation purposes, but extra checking may be added in the future if necessary.

I think 12 years later we can accept that this extra never will be added, and simplify the API.

The signals docs list the parameters. ​For example, `pre_init`. I've never thought to look to the source for that. I can't believe many other folks have either.

[Carlton Gibson <carlton@…>]

In 769cee5:

Fixed #31327 -- Deprecated providing_args argument for Signal.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 1adcf203:

Refs #31327 -- Removed providing_args argument for Signal per deprecation timeline.