CLI: can bool parameters become `--flag` instead of `--flag true`?

[indigoviolet]

🚀 Feature request

Currently, while using CLI(), a bool param must be specified on the command line as --flag true or --flag yes. Is it possible to set it up such that --flag without the yes or true will still pass True into the function?

Motivation

I see this commonly tripping up members on my team. --flag is a common pattern, store_true in argparse, supported in python-fire (https://github.com/google/python-fire/blob/master/docs/guide.md#boolean-arguments)

Pitch

--flag should work the same as --flag yes or --flag true

Alternatives

[mauvilsa]

Certainly could be implemented. It is a commonly used behavior in many CLIs. This is already available with ActionYesNo, but not when an argument is created from a type hint.

Note that adding this feature introduces edge cases which might make the CLI usage worse. If true/false is required, when it is not given, there is always an error including [--bool {true,false}] and --bool: expected one argument. Maybe not the best of messages, but mistakes don't lead to executing the process with unintended parameters. However, making the value optional, can lead to silent mistakes. Which is why there is a warning about this in the fire documentation https://github.com/google/python-fire/blob/master/docs/guide.md#boolean-arguments.

For consistency this would need to work with a bool type, but also for more complex types, e.g. bool | str | None. The behavior for all possible cases needs to be clearly defined and be intuitive for users.

[jhony-asanuma-oxb]

I guess the store_true behaviour is the most common in any shell command, I never see any tool asking for a --flag yes or --flag true!
I really appreciate it if you could implement this, and in my opinion, only for the bool type, and keep the existing behaviour for other types.

[mauvilsa]

I realized that this is already possible and there is no need to implement a new feature. Just subclass the parser and customize how the argument is added. For example it could be:

from jsonargparse import ArgumentParser, ActionYesNo, CLI

class CustomArgumentParser(ArgumentParser):
    def add_argument(self, *args, **kwargs):
        if "type" in kwargs and kwargs["type"] == bool:
            kwargs.pop("type")
            kwargs["action"] = ActionYesNo
        return super().add_argument(*args, **kwargs)

def function(bool: bool = False):
    print(bool)

CLI(function, parser_class=CustomArgumentParser)

And this allows people to customize the argument however they wish.

[mauvilsa]

Actually this only works in simple cases. But I could fix it so that it works in general.

[jhony-asanuma-oxb]

yeah, that would be great! many thanks @mauvilsa 🙏🏻

[mauvilsa]

The reason why the CustomArgumentParser above doesn't work in general is because of how argparse is designed. There is add_argument in two places, the parser class and the argument group class. But it wouldn't be good user experience requiring people to subclass two classes and the somehow pass along the group class which currently is private. So my idea is that the CustomArgumentParser written just like above should work for all cases.

I created pull request #661. It should already work for most cases. From the changes I did, I know there might be some more rare cases when it doesn't work, but I wasn't able to figure out a case. Please test it out to see if we can find cases when it still doesn't work.

[mauvilsa]

Customization of add_argument would also make possible #301.