我认为你正在将这个冲突处理程序推入无意识和未经测试的领域.通常父母是不使用的独立解析器.它们只是Actions的来源.关于-h的冲突由add_help = False处理.
通过后台：使用默认的conflict_handler(错误),您在创建wrappercommand subparser时会收到错误消息：
argparse.ArgumentError: argument -h/–help: conflicting option string(s): -h, –help
添加一些add_help = False后,您仍然会得到：
argparse.ArgumentError: argument –config: conflicting option string(s): –config
解决冲突处理程序用某种“解决方案”替换错误消息.下面的脚本演示了正在发生的事情.
解析处理程序删除了子命令1操作的option_strings,同时保留了操作.实际上,它变成了位置.由于帮助有nargs = 0,它总是运行.因此,帮助显示.
_handle_conflict_resolve的意图是删除第一个参数的证据,因此可以添加新参数.当两个带有相同选项字符串的add_argument命令产生冲突时,这样可以正常工作.但在这里,冲突是由2个父母的“复制”行为产生的.但父母行为是通过引用复制的,因此“孩子”的变化最终会影响“父母”.
一些可能的解决方
>直接将参数添加到wrappercommand.这种父母机制只是将父母的观点添加到孩子身上.它没有按顺序“运行”父母.
>编写自己的_handle_conflict _…函数以正确解决冲突.
>删除冲突,以便您可以在不使用解析处理程序的情况下使用父级.
parent1 = argparse.ArgumentParser(add_help=False)
parent1.add_argument(‘–config’)
parent2 = argparse.ArgumentParser(add_help=False)
parent2.add_argument(‘–config’)
parser = argparse.ArgumentParser(parents=[parent1,parent2],
conflict_handler=’resolve’)
def foo(parser):
print [(id(a), a.dest, a.option_strings) for a in parser._actions]
foo(parent1)
foo(parent2)
foo(parser)
产生：
[(3077384012L, ‘config’, [])]
[(3076863628L, ‘config’, [‘–config’])]
[(3076864428L, ‘help’, [‘-h’, ‘–help’]), (3076863628L, ‘config’, [‘–config’])]
请注意,parent1缺少option_strings,而另一个2. parent1的匹配id不能再次用作父级或解析器.