This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.j3
Recipients Brett.Hannigan, paul.j3
Date 2014-11-13.06:32:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1415860327.78.0.806929274231.issue22848@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2014-11-13 06:32:07paul.j3setrecipients: + paul.j3, Brett.Hannigan
2014-11-13 06:32:07paul.j3setmessageid: <1415860327.78.0.806929274231.issue22848@psf.upfronthosting.co.za>
2014-11-13 06:32:07paul.j3linkissue22848 messages
2014-11-13 06:32:07paul.j3create