Message231098
A notational point - you are adding a subparser, not an argument, to the subparsers action.
Why would a user want to use `help=argparse.SUPPRESS`, as opposed to simply omitting the `help` parameter? The effect would be the same as your patch.
Another possibility is to interpret this SUPPRESS as meaning, omit the subparser (and it's aliases?) from the choices list(s) as well. In other words, make this an entirely stealth choice.
usage: test [-h] {foo} ...
positional arguments:
{foo}
foo This is help for foo
...
'test bar -h' would still display a help for that subparser (unless given a `add_help=False` parameter).
I don't know how much work this stronger SUPPRESS would required, or whether such an interpretation would be intuitive to most users. There isn't a mechanism to omit a regular argument from the usage, so why should there be a mechanism for omitting a subparsers choice from usage?
With the weaker interpretation, this patch fills in a hole in the logic, but doesn't add any functionality (that I can think of). |
|
Date |
User |
Action |
Args |
2014-11-13 06:32:07 | paul.j3 | set | recipients:
+ paul.j3, Brett.Hannigan |
2014-11-13 06:32:07 | paul.j3 | set | messageid: <1415860327.78.0.806929274231.issue22848@psf.upfronthosting.co.za> |
2014-11-13 06:32:07 | paul.j3 | link | issue22848 messages |
2014-11-13 06:32:07 | paul.j3 | create | |
|