feat: implement get function

[EepyElvyra]

About

This is a new approach for the get method. It is now located in a separate file, so the @overloads don't mess another file up. Having an overload decorator for every object allows to precisely show the user what arguments he has to put in, and for us to do a simple **kwagrs into the function that actually gets the object

Checklist

• I've ran pre-commit to format and lint the change(s) made.
• I've checked to make sure the change(s) work on 3.8.6 and higher.
• This fixes/solves an Issue.
  • (If existent):
• I've made this pull request for/as: (check all that apply)
  • Documentation
  • Breaking change
  • New feature/enhancement
  • Bugfix

[EepyElvyra]

pre commit check will (hopefully) fail until webhook pr is merged

[Toricane]

I didn't mean that...

[Toricane]

Looks good, just missing cache implementation.

Also, should getting a list of an object be implemented, or is that out of the scope of this?
For example, List[User], with a list of user IDs inputted, which returns a list of User objects.

[EepyElvyra]

I hate everything xD

[AstreaTSS]

I find the number of double underscored variables to be excessive and unnecessary in this case, but that's a me thing.

Otherwise, the code looks good! I haven't tested it though - busy with some other things. I also likely have missed a couple of things, which is why I'm not giving it explicit approval.

[EepyElvyra]

I find the number of double underscored variables to be excessive and unnecessary in this case, but that's a me thing.

Otherwise, the code looks good! I haven't tested it though - busy with some other things. I also likely have missed a couple of things, which is why I'm not giving it explicit approval.

I only made double underscores when single underscore was used already, no? (except the two functions)

[i0bs]

Before I make a final review, I'd really like to discuss my disdain for @overload.

This is going to obviously lead to an extremely messy and obfuscated pattern in the type hinting for numerous objects. Is there not any other way to assure to end-users that objects passed by the Discord API/Gateway are usable in this context?

[EepyElvyra]

Before I make a final review, I'd really like to discuss my disdain for @overload.

This is going to obviously lead to an extremely messy and obfuscated pattern in the type hinting for numerous objects. Is there not any other way to assure to end-users that objects passed by the Discord API/Gateway are usable in this context?

There are 9 overloads (what already is a massive reduction from the 36 we had before) and the typehints can be controlled via the _SA and _MA TypeVars, i don't think that it is too messy

[i0bs]

Long awaited, and after nearly a year of debating how to develop this, I'm giving it my seal of approval.

Outdated

[Toricane]

LGTM!