Hey there, I started a discussion on twitter, asking why
@click.option('--shout', is_flag=True)
is not just
This might seem like a minor issue, but to me, it feels like the option concept is being overused. Please stop me if I'm wrong, I have a windows background but I use the command line a lot, so it might just be a unix/windows/German/English language barrier preventing me to get the idea.
I am unsure I care about the fact that something is an option to begin with. Another part is that the option now uses a lot of kwargs that make it work in strange and oddly specific ways. I can't imagine a good use case for counting with
@click.option('-v', '--verbose', count=True)
At least, when using separate decorators such as
@click.count('-v', '--verbose')
The concept could be isolated. I would like to point somewhere in the direction of the single responsibility principle, or something like that, but I would not like to make this a discussion on principles. I feel that this, if it is a specific concept, deserves its own decorator that reflects its name,
I believe that like this signature would become less noisy, since the function itself could preconfigure a lot of values (as with the flag thingy the flag decorator could easily just set the is_flag to true, withough me having to remember to put in yet another kwarg).
You answered to my inquiry, that a solution like @click.flag('--shout')
would be unnecessary, because a flag would still be an option. This is true, but the distinction would allow for a separation of the concepts non the less. Of course, a flag is still an option, but it is a specific case of one and there is no need to name things by the highest level of objects in their inheritance hierarchy. After all, a string in python is an object, yet you don't call it a string_object and, I guess it would be fair to argue that a string is a fairly specific type of an object, as is an int or a character.
Rather than having one big click.option decorator I would love for click to separate the concepts some more.
Rather than using
@click.option('--password', prompt=True, hide_input=True, confirmation_prompt=True)
The code could already provide this (indeed more useful than the counting) case as a specific decorator:
@click.password('--password', confirm=True)
The functionality is already there and writing a decorator like this would be possible by merely creating a couple of aliases that in the end point back to or derive from option, and could easily abstract away a lot of the complexity by providing sensible defaults.
Going through this page: http://click.pocoo.org/options/#basic-value-options
I can't help but invent more specific decorators for the individual sections in my mind, such as counting, flags, switches and so on, all of which are different concepts, all of which are provided by one massive function, but all of which appear to be different concepts, at least enough so to deserve their own very nice documentation.
This was a lot of criticism, I apologize if it is very direct, please read it with a smile and see it as a different point of view and never a need to be offended.
I really love the hard work you have put into this, I really love where this is going, I really love flask and your work and have a very deep respect for you.