Author paul.j3
Recipients bethard, gotgenes, jamadagni, micktwomey, paul.j3
Date 2014-02-28.23:04:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1393628685.74.0.968254538364.issue10984@psf.upfronthosting.co.za>
In-reply-to
Content
In http://bugs.python.org/issue11588 (Add "necessarily inclusive" groups to argparse) I propose a generalization to these testing groups that would solve your 'conflicter' case as follows:

    usage = 'prog [ --conflicter | [ --opt1 ] [ --opt2 ] ]'
    parser = argparse.ArgumentParser(usage=usage)
    conflicter = parser.add_argument("--conflicter", action='store_true')
    opt1 = parser.add_argument("--opt1", action='store_true')
    opt2 = parser.add_argument("--opt2", action='store_true')

    @parser.crosstest
    def test(parser, seen_actions, *args):
        if conflicter in seen_actions:
            if 0<len(seen_actions.intersection([opt1, opt2])):
                parser.error('--conflicter cannot be used with --opt1 or --opt2')

Groups, as currently defined, cannot handle nesting, and as a consequence cannot handle complex logic.  My proposal is to replace groups with user defined conflict tests that would be run near the end of 'parse_args'.  

This example shows, I think, that the proposal is powerful enough.  I'm not sure about ease of use and logical transparency.

Formatting the usage line is a different issue, though the MultiGroupHelpFormatter that I propose here is a step in the right direction.  For now a user written 'usage' is the simplest solution.
History
Date User Action Args
2014-02-28 23:04:45paul.j3setrecipients: + paul.j3, bethard, gotgenes, micktwomey, jamadagni
2014-02-28 23:04:45paul.j3setmessageid: <1393628685.74.0.968254538364.issue10984@psf.upfronthosting.co.za>
2014-02-28 23:04:45paul.j3linkissue10984 messages
2014-02-28 23:04:45paul.j3create