paul j3 added the comment:
Another way to add an existing Action to a group is to modify the
'add_argument' method for the Group subclass. For example we could add this to
the _MutuallyExclusiveGroup class:
def add_argument(self, *args, **kwargs):
# allow adding a prexisting
Changes by Shriramana Sharma samj...@gmail.com:
--
nosy: +jamadagni
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10984
___
___
Python-bugs-list
Shriramana Sharma added the comment:
I also wish to see argparse allowing me to define a group of arguments that
conflict with another argument or another group of arguments and FWIW I feel
the help output should be like:
prog [ --conflicter | [ --opt1 ] [ --opt2 ] ]
where --conflicter
paul j3 added the comment:
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 =
paul j3 added the comment:
Another situation in which this MultiGroupHelpFormatter helps is when one or
more of the groups includes an optional positional.
The regular formatter moves all the positionals to the end, after the
optionals. This move could easily break up a mutually exclusive
paul j3 added the comment:
A possible further tweak is, in take_action(), test for conflicts before adding
the action to 'seen_non_default_actions'
if argument_values is not action.default:
#seen_non_default_actions.add(action)
for conflict_action in
paul j3 added the comment:
This patch produces the same usage as before, but I have rewritten
_format_actions_usage() for both HelpFormatter and MultiGroupFormater.
The original HelpFormatter._format_actions_usage() formats the actions, splices
in group markings, cleans up the text, if
paul j3 added the comment:
This patch adds a MultiGroupHelpFormatter that formats groups even if they
share actions or the actions are not in the same order as in the parse._actions
list. It sorts the groups so positional actions, if any appear in the correct
order.
A long test case
paul j3 added the comment:
While playing with some examples, I found that exclusive group formatting has
another failure case. If the usage line is long enough to wrap, optionals and
positionals are formatted separately, with positionals appearing on a separate
line(s). That means that if a
paul j3 added the comment:
One usage option is to make a subclass of HelpFormatter (the accepted way of
customizing a formatter), and write a function that formats each group
independently. For the example case, the resulting format might be:
usage: PROG [-h] [-b] [-a | -c] [-a | -d]
-h
paul j3 added the comment:
This approach of simply adding the existing actions to the group's
_group_actions works fine, at least when it comes catching the error.
It may be difficult to get a useful usage line. In usage, arguments appear in
the order in which they were created, optionals
Michael Twomey added the comment:
I've picked up on this as part of the EP 2013 sprints.
I've attached a patch which implements the behaviour described in the comments.
It doesn't break any existing functionality but the help generated by argparse
is definitely not quite right.
--
Steven Bethard steven.beth...@gmail.com added the comment:
I'm definitely open to providing such functionality. I assume you're imagining
something like:
parser = argparse.ArgumentParser()
a_action = parser.add_argument('-a')
b_action = parser.add_argument('-b')
c_action =
New submission from Chris Lasher chris.las...@gmail.com:
argparse supports registering conflicting arguments, however, it does so in a
way that an argument may belong to at most one group of conflicting arguments.
The inspiration for this bug is Stack Overflow question #4770576.
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +bethard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10984
___
___
Python-bugs-list
15 matches
Mail list logo
