discord.py 2.0 did some refactoring with how avatars are handled - User.avatar no longer returns a default avatar if a user has a default avatar, instead returning None (as, well, according to the API, they have none). User.display_avatar allows default avatars to be returned, though. userinfo in converters.py in examples did not account for this change and so could possibly break if the user mentioned for it has a default avatar. This basically fixes that by using display_avatar over avatar.
Checklist
If code changes were made then they have been tested.
I have updated the documentation to reflect the changes.
This PR fixes an issue.
This PR adds something new (e.g. new method or parameters).
This PR is a breaking change (e.g. methods or parameters removed/renamed)
This PR is not a code change (e.g. documentation, README, ...)
## Summary
`discord.py 2.0` did some refactoring with how avatars are handled - `User.avatar` no longer returns a default avatar if a user has a default avatar, instead returning `None` (as, well, according to the API, they have none). `User.display_avatar` allows default avatars to be returned, though.
`userinfo` in `converters.py` in `examples` did not account for this change and so could possibly break if the user mentioned for it has a default avatar. This basically fixes that by using `display_avatar` over `avatar`.
## Checklist
<!-- Put an x inside [ ] to check it, like so: [x] -->
- [x] If code changes were made then they have been tested.
- [ ] I have updated the documentation to reflect the changes.
- [ ] This PR fixes an issue.
- [ ] This PR adds something new (e.g. new method or parameters).
- [ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
- [ ] This PR is **not** a code change (e.g. documentation, README, ...)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
discord.py 2.0did some refactoring with how avatars are handled -User.avatarno longer returns a default avatar if a user has a default avatar, instead returningNone(as, well, according to the API, they have none).User.display_avatarallows default avatars to be returned, though.userinfoinconverters.pyinexamplesdid not account for this change and so could possibly break if the user mentioned for it has a default avatar. This basically fixes that by usingdisplay_avataroveravatar.Checklist
LGTM
just fix the conflict
Fixed!