Author paul.j3
Recipients John.Didion, bethard, manveru, paul.j3, xuanji
Date 2014-02-14.21:26:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1392413219.96.0.705192962164.issue11588@psf.upfronthosting.co.za>
In-reply-to
Content
The suggestion in this issue is to add a 'mutually_inclusive_group' mechanism, one that would let users specify that certain sets of arguments must occur together.  Furthermore there was mention of allowing some sort of nesting.

Modeling it on the mutually_exclusive_group would be straight forward.  But should it affect the usage and help display?mutually_exclusive_groups add a messy layer to the usage formatting.

The only place such a group would act would be at the end of '_parse_known_args', where the current code checks for things like required actions (and mxgroups). A test at this point could use 'namespace', 'seen_actions' and 'seen_non_default_actions' to check whether the required group actions were seen.

But the only thing that the argument_group contributes to this test is a list of argument names ('dest'?).  Why not provide this list directly?  And what if the user wants A to occur together with either B or C, but not both?  Or make the inclusivity conditional on the value of A?

Currently users can define argument interactions in a couple of ways.  They can define custom Actions. In test_argparse.py there's a custom Actions test that does something like this (using '--spam' and 'badger').  But tests in Actions depend on the order in which arguments are given.

An alternative is to test for interactions of arguments after `parse_args`.  However the only information that the user has at this point is the args namespace.  Reliably distinguishing between non-occurrence of arguments and default values can be difficult.

I am proposing 'cross_test' mechanism that would give the user access to the 'seen_actions' and 'seen_non_default_actions' sets that 'mutually_exclusive_groups' use.  Specifically an optional function can be called at the end of '_parse_known_args' that has access to these sets as well as the parser and the namespace.

The core of the change would be adding

    cross_test = getattr(self, 'cross_test', None)
    if cross_test:
        cross_test(self, namespace, extras, seen_actions, seen_non_default_actions)

at the end of 'parser._parse_known_args'.  In addition 'cross_test' (or some other name) could be added to the 'ArgumentParser.__init__' arguments.

The feature could be used by defining such a 'cross_test' function and adding it to the parser (either instance or subclass)

    def foobar(self, namespace, extras, seen_actions, seen_non_default_actions):
        ...
        (raise self.error(...))

    parser.cross_test = foobar

The patch proposed http://bugs.python.org/issue18943 should be included
with any changes here since it refines the setting of 'seen_non_default_actions'.

I am working on tests and examples of such functionality.
History
Date User Action Args
2014-02-14 21:27:00paul.j3setrecipients: + paul.j3, bethard, xuanji, John.Didion, manveru
2014-02-14 21:26:59paul.j3setmessageid: <1392413219.96.0.705192962164.issue11588@psf.upfronthosting.co.za>
2014-02-14 21:26:59paul.j3linkissue11588 messages
2014-02-14 21:26:58paul.j3create