New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate unsupported nesting of argparse groups #66246
Comments
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 optional arguments: 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, 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:
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
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. |
I am unable to reproduce this on 3.11: % ./python.exe tt.py -h options: |
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: bpo-46057 (from today), bpo-16807, bpo-45690, bpo-43259, (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: bpo-38590. |
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 30322c4. |
_MutuallyExclusiveGroup inherits add_argument_group from _ArgumentGroup. |
Hi @iritkatriel, based on your change 30322c4, it appears that it's still okay to call |
Yes, this combination is useful and it works, so it is supported. |
to avoid DeprecationWarning: Nesting argument groups is deprecated. python/cpython#66246
* Comment out added argument groups to avoid DeprecationWarning: Nesting argument groups is deprecated. python/cpython#66246 * Swap to TODOs and fix linecount
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: