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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
argparse should support multiple types when nargs > 1 #82398
Comments
argparse supports consuming multiple command-line arguments with nargs=2, etc. It converts them to the type given in the argument's type parameter. argparse does not provide a good solution when the input arguments should be different data types. For an example, you cannot have an argument that expects a str followed by an int, '--set-age Bob 34'. Ordinarily, the suggestion would be to split it into two arguments, like '--set-person Bob --set-age 34'. However, this becomes awkward with an action such as 'append', where the command line arguments become tedious, like '--set-person Bob --set-age 34 --set-person Alice --set-age 29', or confusing, as in '--set-person Bob --set-person Alice --set-age 34 --set-age 29'. My proposal is to allow the 'type' parameter to accept a tuple of types: p.add_argument('--set-age', nargs=2, type=(str, int)) Since 'nargs' is redundant, this could even be simplified to just: p.add_argument('--set-age', type=(str, int)) The resulting parsed argument would then be a tuple of (str, int), as opposed to a list. If action='append', the result would be a list of such tuples. This creates no backwards compatibility issue because tuple instances are not callable, so this was never valid code that did something else. A further enhancement could be that when nargs='+' or '*', and a tuple of types is provided, the types are used round robin: '--set-ages Bob 34 Alice 29'. An exception would be raised if it would create an incomplete tuple. See here for other discussion and workarounds: https://stackoverflow.com/questions/16959101/python-argparse-how-to-have-nargs-2-with-type-str-and-type-int |
Which is more valuable to you, the string conversion, or the checking? What's wrong with doing the 'type check' in post parsing code? (MarSoft's answer in the SO link). To make a better case for this, I'd suggest writing your own fix. It doesn't need to be a polished push, but enough code to show that the change is relatively simple (preferably occurring in only one or two functions). |
I just ran into this exact use case. I would also appreciate this feature. |
I am running into this now as well and am in need of this feature. The fact that it is not supported already is kinda baffling. To get this same functionality I now need to write up code to process a configuration file, as I need to pass multiple configurations with lot of different data types. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: