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
add_argument from argparse has a typeoption that "allows any necessary type-checking and type conversions to be performed". The ability to ensure the CLI args are converted to certain types helps ensure consistent CLI behavior and avoid bugs.
Since fire strives to be as automated as possible, it seems natural that it could inspect the type hints for the function signature that is being fired and cast the arguments to these types. If the arguments can't be converted to the type signature, an error would be raised to alert the CLI user to the invalid argument.
The types of the arguments are determined by their values, rather than by the function signature where they're used.
But the convenience of relying on type hints for argument type conversion would be major. It could be implemented in an opt-in manner for back compat. Would this idea ever be considered? Are there any CLI projects that are already doing this?
add_argument
fromargparse
has atype
option that "allows any necessary type-checking and type conversions to be performed". The ability to ensure the CLI args are converted to certain types helps ensure consistent CLI behavior and avoid bugs.Since fire strives to be as automated as possible, it seems natural that it could inspect the type hints for the function signature that is being fired and cast the arguments to these types. If the arguments can't be converted to the type signature, an error would be raised to alert the CLI user to the invalid argument.
The docs are clear that this is not the current design:
But the convenience of relying on type hints for argument type conversion would be major. It could be implemented in an opt-in manner for back compat. Would this idea ever be considered? Are there any CLI projects that are already doing this?
See also the related issue at #260.
The text was updated successfully, but these errors were encountered: