[issue11354] argparse: nargs could accept range of options count

paul j3 added the comment: Post parsing testing for the correct number of strings is the easy part. It's the auto-generate usage that's harder to do right, especially if we wanted to enable the metavar tuple option. Clean usage for '+' is messy enough. --

[issue11354] argparse: nargs could accept range of options count

Alex Kanitz added the comment: Given that people were asking for real-world use cases, here's one: high-throughput sequencing, e.g., in RNA-Seq (https://en.wikipedia.org/wiki/RNA-Seq), typically yields either one or two output files, depending on the type of the sequencing library. As the

[issue11354] argparse: nargs could accept range of options count

Christoph Anton Mitterer added the comment: Next to code readability, there's IMO one could reason to properly support this would be a clean and easy way to get proper help strings for such options. Of course I can do something like: parser = argparse.ArgumentParser()

[issue11354] argparse: nargs could accept range of options count

Change by Raymond Hettinger : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue11354] argparse: nargs could accept range of options count

Alex added the comment: Weighing up how little demand there seems to be for this, and how easy it is to achieve the same effect with post-processing within a hypothetical script that happens to need it - I agree with closing it. -- ___ Python

[issue11354] argparse: nargs could accept range of options count

hai shi added the comment: Could we close some bpo with a long history? If some user need this feature in future we could reopen it. -- ___ Python tracker ___

[issue11354] argparse: nargs could accept range of options count

Raymond Hettinger added the comment: Do we have examples of real world APIs that actually need this functionality? Offhand, I don't recall having worked with any command-line tool that would accept "at least two but no more than four filenames" for example. Given that this isn't trivial to

[issue11354] argparse: nargs could accept range of options count

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11354] argparse: nargs could accept range of options count

Alex added the comment: I've had a look at the most recent patch and the code surrounding it, and I would be happy to take on the work to update the code and testing. However, > - It's easy to test for this range after parsing, with '*' or '+' nargs. So > the main thing this patch adds is

[issue11354] argparse: nargs could accept range of options count

paul j3 added the comment: A couple of quick observations: - this is one of the first patches that I worked on, so the details aren't fresh in my mind. A glance at my latest patch show that this isn't a trivial change. - nargs changes affect the input handling, the parsing, help and

[issue11354] argparse: nargs could accept range of options count

hai shi added the comment: I think the answer is 'yes'(It's over 8 years~). And tons of argparse'work need to be finished;) -- nosy: +shihai1991 ___ Python tracker ___

[issue11354] argparse: nargs could accept range of options count

alclarks added the comment: Hi, I'm a new contributor looking for issues to work on. This looks like a nice enhancement, would it be a good idea for me to update the patch and raise a pull request? -- nosy: +alclarks ___ Python tracker

[issue11354] argparse: nargs could accept range of options count

paul j3 added the comment: With a minor tweak to `argparse._is_mnrep()`, `nargs='{3}'` would also work. This means the same as `nargs=3`, so it isn't needed. But it is consistent with the idea of accepting Regular Expression syntax where it makes sense. `nargs='{2,3}?'` also works, though

[issue11354] argparse: nargs could accept range of options count

paul j3 added the comment: I think this patch should build on http://bugs.python.org/issue9849, which seeks to improve the error checking for nargs. There, add_argument returns an ArgumentError if the nargs value is not a valid string, interger, or it there is mismatch between a tuple

[issue11354] argparse: nargs could accept range of options count

paul j3 added the comment: This patch adds this `nargs='{m,n}'` or `nargs=(m,n)` feature. It builds on the `better nargs error message` patch in http://bugs.python.org/msg187754 It includes an argparse.rst paragraph, changes to argparse.py, and additions to test_argparse.py. The tests

[issue11354] argparse: nargs could accept range of options count

paul j3 added the comment: Wouldn't it be simpler to use the re {m,n} notation to grab the appropriate number of arguments? In ArgumentParser _get_nargs_pattern we could add: +# n to m arguments, nargs is re like {n,m} +elif is_mnrep(nargs): +nargs_pattern =

[issue11354] argparse: nargs could accept range of options count

Steven Bethard steven.beth...@gmail.com added the comment: The tests look like they're testing the right things, but the tests should instead be written like the rest of the argparse tests. For example, look at TestOptionalsNargs3 and TestPositionalsNargs2. You could write your tests to look

[issue11354] argparse: nargs could accept range of options count

Alex Frase fr...@cs.wisc.edu added the comment: I'm new here so I apologize if this is considered poor etiquette, but I'm just commenting to 'bump' this issue. My search for a way to accomplish exactly this functionality led me here, and it seems a patch was offered but no action has been

[issue11354] argparse: nargs could accept range of options count

Wojciech Muła wojciech_m...@poczta.onet.pl added the comment: Steven, thank you for links, I prepared patch against trunk. All tests passed. -- Added file: http://bugs.python.org/file21617/issue11354.patch ___ Python tracker rep...@bugs.python.org

[issue11354] argparse: nargs could accept range of options count

Steven Bethard steven.beth...@gmail.com added the comment: Thanks for the patch. The idea and the approach of the patch look fine. But the patch needs to be against the Python repository: http://docs.python.org/devguide/patch.html#creating For the tests, you should integrate your test.py into

[issue11354] argparse: nargs could accept range of options count

Changes by Wojciech Muła wojciech_m...@poczta.onet.pl: Removed file: http://bugs.python.org/file20948/test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11354 ___

[issue11354] argparse: nargs could accept range of options count

Wojciech Muła wojciech_m...@poczta.onet.pl added the comment: Daniel, thanks for note, fixed. -- Added file: http://bugs.python.org/file20981/test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11354

[issue11354] argparse: nargs could accept range of options count

Changes by SilentGhost ghost@gmail.com: -- nosy: +bethard ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11354 ___ ___ Python-bugs-list mailing

[issue11354] argparse: nargs could accept range of options count

Daniel Haertle haer...@uni-bonn.de added the comment: Hi Wojciech, in your tests, at def test_add_argument10(self): nargs = (0, 1) = optimized to '?' opt = self.add_argument(1, None) self.assertEqual(opt.nargs, argparse.ONE_OR_MORE) you should change

[issue11354] argparse: nargs could accept range of options count

New submission from Wojciech Muła wojciech_m...@poczta.onet.pl: Hi, sometimes it is needed to grab variable, but limited, number of options. For example --point could accept 2, 3 or 4 values: (x,y) or (x,y,z) or (x,y,z,w). Current version of argparse requires postprocessing:

[issue11354] argparse: nargs could accept range of options count

Wojciech Muła wojciech_m...@poczta.onet.pl added the comment: tests -- Added file: http://bugs.python.org/file20948/test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11354 ___