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 Laszlo.Attila.Toth, iritkatriel, paul.j3
Date 2022-01-10.19:30:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1641843034.68.0.643822860239.issue46057@roundup.psfhosted.org>
In-reply-to
Content
"I tried to create a group hierarchy in a way that I can pass the responsibility of argument validation to the argument parser." 

I looked at your example in:

https://bugs.python.org/issue46058

The many levels of nesting groups was confusing, but now I realize that by nesting argument_groups in a mutually_exlusive_group you were try to implement some sort of any/all group within the xor group.  

This cannot be done within argparse.  Mutually_exclusive only implements a flat xor.  Argument_groups are used for help display, but play no role in parsing.

Some years ago I explored the use of nest parsing groups:

https://bugs.python.org/issue11588
Add "necessarily inclusive" groups to argparse

I was trying to allow for nested groups that implemented all logical options - xor, or, and, not.  Defining such groups wasn't hard.  And I think I got the testing logic working right.  But usage display required too big of a change to the formatter, and left too many loose ends.  So I have let that languish.

Now I recommend focusing on doing the testing after parsing.  Use meaningful defaults where possible, and use `is None` to test whether a users has provided a value or not.
History
Date User Action Args
2022-01-10 19:30:34paul.j3setrecipients: + paul.j3, Laszlo.Attila.Toth, iritkatriel
2022-01-10 19:30:34paul.j3setmessageid: <1641843034.68.0.643822860239.issue46057@roundup.psfhosted.org>
2022-01-10 19:30:34paul.j3linkissue46057 messages
2022-01-10 19:30:34paul.j3create