@option decorator breaks principle of least surprise
touilleMan opened this issue · 0 comments
Hi,
I've just find out @command
and @option
decorators are incompatile.
For the story, until now I was creating my commands like that:
@broker_manager.command
@broker_manager.option('queue', help='Queue to monitor')
@broker_manager.option('-t', '--timer', help='Polling timer')
def start(queues, timer=60):
[...]
This way the @option
decorators weren't applied and the behavior was quiete clunky (short command name clashing, no default handling etc.). I was assuming the lib was kind of broken (see #142) and it only when I decided to hack into the code to make a fix, that I realized the horrible truth (i.e. you're lib is not broken and I can't read properly the doc ! 😢 )
However, I think there is something to learn about my experience, "explicit is better than implicit" as the zen of python says, the @option
should not do the job of the @command
decorator.
Nevertheless, it would be a shame to break compatibility so deeply for this, so I think the best fix should be to neutralize @command
if it is applied on something already decorated by @option
.
If you agree on this, I would provide a PR with pleasure 😃