refactor: Improve webhook typing.

[elenakrittik]

Summary

Fixes #626

This is a typing-breaking change.

Should Webhook.edit and Webhook.delete also be overloaded with a Never somewhere to forbid calling them (you can't delete or edit an interaction webhook, right?)?

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• 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, ...)

[shiftinv]

Thanks for the PR! c:
It's not quite clear whether this is meant to be a typing or runtime change; followup is annotated as returning an InteractionFollowupWebhook, but returns a "plain" Webhook in practice.
Types that are only used in annotations can be confusing to some people, so it might be better to actually use this type at runtime too?

As a more general comment: having to subclass something to change a return type annotation for specific situations is rather awkward. I can't think of another solution either, other than maybe generics, which wouldn't help much iac.

[elenakrittik]

It's not quite clear whether this is meant to be a typing or runtime change; followup is annotated as returning an InteractionFollowupWebhook, but returns a "plain" Webhook in practice.
Types that are only used in annotations can be confusing to some people, so it might be better to actually use this type at runtime too?

Making it actually return an InteractionFollowupWebhook will make it a runtime breaking change. I intentionally avoided that "by default" but if it's okay in this case i'll willingly do this!

[shiftinv]

Making it actually return an InteractionFollowupWebhook will make it a runtime breaking change. I intentionally avoided that "by default" but if it's okay in this case i'll willingly do this!

ah, gotcha. 🤔
In that case, what about moving InteractionFollowupWebhook.send into a type-checking block as well? Similar to Bot.__init__, such that the runtime implementation is inherited from the parent class, while being able to adjust the (typing-only) method signature freely.

[elenakrittik]

Making it actually return an InteractionFollowupWebhook will make it a runtime breaking change. I intentionally avoided that "by default" but if it's okay in this case i'll willingly do this!

ah, gotcha. 🤔 In that case, what about moving InteractionFollowupWebhook.send into a type-checking block as well? Similar to Bot.__init__, such that the runtime implementation is inherited from the parent class, while being able to adjust the (typing-only) method signature freely.

That's a nice idea, thanks!

[elenakrittik]

Done in ec9a610!

[Enegg]

having to subclass something to change a return type annotation for specific situations is rather awkward

This is why those situations should be working on distinct types. Not a subclass of one handle-all type, as it later shows the interface allows for more than is actually supported.

[elenakrittik]

having to subclass something to change a return type annotation for specific situations is rather awkward

This is why those situations should be working on distinct types. Not a subclass of one handle-all type, as it later shows the interface allows for more than is actually supported.

So you suggest something like making InteractionFollowupWebhook the base type and Webhook as sub-type?

[Enegg]

So you suggest something like making InteractionFollowupWebhook the base type and Webhook as sub-type?

I suggest making InteractionFollowupWebhook one type and Webhook another type.
Only then consider creating some base/mixin class.

[shiftinv]

This is why those situations should be working on distinct types. Not a subclass of one handle-all type, as it later shows the interface allows for more than is actually supported.

Yeah. A bunch of the class/instance methods on Webhook don't work or make sense in the context of application webhooks. Splitting it into separate types would be great, but is simultaneously the most breaking change