[RFC] [commands] custom default arguments

[khazhyk]

Modeled slightly after Converters, allow specifying Converter-like class
for context-based default parameters. e.g.

class Author(ParamDefault):
  async def default(self, ctx):
    return ctx.author

async def my_command(ctx, user: discord.Member=Author):
  ...

[Gelbpunkt]

@Rapptz any update/statement on this? Would make some discord.py code far prettier and seems a not-breaking change.
Referring to the example, currently it's:

async def my_command(ctx, user: discord.Member=None):
    user = user or ctx.author

which is ugly

[khazhyk]

I might have time to finish this up this week/end

[khazhyk]

• Added example and docs
• Fixed issue where non-specified converter type would default to type instead of str

Would appreciate others testing and comments.

[Gelbpunkt]

Does the job and is a great code readability enhancement

[Gelbpunkt]

I may have found a bug?

from discord.ext.commands.default import Author

@bot.command()
async def testme(ctx, thing: discord.Member = Author):
    await ctx.send(thing.joined_at)

This raises AttributeError: type object 'Author' has no attribute 'joined_at'.
When I print dir(thing), it's all the proper attributes there, even joined_at

[khazhyk]

I can't reproduce ( see https://canary.discordapp.com/channels/336642139381301249/381963689470984203/574499828172587038 and following) - the behavior your experiencing seems like the command framework isn't evaluating the customdefaults, does this behavior persist past restart?

[khazhyk]

Ah - ctx.invoke() is what isn't working

ctx.invoke doesn't call converters at all - so also won't resolve defaults. what you probably want is bot.invoke(ctx) rather than ctx.invoke(command) (which do different things)

[Gelbpunkt]

Was an issue on my end - the code proposed in the PR works fine. Thanks!

[khazhyk]

Pushed an update to fix a missing isclass check which could cause some commands with defaults to break... whoops

[Gelbpunkt]

I also found this to look weird on command.signature. Here's what it looks like:
[argument=<class 'discord.ext.commands.default.Author'>]

Is there a way to prettify that or do I have to write my own signature generator?

[NCPlayz]

The classes should probably define their own __repr__ to prettify that

[Gelbpunkt]

Yea, I know that. Not sure if they want to write a new repr for the "prepacked" defaults and what it would be, though. [argument=Author] isn't very user-friendly either...

[thecaralice]

@khazhyk I created a PR to your fork to fix the problem with signature khazhyk#2

[khazhyk]

Does the default HelpCommand already have special casing for Converter? It would make sense to treat it similarly to Converter (which does not override repr just for HelpCommand)

[thecaralice]

Type hints (including converters) are not displayed in help lol

[thecaralice]

I tested your example from docs and there are some name errors

[avayert]

I don't like the duplicate name for Guild (and to a certain extent Channel) as it already exists as discord.Guild. discord.Guild also has converter support built into it in the commands API which would make this inconsistent and a little confusing, even when using the namespaced default.Guild.

I don't currently know how or if it would even make sense to attach the defaults to said class, but a simple fix could be to rename them to CurrentGuild and CurrentChannel, which I find makes the signature more comprehensible to read.

[ioistired]

Attaching the defaults to the classes would be far worse IMO, as you'd end up with signatures like "x: discord.Guild = discord.Guild" which to me.is very confusing. I think it would be better to rename them to Current* yes.

[khazhyk]

I don't currently know how or if it would even make sense to attach the defaults to said class, but a simple fix could be to rename them to CurrentGuild and CurrentChannel, which I find makes the signature more comprehensible to read.

Doing CurrentGuild and CurrentChannel makes sense to me, done.

[TheRockettek]

Because it needs to be reviewed. The only tag there is my dude

[sairam4123]

Is this dead?

[thecaralice]

It’s still waiting for review

[sairam4123]

Because it has been 1 year
that's why, I am asking!

[khazhyk]

Rebased this. I recall some people claimed issues between customdefaults and some of the newer argument types (greedy, etc.). Is that the case/still the case? Is there an example that behaves weirdly?

[sairam4123]

Let me test the code.

[sairam4123]

Just a suggestion, instead of Author, you could do, CurrentAuthor would be nice to see.

[sairam4123]

I got an error when trying to use Greedy with this. @khazhyk

Ignoring exception in command my_command:
Traceback (most recent call last):
  File "F:\PyCharm Python Works\OpenCityBot\discord.py\discord\ext\commands\core.py", line 86, in wrapped
    ret = await coro(*args, **kwargs)
  File "F:\PyCharm Python Works\OpenCityBot\discord.py\test.py", line 14, in my_command
    await ctx.send(member.display_name)
AttributeError: type object 'Author' has no attribute 'display_name'

Here's the code I used.

@bot.command()
async def my_command(ctx, member: commands.Greedy[discord.Member] = Author, channel: discord.TextChannel = CurrentChannel, guild = CurrentGuild):
    await ctx.send(member.display_name)
    await ctx.send(channel.name)
    await ctx.send(guild.name)

Without Greedy it works super fine, so, check why the Greedy isn't working, I'll check the others as well, like Optional and Channel.

Tested Union[discord.Member, discord.User] works fine
Tested Optional[discord.Member] works fine

To fix:

1. Greedy.

[khazhyk]

Just a suggestion, instead of Author, you could do, CurrentAuthor would be nice to see.

The reason I went for "Author" instead of "CurrentAuthor" is that Author I think should be unambiguous, vs. Channel/Guild, which would be ambiguous. And stuff like CurrentUser also could be misunderstood. So CurrentAuthor seems too wordy, imo, but does look slightly more consistent. I'm indifferent, do others have thoughts on this?

[khazhyk]

@sairam4123 figured out and fixed the issue with Greedy, thanks! That should work now.

[khazhyk]

I also added a commit from @sgtlaggy which I thought was useful, although there could be some bikeshedding to do here. In particular, I'm not so sure that having a member variable to override is the best api.

one option, which I don't think works in this current PR, is if the defaultargument was both a converter and a default, then detect if the default is (also) a converter, and use that, e.g.

class MyDefault(DefaultArgument, MyConverter):
  ...

[Tari-dev]

If we are going to add this couldn't we support attachment with ext.commands?
Also we could support for slash-ext hybrid?

[khazhyk]

Sorry, as evidenced by my lack of touching this for a while, I'm not really motivated to push this to completion. I still think something like this is a good idea, and if anyone else wants to implement something like this (or polish this code up for the lib), I would be happy to see it.