Message324295
Errors that are associated with a specific argument, such as a wrong 'type' do get usage from the appropriate subparser.
e.g.
In [164]: p.parse_args('--foo 1 cmd1 --bar x'.split())
usage: ipython3 cmd1 [-h] [--bar BAR]
ipython3 cmd1: error: argument --bar: invalid int value: 'x'
`required` tests also issue subparser specific usage; mutually exclusive tests probably do so as well.
But this unrecognized argument error is a bit less specific. In your example '-x a' and 'a -x' will both produce the same error message. The route by which the '-x' is put into the 'extras' list is different in the two cases, but in both it's the top 'parse_(known_)args' that determines whether to just return them, or raise an error. '-x a -x' will put 2 '-x' in the unrecognized list.
If you really need a subparser specific message it might be possible to do so by modifying, or subclassing the _SubParsersAction class, making it raise an error when there are 'extras' rather than returning them as 'unrecognized'. But that's not a backward compatible change. |
|
Date |
User |
Action |
Args |
2018-08-28 22:19:31 | paul.j3 | set | recipients:
+ paul.j3, siming85 |
2018-08-28 22:19:31 | paul.j3 | set | messageid: <1535494771.51.0.56676864532.issue34479@psf.upfronthosting.co.za> |
2018-08-28 22:19:31 | paul.j3 | link | issue34479 messages |
2018-08-28 22:19:31 | paul.j3 | create | |
|