René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Argparse: certain action types dont accept `metavar`, but should?","articleBody":"# Feature or enhancement\r\n\r\n### Proposal:\r\n\r\nGiven some arbitrary argument with a `dest` value of `foo.bar.baz` (justification below),  you will end up with helptext like `FOO.BAR.BAZ`. This is the explicit usecase for the use of `metavar`. You set `metavar` to the value you **want** it to show up as, and you're good.\r\n\r\nUnfortunately, you aren't allowed to supply `metavar` in some scenarios. I haven't enumerated all of them yet, but, for example, if you set `action='help'`, `action='store_true'`, or `action='store_false'`, you'll be routed through `_HelpAction`, `_StoreTrueAction`, or `_StoreFalseAction`, none of which accept a `metavar` argument. There may be more.\r\n\r\nThe superclasses of all three **do** accept metavar, but in usercode i can just subclass them like so:\r\n\r\n```python\r\nclass _HelpAction(argparse._HelpAction):\r\n    def __init__(self, metavar=None, **kwargs):\r\n        self.metavar = metavar\r\n        super().__init__(**kwargs)\r\n\r\n\r\nclass _StoreTrueAction(argparse._StoreTrueAction):\r\n    def __init__(self, metavar=None, **kwargs):\r\n        self.metavar = metavar\r\n        super().__init__(**kwargs)\r\n\r\n\r\nclass _StoreFalseAction(argparse._StoreFalseAction):\r\n    def __init__(self, metavar=None, **kwargs):\r\n        self.metavar = metavar\r\n        super().__init__(**kwargs)\r\n\r\nclass ArgumentParser(argparse.ArgumentParser):\r\n    def __init__(self, *args, **kwargs):\r\n        self.register(\"action\", \"store_true\", _StoreTrueAction)\r\n        self.register(\"action\", \"store_false\", _StoreFalseAction)\r\n```\r\n\r\nWith no other changes, the rendered helptext names of the options properly accept and render the `metavar` value instead of the `dest`.\r\n\r\n---\r\n\r\nSome context/justification for why this is meaningful. I am currently using this snippet from the internet to, with relatively little effort, \"properly\" parse multiply nested subparsers in a way that maintains the nested relationship of the input args when they're written:\r\n\r\n```python\r\nclass Nestedspace(argparse.Namespace):\r\n    def __setattr__(self, name, value):\r\n        if \".\" in name:\r\n            group, name = name.split(\".\", 1)\r\n            ns = getattr(self, group, Nestedspace())\r\n            setattr(ns, name, value)\r\n            self.__dict__[group] = ns\r\n        else:\r\n            self.__dict__[name] = value\r\n```\r\n\r\nWhich produces `{'foo': {'bar': {'baz': 4}}}` for some doubly nested subparser with a baz argument. Whereas it'd have just produced `{'baz': 4}` by \"default\".\r\n\r\nThis strategy requires setting the `dest` value to `foo.bar.baz` for the arg in question.\r\n\r\nHaving done that, you end up with `[-k FOO.BAR.BAZ]` in the help text, with no way to customize it.\r\n\r\n---\r\n\r\n### Has this already been discussed elsewhere?\r\n\r\nThis is a minor feature, which does not need previous discussion elsewhere\r\n\r\n### Links to previous discussion of this feature:\r\n\r\nI dont know whether this is relevant to issues like https://github.com/python/cpython/pull/103678, where they're removing metavar from not-these-classes-but-boolean-action-option, which naively seems related. perhaps it's unrelated though.\r\n\r\n---\r\n\r\nif it were just a matter of making the in-repo equivalents to these changes (plus tests), i'd be willing to contribue them, but i figured it might be this was for a reason, and wanted to make sure it'd be accepted before submitting a PR","author":{"url":"https://github.com/DanCardin","@type":"Person","name":"DanCardin"},"datePublished":"2023-09-23T18:39:31.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/109792/cpython/issues/109792"}