argparse nargs should support string wrapped integers too

[shubham1172]

BPO	32474
Nosy	@ericvsmith, @stevendaprano, @bitdancer, @asvetlov, @shubham1172
PRs	#32474 nargs enhancement #5070 bpo-32474: nargs enhancement #5075

^{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:

assignee = None
closed_at = <Date 2018-01-01.21:27:22.482>
created_at = <Date 2018-01-01.06:47:30.131>
labels = ['3.7', 'type-feature', 'library']
title = 'argparse nargs should support string wrapped integers too'
updated_at = <Date 2018-01-09.07:00:18.153>
user = 'https://github.com/shubham1172'

bugs.python.org fields:

activity = <Date 2018-01-09.07:00:18.153>
actor = 'paul.j3'
assignee = 'none'
closed = True
closed_date = <Date 2018-01-01.21:27:22.482>
closer = 'r.david.murray'
components = ['Library (Lib)']
creation = <Date 2018-01-01.06:47:30.131>
creator = 'shubham1172'
dependencies = []
files = []
hgrepos = []
issue_num = 32474
keywords = ['patch']
message_count = 10.0
messages = ['309322', '309323', '309324', '309325', '309326', '309327', '309331', '309345', '309350', '309686']
nosy_count = 6.0
nosy_names = ['eric.smith', 'steven.daprano', 'r.david.murray', 'asvetlov', 'paul.j3', 'shubham1172']
pr_nums = ['5070', '5075']
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue32474'
versions = ['Python 3.7']

[stevendaprano]

What do you mean by "string wrapped integers", and how should it support them?

[shubham1172]

Values like "1", "2", "3", should be supported.

[shubham1172]

A simple int(nargs) would be sufficient. I am getting ready with a PR in some time.

[stevendaprano]

Values like "1", "2", "3", should be supported.

You mean you want to call parser.add_argument('--foo', nargs="2")
instead of parser.add_argument('--foo', nargs=2)?

Why?

[bitdancer]

Why? What's the motivation for supporting this? There's no reason that I can think of, so I'm curious what your use case is.

[shubham1172]

nargs can take various values like "*", "+", etc. but doesn't support integers which are wrapped around in strings. Say, I want to take a user input for the nargs value (just a hypothetical situation); now I'll have to check additionally whether there's a numeric value inside the input char and then cast it to integer manually. An enhancement like this would eliminate this hassle and support for these will be helpful.

[ericvsmith]

Fixed possible versions.

I’m firmly -1 on this. It’s not at all common, and would allow code to pass that I’d prefer to cause an error. For the rare case where it’s desired, it can be moved in to the client code.

If I were doing this in client code, I’d try to convert to an int, and if an exception use the string version. It’s only a few lines of code:

try:
    val = int(val)
except ValueError:
    pass

(I think it’s a ValueError, but I’m on my phone and can’t easily verify.)

[asvetlov]

-1

[bitdancer]

Agreed. I don't think there is sufficient motivation for doing this, and there are downsides as Eric has pointed out. Rejecting.

[paulj3]

In https://bugs.python.org/issue11354

'argparse: nargs could accept range of options count'

I explored the option allowing regex style range arguments, such as nargs='{2,4}' or an equivalent tuple nargs=(2,4).

But that builds on https://bugs.python.org/issue9849, which seeks better error checking of the nargs parameter. In the current implementation, there is no checking or parsing of the value. The full range of allowable values is determined by its use in 2 methods:

_get_nargs_pattern
_format_args