fix: 🧑‍💻 Add kwargs explicitly for app-command decorators

[ToothyDev]

Summary

This explicitly adds typed kwargs to the slash_command, user_command and message_command decorators as well as to the basic application_command decorator.

Information

• This PR fixes an issue.
• This PR adds something new (e.g. new method or parameters).
• This PR is a breaking change (e.g. methods or parameters removed/renamed).
• This PR is not a code change (e.g. documentation, README, typehinting,
  examples, ...).

Checklist

• I have searched the open pull requests for duplicates.
• If code changes were made then they have been tested.
  • I have updated the documentation to reflect the changes.
• If type: ignore comments were used, a comment is also left explaining why.
• I have updated the changelog to include these changes.

[pycord-app]

Thanks for opening this pull request!
Please make sure you have read the Contributing Guidelines and Code of Conduct.

This pull request can be checked-out with:

git fetch origin pull/3119/head:pr-3119
git checkout pr-3119

This pull request can be installed with:

pip install git+https://github.com/Pycord-Development/pycord@refs/pull/3119/head

[Paillat-dev]

Should do the trick for now

[Paillat-dev]

Should do the trick for now

[Soheab]

Why are none of these kwargs only? This will look confusing to the "beginning" users.

[ToothyDev]

opinions @Paillat-dev @JustaSqu1d

[Paillat-dev]

@Soheab is right. Where the original only accepted **kwargs these should be kwarg-only as well.

[plun1331]

whatever the other person said about kwargs

[Paillat-dev]

lgtm

a

[Dorukyum]

Since all applicable kwargs are explicitly typed now, shouldn't we remove this?

[Paillat-dev]

We could but it would break for people that were passing non-existent params previously. Which is kinda their fault but we also did accept **kwargs. I am fine either ways personally.

[Lulalaby]

we should remove it def in future. but for rn. lets do a vote in discord

[Dorukyum]

I think we should remove it in this pull request while we're at it tbh. We did allow **kwargs but non-existent params had no effect anyway.

[Soheab]

We could disallow it at type checking using overloads or if TYPE_CHECKING: ...

[Paillat-dev]

I agree w/soheab. And maybe have a deprecation warning or runtime warning

[ToothyDev]

I think overloads will be messy here for all these different functions, I'd be on Doru's side. This isn't breaking correct code.

[vmphase]

What about **kwargs: Never? Type checkers will reject unknown kwargs at call sites, and it won't cause any runtime crashes for existing callers (nevertheless, removing **kwargs completely seems the best).

[Paillat-dev]

Note that guild_only is missing from all of these, and while it is deprecated, its deprecation is entirely separate from any potential deprecation/breakage we might have here. It should still be allowed where it was before. We haven't specified any removal date for guild_only=value in its own deprecation notice.

[Paillat-dev]

After sleeping over this, I believe the best course of action here is to type them as Never as suggested by vmphase, and have a deprecation notice for removal in 2.9.

However, guild_only should be added as a separate parameter and default to MISSING (see class ApplicationCommand) where it isn't present currently. No special code is needed for it other than normally passing it down to the constructor because a deprecation notice is already present where needed for it.

If anyone has something to add or a different suggestion please share it. Otherwise we can go forward with this. It should realistically be the least code-heavy change of doing this.