使用conflict_handler覆盖argparse参数时与父解析器的异常交互问题

这类异常是argparse模块的内置实现缺陷，不属于使用方式疏漏：

• 参数状态污染的来源：argparse在处理parents参数继承时，不会对父解析器挂载的Action对象做深拷贝，而是直接持有原对象的引用。当子解析器通过conflict_handler='resolve'覆盖同名参数时，会直接修改原Action的内部属性，这个改动会同步传导到所有引用了该父解析器的其他解析器（包括主解析器）。
• 主解析器帮助异常的成因：子解析器覆盖参数时，旧的foo Action被从子解析器的参数列表移除、其内部的选项标识属性被清空，而主解析器因为共享引用，持有的正是这个被清空属性的旧Action，因此生成帮助信息时无法获取短/长选项标识，最终出现usage行空位、参数列表只显示帮助文本的异常。
• default值覆盖失效的成因：conflict_handler='resolve'的覆盖逻辑仅替换解析器参数列表中的Action对象，不会更新解析器独立存储的_defaults默认值字典。argparse解析参数时优先从该字典读取默认值，因此即使新Action的default属性设置正确，最终生效的默认值仍是旧Action遗留的配置。
• 原代码运行时行为看似匹配预期的表现，本质是共享对象被篡改后巧合触发了正确的分支逻辑，并非实现正常。

• 切断跨解析器的对象共享：不要把同一个父解析器实例直接传入主解析器和所有子解析器，改为通过工厂函数每次生成配置完全一致的全新父解析器实例，给主解析器、每个子解析器分配独立的父解析器对象和对应的Action实例，从根源上避免子解析器修改参数时污染主解析器状态。
• 手动同步覆盖后的默认值：在子解析器完成同名参数覆盖后，手动将新的默认值写入子解析器的_defaults字典，匹配新Action的配置，解决默认值不生效的问题。
• 修正后的可运行代码示例：

#!python3
import argparse

def get_base_parent():
    # 每次生成独立的父解析器，避免对象引用共享
    parent = argparse.ArgumentParser(add_help=False)
    parent.add_argument('-f', '--foo', action='store_true', help='Parent foo')
    return parent

# 主解析器使用独立的父实例
main_parser = argparse.ArgumentParser(parents=[get_base_parent()])
subparsers = main_parser.add_subparsers(title='sub parsers')

# 子解析器a使用独立的父实例
sub_a = subparsers.add_parser('a', parents=[get_base_parent()], conflict_handler='resolve')
sub_a.add_argument('-f', '--foo', default=False, action='store_false', help='disabled for a')
# 手动同步默认值到解析器的默认值字典
sub_a._defaults['foo'] = False

if __name__ == "__main__":
    print(main_parser.parse_args())

• 实现效果验证：
  • 主解析器的-h输出会正常展示-f/--foo的完整参数标识和帮助文本，usage行不再出现空位
  • 子解析器a的-h输出会明确展示覆盖后的disabled for a帮助提示，清晰说明该参数在当前子命令下被强制禁用
  • 参数解析行为完全符合预期：主解析器下不带-f时foo=False、带-f时foo=True；子命令a下无论是否传入-f，foo始终强制为False

内容的提问来源于stack exchange，提问作者OPPenguin