This commit is a fairly large chunk of code that fixes a previously
annoying and nasty bug causing cached_properties to not be cleared.
Alongside this bug fix I took the opportunity to refactor the entire
methdology behind cached properties, and bind them more strictly to the
behavior of models.
Prior to this commit, cached_properties where not be properly reset upon
a model's `update` method being called due to some invalid code. Along
with this issue, the actual behavior of cached properties landed in a
weird in-between/gray area where they had to support both non-model and
model use cases.
The new version of cached_property is strictly for use with models, and
another version `simple_cached_property` was added to support other use
cases. The new cached_property simply builds an actual `property` within
the metaclass. This is fairly efficient, and also reduces the surface
area of behavior.
When writing this I messed around with a few ideas, including allowing
the user of `cached_property` to define a linkage between the property
and fields that should invalidate its cached value, but this was both
messy and introduced massive cognitive load on understand when a
cached_property should be cleared. Although this version is slighty less
efficient, I'm very much in favor of it vs the alternatives I tried.
Previously guild_id sat outside of the object which created a
semi-invalid role object without guild information. This would be saved
in the guild state.
One option for fixing this would just to be fixing the guild_id of the
role within the state, however I think it's responible to expect roles
passed from the event to have valid context/guild attributes.
UserDict was the wrong way to achieve this, modern versions of Python
can just subclass dict. This provides an immense performance boost by
allowing getitem/setitem calls to be routed directly to the underlying
storage within cpython land, instead of having to route through the
items MRO and eventually hit __dict__
This would cause our GatewayClient to get rate limited when guild member
syncing was enabled for clients with a large number of guilds. The bug
had to do with the limiter releaseing all the requests after the initial
period it blocked for. This was resolved by rewriting the SimpleLimiter
to use a semaphore.
It's possible for Discord to send us presences for users which do not
actually exist in the Guild (remember; eventually consistent), so we
should throw these away when we get them.
As per the documentation for requests, this allows us to have a
persistent TCP connection and uses connection pooling, causing some
speed ups instead of constantly recreating the session object via
`requests.request`.
Andrei
Ondřej Slabý
slice
Andrei Zbikowski
Danny