homepage

This is an example of using 'patch_w_mxg2.diff' to handle the inclusive group case proposed by the OP.
Since 'seen_non_default_actions' (and 'seen_actions') is a set of 'Actions', it is convenient to use 'set' methods with pointers to the actions that a collected during setup. Tests could also be done with the 'dest' or other action attributes.
In this example I wrote 3 simple tests corresponding to the 3 proposed groups, but they could also have been written as one test.
 a_file= parser.add_argument("-o", "--outfile", metavar='FILE')
 a_dir = parser.add_argument("-O", "--outdir", metavar='DIR')
 a_pat = parser.add_argument("-p", "--outpattern", metavar='PATTERN')
 a_suf = parser.add_argument("-s", "--outsuffix", metavar='SUFFIX')
 ...
 def dir_inclusive(parser, seen_actions, *args):
 if a_dir in seen_actions:
 if 0==len(seen_actions.intersection([a_pat, a_suf])):
 parser.error('DIR requires PATTERN or SUFFIX')
 parser.register('cross_tests', 'dir_inclusive', dir_inclusive)
 ...
In theory tests like this could be generated from groups as proposed by the OP. There is one case in 'test_argparse.py' where a mutually_exclusive_group is nested in an argument_group. But the current groups do not implement nesting. A (plain) argument_group does not share its '_group_actions' list with its 'container'. A mutually_exclusive_group shares its '_group_actions' but the result is a flat list (no nesting).
For now I think it is more useful to give users tools to write custom 'cross_tests' than to generalize the 'group' classes.