Eneg
Eneg
I've written some example implementation of how the forementioned decorator could look like. ```py from collections import abc from typing import Concatenate, Never, NewType, ParamSpec, Protocol, overload from typing_extensions import...
> 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...
> 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...
Tangentially related: we could add slice support for defining ranges (`Range[int, 0:32]`, `String[str, :10]`). Not sure how useful it'd be.
How about passing the init arguments to the decorator? ```py import attrs class Base: @classmethod def __attrs_init_subclass__(cls, foo): cls.foo = foo print(f"Base has been subclassed by attrs {cls} and foo={cls.foo}.")...
(Also, discord has native polls now, why not use them?)
We are missing a concrete representation for *"unfurled media item"*, used in `Thumbnail`, `MediaGalleryItem` and `File`. I think it makes sense to accept `disnake.Attachment`, `disnake.File` and strings in most places...
The PR could go the other way and replace `.__class__` with `type()`. Just wanted to standardize it as a prelude to standardizing exception messages that I have a branch for
> `ext.commands.ColourConverter` also handles hex colors of various formats, it could probably make use of this new method too. I did expect there being a converter for this, but I'm...
Hard agree with @Sharp-Eyes