| msg309322 - (view) |
Author: Steven D'Aprano (steven.daprano) *  |
Date: 2018-01-01 07:02 |
| What do you mean by "string wrapped integers", and how should it support them? |
|
|
| msg309323 - (view) |
Author: Shubham Sharma (shubham1172) * |
Date: 2018-01-01 07:10 |
| Values like "1", "2", "3", should be supported. |
|
|
| msg309324 - (view) |
Author: Shubham Sharma (shubham1172) * |
Date: 2018-01-01 07:11 |
| A simple int(nargs) would be sufficient. I am getting ready with a PR in some time. |
|
|
| msg309325 - (view) |
Author: Steven D'Aprano (steven.daprano) * |
Date: 2018-01-01 07:19 |
| > 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? |
|
|
| msg309326 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2018-01-01 07:22 |
| 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. |
|
|
| msg309327 - (view) |
Author: Shubham Sharma (shubham1172) * |
Date: 2018-01-01 07:34 |
| 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. |
|
|
| msg309331 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2018-01-01 14:33 |
| 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.) |
|
|
| msg309345 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2018-01-01 19:49 |
| -1 |
|
|
| msg309350 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2018-01-01 21:27 |
| Agreed. I don't think there is sufficient motivation for doing this, and there are downsides as Eric has pointed out. Rejecting. |
|
|
| msg309686 - (view) |
Author: paul j3 (paul.j3) *  |
Date: 2018-01-09 07:00 |
| 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 |
|
|