This is suggested to prevent spamming the console unnecesarilly.
Info should be used to output information to the user that is important, but
not a warning or an error. If I am bundling a bot as a modular package then
it doesn't really make sense to spam their console with every time a coroutine
is subscribed to, as it likely will not mean anything to the user. If they are
interested in this, it would make more sense to just to enable debugging first.
I have made this change, as I am writing a wrapper for this library for a
private project, and that will handle dispatching events, thus, I do not
need a prompt for each event that is subscribed to in this module outside of
DEBUG. Currently, with logging set to INFO, I am getting 47 lines reading:
INFO:discord.client:coroutine has successfully been registered as an event
...being output as my bot starts, and without having to disable INFO logging
altogether, I am currently having to temporarily change the verbosity of the
logger as the events are initialised, which is not desirable as it could
potentially cover up any other INFO messages that would be useful to have
output.
Using a filter seems like a bit of a hacky workaround. If this isn't acceptable
then another alternative would be to add a parameter to the constructor of
discord.Client to enable or disable printing this information.
This adds:
* CategoryChannel, which represents a category
* Guild.by_category() which traverses the channels grouping by category
* Guild.categories to get a list of categories
* abc.GuildChannel.category to get the category a channel belongs to
* sync_permissions keyword argument to abc.GuildChannel.edit to sync
permissions with a pre-existing or new category
* category keyword argument to abc.GuildChannel.edit to move a channel
to a category
This affects:
* Member.add_roles
* Member.remove_roles
This is the main attempt of fixing long standing bugs like #56. Since
cache consistency is too hard to ask for due to eventual consistency
and this generally being one of the only main roadblocks that the
cache ruins, it's best to just implement it in terms of the atomic
endpoint instead.
Fixes#56
The global emoji cache still managed to somehow cause memory leaks. By
storing IDs directly and lazily evaluating them when needed this
essentially removes all strong references to Guild objects which would
cause an explosion in memory usage.
espeonofespeonage
Rapptz
Jake
Giovani Irimea
rooni
Harmon
Steve C
Nick
ReinaSakuraba
Ethan