The following code:

   import argparse
   parser = argparse.ArgumentParser()
   group1 = parser.add_mutually_exclusive_group()
   group2 = group1.add_mutually_exclusive_group()
   group2.add_argument('-hello',action='store_true', help="A flag")
   args = parser.parse_args()

produces this output:

   skerr@gravel:~$ python bug.py -h
   usage: bug.py [-h] [[-hello]

   optional arguments:
        -h, --help  show this help message and exit
        -hello      A flag
   skerr@gravel:~$ 

Note the double [[ around hello, but there is no double ]] to close it. This is the error.

That's an artifact of how the group usage is formatted (which isn't very robust).  It's not designed to handle nested groups.  

Mutually exclusive groups aren't meant to nest inside other mutually exclusive groups.  While it possible, it doesn't help you.  Effectively the arguments combined into one larger group.

See http://bugs.python.org/issue11588 for discussion on how nested groups might be implemented, and the difficulties in properly formatting their usage.

http://bugs.python.org/issue10984 has a more robust mutually exclusive group formatter, but even that is not designed for nesting.

On further thought, I think

   group2 = group1.add_mutually_exclusive_group()

should have raised an error, stating that a group (argument or mutually exclusive) cannot be added to a mutually exclusive group.

Also an argument group should not be added to another argument group.

However, adding a mutually exclusive group to an argument group is ok, though only for the undocumented (though tested) purpose of giving it a title.

What I was going for was the ability to have a group contain a mutually exclusive group and a non-exclusive group, but using the mutually exclusive group meant you could not use the non-exclusive group.

Such as:

[ [ -opt1 | -opt2 | -opt3   ] [ [-opt4] [-opt5] [-opt6] ] ]

I fat fingered the example, sorry:

[ [ -opt1 | -opt2 | -opt3   ] | [ [-opt4] [-opt5] [-opt6] ] ]

Note the new pipe between the 2 subgroups

Here's a preliminary patch that raises an error if there's an attempt to nest a mutually exclusive group in another, or there's an attempt to add an argument group to either kind of group.

It still needs test_argparse.py and argparse.rst changes

I'm raising a ValueError, since that is what most of the other add_argument errors do.  An alternative is a NotImplementedError, since that is, in effect, what I am doing, blocking the implementation of particular 'add' methods.

An alternative to adding this patch as high priority bug issue, is to include it in the UsageGroup patch (11588) which will implement nestable groups.

ArgumentGroups and MutuallyExclusiveGroups, as currently defined, won't give you that kind of usage.  I have appended a script that uses UsageGroups, which I am developing for http://bugs.python.org/issue11588, 
to solve this.

It defines 2 'mxg' groups (groups with the xor logic of mutually exclusive groups), and 1 'any' group.  They can be nested.

The resulting usage line is:

    usage: PROG [-h] [[--opt1 | --opt2 | --opt3] | [--opt4 --opt5 --opt6]]

Normally '|' is used for simple logical 'or'.  But in mutually exclusive groups it denotes 'xor'.  So what should join 'any' lists?  You chose ' ', I was using ','.  Defining a usage notation that is simple, intuitive, and also flexible, is not easy.

This patch adds a 

    class TestMutuallyExclusiveGroupErrors
        test_invalid_add_group() test,

closely modeled on

        test_invalid_add_argument()

I'm using ValueError in group add methods (maintaining the similarity with add_argument errors).

I haven't changed the documentation.  add_argument_group and add_mutually_exclusive_group methods are described as belonging to an ArgumentParser, and the examples are consistent with that. An admonition against nesting groups would not fit with the current flow.

However to be accurate, these methods belong to _ActionsContainer, the parent class for both the parser and groups.  The documentation glosses over this detail.  So an alternative way of addressing this issue is to move these 2 methods to the ArgumentParser class.

A similar issue about nesting an Argument Group inside a Mutually Exclusive Group.

http://bugs.python.org/issue24736

I am unable to reproduce this on 3.11:

% ./python.exe tt.py -h
usage: tt.py [-h] [[-hello]]

options:
  -h, --help  show this help message and exit
  -hello      A flag

While I was unable to reproduce this rendering error, there are other issues due to nesting of argument groups, and I wonder if we should deprecate those operations, along the lines of Paul's patch on this issue (but with deprecation rather than raising an exception).

Other related issues:  issue46057 (from today), issue16807, issue45690, issue43259, (there are probably more).

I am repurposing this issue for the deprecation of nesting. It is pretty clear that the functions exist by accident through inheritance. They are not documented and from the number of open issues about them they clearly are not working as people expect them to.

Another issue due to nesting: issue38590.

New changeset 30322c497e0b8d978f7a0de95985aac9c5daf1ac by Irit Katriel in branch 'main':
bpo-22047: [argparse] deprecate nested argument groups and mutually exclusive groups (GH-30098)
https://github.com/python/cpython/commit/30322c497e0b8d978f7a0de95985aac9c5daf1ac

Hi, according to the group update the _MutuallyExclusiveGroup should have an add_argument_group() call with the deprecation warning, but that method is missing in commit 30322c497e0b8d978f7a0de95985aac9c5daf1ac.

_MutuallyExclusiveGroup inherits add_argument_group from _ArgumentGroup.