Possibly make a new method instead (guild.bulk_ban) since they're different endpoints, and similar stuff is split as well (e.g. fetch_member vs fetch_members)

I did consider this initially, but after mulling it over I figured it made more sense to compare to Member.add_roles/remove_roles, which similarly accepts 1 or multiple Snowflakes and incorporates different routes depending on the situation

Possibly make a new method instead (guild.bulk_ban) since they're different endpoints, and similar stuff is split as well (e.g. fetch_member vs fetch_members)

I did consider this initially, but after mulling it over I figured it made more sense to compare to Member.add_roles/remove_roles, which similarly accepts 1 or multiple Snowflakes and incorporates different routes depending on the situation

My main issue is we end up having multiple different return types, which isn't a massive problem but might be confusing as some people might pass a list and not expect it to give None back (if the list had a length of 1), similar to some confusion that was discussed a while ago about the return types of ApplicationContext.respond

I agree with plun, a new method should suffice.

Upon implementing it myself I agree with doru, a seperate method is needed

With this, 2.6 is officially breaking so please include the relevant warnings in any announcements

Before we merge it, @Dorukyum, do you agree on removing the obsolete parameter completely in this PR?

Before we merge it, @Dorukyum, do you agree on removing the obsolete parameter completely in this PR?

It's fine. A seperate pr for each change would obviously be better, but the changes here are relevant enough I guess.