Author forest
Recipients forest, jkloth, paul.j3, rhettinger
Date 2021-09-06.05:49:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <qoabjg1man8p6fm4ukorgah9jcimv204qs@4ax.com>
In-reply-to <1630904318.83.0.19457001248.issue45110@roundup.psfhosted.org>
Content
On Mon, 06 Sep 2021 04:58:38 +0000, paul j3 wrote:

>This repeat has been a part of argparse from the beginning, so I can't
>see changing the default behavior.

Yes, I guessed as much, which is why I first suggested making it optional.

>But we could add a HelpFormatter subclass that changes one (or two methods)
>such as _format_action_invocation.  Subclassing the formatter is the accepted
>way of adding help features.

If it was done in a subclass, how would people be expected to get the new
behavior *and* that of the other subclasses?  For example, someone with
pre-formatted description and epilog text is currently directed to use the
RawDescriptionHelpFormatter subclass.  If they also wanted to avoid repeat
metavars, and that behavior was implemented in another subclass, would they
be expected to write a third subclass inheriting from both module-defined
subclasses?

To me, multiclassing seems rather heavyweight for a simple behavior change
like this one, but yes, I recognize that argparse's current code uses that
approach.  Pity, that.

>Of course people can use such a subclass without it being part of the
>standard module.

Technically: sure. But practically: not so much.  An application would have
to subclass and override _format_action_invocation(), which (judging by the
leading underscore) appears to be intended as private to the module.  Even
the module doc string says so:

"""
(Also note that HelpFormatter and RawDescriptionHelpFormatter are only
considered public as object names -- the API of the formatter objects is
still considered an implementation detail.)
"""

So, a subclass that isn't part of the standard module is implicity and
explicitly discouraged by the module itself.

If we're married to the module's current policy for formatter tweaks, I
guess that leaves a module-defined subclass as the only option.  Here is
an example that works:

class OneMetavarHelpFormatter(argparse.HelpFormatter):
    """A formatter that avoids repeating action argument metavars.
    """
    def _format_action_invocation(self, action):
        "Format action help without repeating the argument metavar"
        if not action.option_strings or action.nargs == 0:
            return super()._format_action_invocation(action)

        default = self._get_default_metavar_for_optional(action)
        args_string = self._format_args(action, default)
        return ', '.join(action.option_strings) + ' ' + args_string
History
Date User Action Args
2021-09-06 05:49:31forestsetrecipients: + forest, rhettinger, jkloth, paul.j3
2021-09-06 05:49:31forestlinkissue45110 messages
2021-09-06 05:49:31forestcreate