You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.
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')defstart(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 😃
The text was updated successfully, but these errors were encountered:
Hi,
I've just find out
@command
and@option
decorators are incompatile.For the story, until now I was creating my commands like that:
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 😃
The text was updated successfully, but these errors were encountered: