This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.j3
Recipients calestyo, paul.j3, rhettinger
Date 2021-02-22.05:30:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I've added a script that does what you want, but with a simple utility function instead of a parent (or lots of copy-n-paste).


I explored the code a bit, and have an idea that might correct the [parent] behavior.

In the method that copies a parent's groups and actions

     def _add_container_actions(self, container):

It might be enough to change

        for group in container._mutually_exclusive_groups:
            mutex_group = self.add_mutually_exclusive_group(


        for group in container._mutually_exclusive_groups:
            pgroup = group._container
            mutex_group = pgroup.add_mutually_exclusive_group(

The mutually group records where it was create in its '._container' attribute.  Usually that would a parser, but in your example would the 'inputs' action group.  

I haven't tested this idea.


In (request for inclusive groups), I explored adding a Usage_Group class that could nest.  That project become too large, especially when considering help formatting.  And I did not give any thought to dealing with parents there.


Another issue involving parents (and the potential problems caused by copy-by-reference). 
argparse: 'resolve' conflict handler damages the actions of the parent parser


Belatedly I look for other issues involving 'parent', and found these duplicates
argparse help error: arguments created by add_mutually_exclusive_group() are shown outside their parent group created by add_argument_group()
argparse group nesting lost on inheritance
Date User Action Args
2021-02-22 05:30:13paul.j3setrecipients: + paul.j3, rhettinger, calestyo
2021-02-22 05:30:13paul.j3setmessageid: <>
2021-02-22 05:30:13paul.j3linkissue43259 messages
2021-02-22 05:30:13paul.j3create