Was there a particular reason decorators were favored over signature parsing?

[GoogolGenius]

This is a design question:

You may be aware that Ashlen created a simple extension on top of Tanjun that allows for signature parsing, however for the built in implementation, someone had talked to me and I realized that this might not be a good idea for type safety.

I know you can pass in arguments to the function with the decorators and type hint those but this still isn’t good in some scenarios where the function params are completely wrong from the decorators. If you try to access the ctx.options dictionary key values for options, there is no real typing data there either, it’s just Any. As UX, there is no autocomplete.

Is there a particular reason you decided decorators were a better way to handle command arguments?

[FasterSpeeding]

Decorators weren't a design choice, they just relay fluent methods on the relevant object to give you a different method of call chaining; the design choice is that this library uses the fluent builder pattern.

ctx.options mostly exists for checks and hooks (not necessarily command execution as it's less feature rich than pass_as_kwargs), it is built before any argument conversion or verification is done and therefore will not contain defaults or the converted value but rather contains SlashOptions which has the raw value and helper methods which asserts the option type for you and get the "resolved" object.

Signature parsing has been a maybe-TODO for years by now https://github.com/FasterSpeeding/Tanjun/projects/1#card-50050993 but it's a complex thing to add ontop as it'd have to be cross-compatible between message and slash commands; and also isn't a priority and therefore hasn't been implemented but there is also a 3rd party slash-command specific signature parser implemented at https://github.com/thesadru/tanchi.

but this still isn’t good in some scenarios where the function params are completely wrong from the decorators

This this falls under the scope of the 2nd part of this maybe-todo https://github.com/FasterSpeeding/Tanjun/projects/1#card-50050993 (adding logic for verifying the names of options match) and isnt a problem signature parsing is really needed to deal with.

[GoogolGenius]

I see, thanks for explaining. And I am aware of the 3rd party implementation of signature parsing as I mentioned👍.
Might still be nice someday to have slightly better UX in some ways with signature parsing but it's fine that it's in the backlog right now.

[GoogolGenius]

I think the name verification could be a good idea as well. Does Tanjun currently check the types of the passed kwargs against the option decorators by the way?