Use functools.wraps instead of decorator

[Pliner]

Just a small cleanup: only 3.9+ is supported, so it looks fine to switch to functools.wraps.

[Pliner]

It looks like there are two options for now: ignore or cast.

PS In python 3.10 it was resolved via https://docs.python.org/3/library/typing.html#typing.ParamSpec.

[Pliner]

@csmarchbanks Could you look on it please? Thanks.

[Pliner]

I'm not sure these checks are relevant now: it could be worth ditching them.

[csmarchbanks]

Hmm, I am not super familiar with functools.wraps but I see some disagreement around if it actually preserves the signature, for example: https://stackoverflow.com/questions/13907644/decorator-module-vs-functools-wraps/55363013#55363013. Are there some recent posts around functools.wraps for 3.6+ that fully preserve the signature?

[Pliner]

Hmm, I am not super familiar with functools.wraps but I see some disagreement around if it actually preserves the signature, for example: https://stackoverflow.com/questions/13907644/decorator-module-vs-functools-wraps/55363013#55363013. Are there some recent posts around functools.wraps for 3.6+ that fully preserve the signature?

Hey @csmarchbanks,

Sorry for the delayed for 2 years response.

I have investigated the mentioned downsides of functools.wraps.

The wrapper code can not easily access an argument using its name, from the received *args, **kwargs. Indeed one would have to handle all cases (positional, keyword, default)

It doesn't seem to be relevant for this library, because they are passed as it is in all usecases.

The wrapper code will execute even when the provided arguments are invalid.

It is true and might be relevant, however:

1. It doesn't look like too bad (in my humble opinion ofc) for the use cases inside the library (btw, this fails only at runtime).
2. A better way to catch this kind of errors might be to annotate decorators properly with ParamSpec so that incorrectly passed arguments will be detected by a type checker.

So, as part of this PR I have added a proper typing for decorators. Unfortunately,
ParamSpec is only availably from 3.10+, so I had to depend on typing_extensions for 3.9. For example, aiohttp depends on it as well (https://github.com/aio-libs/aiohttp/blob/master/requirements/base.txt#L41).

PS I don't know your opinion about this additional dependency, but it might be reasonable for the benefits we will get from the proper annotations, considering this extra dependency is only for 3.9.