Python argparse has a limitation on argument groups that makes me sad | Hacker News Reader

Python argparse has a limitation on argument groups that makes me sad

utcc.utoronto.ca

29 pointszdw16 comments

Is there a standard python library that does annotate if an argument is user provided or instead (just) the default value?

This is extremely important for configuration priority. Program defaults (generally) should be the lowest priority level. Superseded by configuration files. Superseded by command-line arguments. Finally replaced by configuration changes during runtime. Notably each is (in theory) specified in a more specific context as well as more recently.

I think this is doable but as an X vs Y problem. You can either not have a default and check if it's in the namespace later, or make the default value be the previously highest priority value as a run-time defined default. Do either of those work?

It would be nice if --help reports the (program) default as the default value for an option. A different option might dump a fully evaluated configuration. While a third might exit without doing anything.

if you pass formatter_class=argparse.ArgumentDefaultsHelpFormatter) you will get exactly that.

shameless copy from https://stackoverflow.com/questions/12151306/argparse-way-to...

This can be done using click.

Not with multiple=True, since it then always returns an empty list and never None, even if the default is None.

Yes it can. click.Context provides a get_parameter_source method that should help with that.

Thank you! I recently got bitten by this limitation and will make use of get_parameter_source. I gave you credit/mentioned in the issue to restore our use of `multiple=True` behavior: https://github.com/gptme/gptme/issues/560

So the author wants a configuration, where I can either run the program with

--foo-timeout=5 --bar-timeout=10

or with

--no-timeouts

which disables the timeouts for both too and bar.

I don't know the author's entire usecase, but it seems odd that you would specifically NOT want the user to only disable one timeout, but keep all the others active.

Unless there is a real reason for this, the more logical design for me would be to treat --foo-timeout=0 or something as the setting to disable timeout foo.

Not sure if argparse supports aliases, but if it does, --no-timeouts could then be defined as an alias for "--foo-timeout=0 --bar-timeout=0 --baz-timeout=0" etc etc.

They probably mean a combination like: I want the program to time out if the server response isn't done after 60 seconds I want the program to time out if the the last byte from the server is more than 10 seconds ago.

It doesn't make sense to say I want one of these timeouts and --no-timeout

Can't you just generate all the groups by having a function the created a set of each individual timeout (--notimeout,--timeout-x) to pass to the parser?

I wondered this as well. I must admit I’ve not yet written a command line tool (in Python) where I’ve needed what the author describes, but I did wonder if adding multiple exclusive groups with --notimeout as a member of all of the groups would do the trick. Perhaps you get an error or get into undefined behaviour territory but it would certainly be worth trying.

I mean, he does have a point, but his point has a solution: do not put them in mutually exclusive groups if they aren't mutually exclusive.

It seems more like this is a missing feature rather than an issue with mutually exclusive, if the desire is that `argparse` handles this in an elegant, internal way.

So, yes, `argparse` has a limitation on argument groups, but `add_mutually_exclusive_group` is not the issue.

The gcloud CLI handles this using argparse, having a parent mutex group with one child —no-timeout flag and then a child group containing the timeout flags.

But the docs say you can’t (or shouldn’t) add a child group because it’s not supported and will be removed…

True, it's annoying

Reply on news.ycombinator.com