Is click too verbose in its api?

[pallets]

Is click too verbose in its api?

[mitsuhiko]

The decorators themselves don't do much besides creating Argument or Option instances. So while you could potentially split up the interface into flags, options, arguments, counters and whatnot it would not make sense to split the lower level class up because there really is not that much stuff in there that can be clearly isolated.

As an example do options become flags by various modes. For instance option('--foo/--bar') automatically makes something into a flag, same with option('--foo', flag_value='whatever').

Counters can't become a separate decorator easily either because a counter still accepts all the other behaviors of an option (sans counter). For instance you can set a default or change the type from an integer to a integer range etc.

The only thing you would gain at the end of the day is to make the edge case @click.option('--x', is_flag=True) (which is strongly discouraged!) to @click.flag('-x'). I'm not sure I like that.

But more than anything, once you go down that road you now have the problem that certain behavior is restricted to options whereas it would otherwise also work for arguments. In case of flags here is no reason why at one point we might not find a use for exposing them to arguments as well.

It's not really possible to "create decorators" that hold this functionality because the decorators don't actually do anything. The underlying class does, and that class does multiple things at once and is not clearly cut and separated.

[cessor]

Thank you for your clarification. I will spend some time with the source code before answering.