Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
indigoviolet opened this issue Aug 19, 2023 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@indigoviolet
Copy link

馃殌 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

@indigoviolet indigoviolet added the enhancement New feature or request label Aug 19, 2023
@mauvilsa
Copy link
Member

mauvilsa commented Aug 25, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants