Discord.py: Expose metadata endpoints

Created on 14 Mar 2016 · 8Comments · Source: Rapptz/discord.py

api/guilds/:id has metadata for servers (this seems to require you're joined to the server) (this also has full role info)
api/guilds/:id/members/:id can be used to get member metadata, this might be useful for non-ws usage of the lib. (this requires you are joined to the server)
api/guilds/:id/channels - useful for non-ws (requires you're joined to server)

/api/v6/users/@me/guilds - some others too

feature request

Source

khazhyk

👍2

Most helpful comment

Can we have a more obvious difference between get_ methods which touch
local cache vs get_ methods which cause an http request? (I guess that
would be a breaking change but 1.0 isn't out yet...) E.g. people get
confused that get_user_info is an http request, vs. get_user is cache, and
this would introduce a second case. Maybe fetch_ prefix or something...

On Mon, Mar 11, 2019, 2:13 PM Nadir Chowdhury <[email protected]
wrote:

Although how old it is, it does affect #1822
https://github.com/Rapptz/discord.py/issues/1822, so I thought of two
ways this could be implemented (in rewrite).
Implementation No. 1

...
async def get_guild(self, id, *, metadata=False):
"""Returns a :class:Guild with the given ID. If not found, returns None."""
if metadata:
data = await self.http.get_guild(id)
return Guild(data=data, state=self._connection)
return self._connection._get_guild(id)

This would allow the user to change between if they want to use the WS
content, or the http request. The only problem with this is that it could
induce a breaking change, since you would have to await them, which
currently is not required.
Implementation No. 2

...
async def get_guild_metadata(self, id):
"""Returns a :class:Guild with the given ID via the API. If not found, returns None."""
data = await self.http.get_guild(id)
return Guild(data=data, state=self._connection)

This would not be a breaking change, but it does mean that it would be
longer to type, if that's a valid issue.

Both implementations use this in discord.http.HTTPClient:

...
def get_guild(self, guild_id):
return self.request(Route('GET', '/guilds/{guild_id}', guild_id=guild_id))

Would any of these implementations be viable in your eyes, @Rapptz
https://github.com/Rapptz?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Rapptz/discord.py/issues/133#issuecomment-471732127,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABeHiUbzrwI1DJADyBEGniK6Yhfm546pks5vVsbggaJpZM4HwYcg
.

khazhyk on 11 Mar 2019

👍3

All 8 comments

Although how old it is, it does affect #1822, so I thought of two ways this could be implemented (in rewrite).

Implementation No. 1

...
    async def get_guild(self, id, *, metadata=False):
        """Returns a :class:`Guild` with the given ID. If not found, returns None."""
        if metadata:
            data = await self.http.get_guild(id)
            return Guild(data=data, state=self._connection)
        return self._connection._get_guild(id)

This would allow the user to change between if they want to use the WS content, or the http request. The only problem with this is that it could induce a breaking change, since you would have to await them, which currently is not required.

Implementation No. 2

...
    async def get_guild_metadata(self, id):
        """Returns a :class:`Guild` with the given ID via the API. If not found, returns None."""
        data = await self.http.get_guild(id)
        return Guild(data=data, state=self._connection)

This would not be a breaking change, but it does mean that it would be longer to type, if that's a valid issue.

Both implementations use this in discord.http.HTTPClient:

...
    def get_guild(self, guild_id):
        return self.request(Route('GET', '/guilds/{guild_id}', guild_id=guild_id))

Would any of these implementations be viable in your eyes, @Rapptz?

NCPlayz on 11 Mar 2019

On Mon, Mar 11, 2019, 2:13 PM Nadir Chowdhury <[email protected]
wrote:

Although how old it is, it does affect #1822
https://github.com/Rapptz/discord.py/issues/1822, so I thought of two
ways this could be implemented (in rewrite).
Implementation No. 1

...
async def get_guild(self, id, *, metadata=False):
"""Returns a :class:Guild with the given ID. If not found, returns None."""
if metadata:
data = await self.http.get_guild(id)
return Guild(data=data, state=self._connection)
return self._connection._get_guild(id)

This would allow the user to change between if they want to use the WS
content, or the http request. The only problem with this is that it could
induce a breaking change, since you would have to await them, which
currently is not required.
Implementation No. 2

...
async def get_guild_metadata(self, id):
"""Returns a :class:Guild with the given ID via the API. If not found, returns None."""
data = await self.http.get_guild(id)
return Guild(data=data, state=self._connection)

This would not be a breaking change, but it does mean that it would be
longer to type, if that's a valid issue.

Both implementations use this in discord.http.HTTPClient:

...
def get_guild(self, guild_id):
return self.request(Route('GET', '/guilds/{guild_id}', guild_id=guild_id))

Would any of these implementations be viable in your eyes, @Rapptz
https://github.com/Rapptz?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Rapptz/discord.py/issues/133#issuecomment-471732127,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABeHiUbzrwI1DJADyBEGniK6Yhfm546pks5vVsbggaJpZM4HwYcg
.

khazhyk on 11 Mar 2019

👍3

You raise an interesting point, since they should be to avoid confusion. Using get_ for a http request would definitely make sense since you are literally sending a GET request.
As you mentioned, discord.py 1.0.0 has not been released yet, which could mean that there's an excuse to change it now rather than after release.
Although I am with you on this, I feel like changing how it is named would require a lot of changes (around 38 function name changes, and a possible more than 50 call changes based off what IntelliJ is telling me).

NCPlayz on 11 Mar 2019

I don't think get makes any more or less sense for the http requests than
fetch or any other word. (get is also used for dicts, and those don't do
http requests...). There's only like 2-3 functions that do http requests
and they're rarely used, so if we want to change anything, it should be
those.

On Mon, Mar 11, 2019, 2:34 PM Nadir Chowdhury <[email protected]
wrote:

You raise an interesting point, since they should be to avoid confusion.
Using get_ for a http request would definitely make sense since you are
literally sending a GET request.
As you mentioned, discord.py 1.0.0 has not been released yet, which could
mean that there's an excuse to change it now rather than after release.
Although I am with you on this, I feel like changing how it is named would
require a lot of changes (around 38 function name changes, and a
possible more than 50 call changes based off what IntelliJ is telling me).

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Rapptz/discord.py/issues/133#issuecomment-471738955,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABeHifIM77sSO9s5dXlqMMuLRZtuFQpkks5vVsvJgaJpZM4HwYcg
.