Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

@option decorator breaks principle of least surprise #143

Open
touilleMan opened this issue Aug 15, 2015 · 0 comments
Open

@option decorator breaks principle of least surprise #143

touilleMan opened this issue Aug 15, 2015 · 0 comments

Comments

@touilleMan
Copy link
Contributor

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 😃

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant