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.
10 hours ago [-]
10 hours ago [-]
Neywiny 11 hours ago [-]
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?
mjevans 10 hours ago [-]
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.
dodslaser 11 hours ago [-]
This can be done using click.
ErikBjare 10 hours ago [-]
Not with multiple=True, since it then always returns an empty list and never None, even if the default is None.
xg15 9 hours ago [-]
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.
NoahZuniga 6 hours ago [-]
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
NewsaHackO 11 hours ago [-]
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?
bartread 11 hours ago [-]
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.
qwertox 11 hours ago [-]
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.
looknee 11 hours ago [-]
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.
what 10 hours ago [-]
But the docs say you can’t (or shouldn’t) add a child group because it’s not supported and will be removed…
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.
--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.
It doesn't make sense to say I want one of these timeouts and --no-timeout
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.