On Wed, Feb 24, 2021 at 1:38 PM Paul Korir <polaris...@gmail.com> wrote:
> I've been using the argparse library for a long time and one use case that
> repeatedly shows us is the need to have two arguments appear together i.e
> either both appear or none of them appear. I'll refer to these as *mutually
> inclusive* in contrast to the existing *mutual exclusive* feature present.
> I might be wrong but there seems to be no way to enforce this.
>
I'm of mixed feelings about this. I can absolutely see that it can be
useful, and many tools will have this kind of argument requirement. On the
other hand, as soon as you mention this pattern, I can think of a number of
others that could be useful (and not implausible) that will remain
unavailable. So it's a trade-off about how much is done in argparse
configuration itself, versus how much is done in manual validation of
arguments. Right now, of course, I can write a manual check:
if (args.foo and not args.bar) or (args.bar and not args.foo):
parser.error("Args foo and bar must occur together")
I don't care whether this checking is done with the future match/case
construct versus current if/elif style. Obviously, there are possible ways
that extra arguments to .add_argument() could describe that check, if such
were added.
But let us think of other possible patterns. What if we need "at least 2
of these 5 arguments"? I can conceive of ways to add more parameters to
.add_arguments() to cover that, but it's not obvious that would be
worthwhile. There will probably remain situations where a manual
post-validation will be needed. I'm not sure that "mutually inclusive"
shouldn't remain as such.
Now a personal confession. I'm far too lax about argument requirements in
what I write; my audience is either myself or fellow developers. Pretty
much I just rely on "you should use this tool correctly. So if
hypothetically, the real usage of my tool is:
mytool ((-foo & -bar) | (-baz & -bam))
I'll probably just make them all optional and just fail downstream (usually
with some message to STDERR, but not in the argument parsing itself). If
my tool were widely used by non-developers or semi-developers, more rigor
would be desirable.
--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZW6YJHOLEP4XUWMER236ZVU54JY3ZAM7/
Code of Conduct: http://python.org/psf/codeofconduct/
