pycord v2 treats Member as an extended User object and copies its attributes; while this isn't entirely wrong, Discord treats Member and User as unique objects. In many cases a Member payload includes a user key, but this is not guaranteed.
- next should completely separate
Member and User as per their respective specs.
- Where there is an inner
user key, it should use a new MemberWithUser class (name as you wish) that's functionally similar to v2's Member.
MemberWithUser inherits both Member and User, overriding Member properties over matching User properties.
Member can resolve to MemberWithUser if there's a cached User available on the client.
This change is potentially awkward for users, but it is worth getting a better match with the API and properly knowing what attributes to expect. You are free
pycord v2 treats
Memberas an extendedUserobject and copies its attributes; while this isn't entirely wrong, Discord treatsMemberandUseras unique objects. In many cases aMemberpayload includes auserkey, but this is not guaranteed.MemberandUseras per their respective specs.userkey, it should use a newMemberWithUserclass (name as you wish) that's functionally similar to v2'sMember.MemberWithUserinherits bothMemberandUser, overridingMemberproperties over matchingUserproperties.Membercan resolve toMemberWithUserif there's a cachedUseravailable on the client.This change is potentially awkward for users, but it is worth getting a better match with the API and properly knowing what attributes to expect. You are free