[HN Gopher] Python argparse has a limitation on argument groups ...
___________________________________________________________________
Python argparse has a limitation on argument groups that makes me
sad
Author : zdw
Score : 22 points
Date : 2025-06-11 16:38 UTC (3 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| lordkrandel wrote:
| True, it's annoying
| mjevans wrote:
| 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.
| Neywiny wrote:
| 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 wrote:
| 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 wrote:
| This can be done using click.
| ErikBjare wrote:
| Not with multiple=True, since it then always returns an empty
| list and never None, even if the default is None.
| NewsaHackO wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| But the docs say you can't (or shouldn't) add a child group
| because it's not supported and will be removed...
| xg15 wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-14 23:02 UTC)