-
-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[argparse] Bad error message formatting when using custom usage text #86463
Comments
In the sos project, we build a custom For example if a bad option value is given, the error message is mangled into the last line of our usage string:
This is especially strange since we build the usage string with a trailing newline character:
So it appears the trailing newlines are being stripped (in our case, unintentionally?). As expected, removing the trailing newline when passing However, if we don't set the usage string at all when instantiating our parser, the error message is properly formatted beginning on a new line. Slightly interesting is that without the usage_string being passed, the error message is prefixed with "sos: report:" as expected for %(prog)s expansion, but when the error message is mangled A little more context is available here: sosreport/sos#2285 |
Provide a minimal reproducible example. I can't reproduce that run on error message. Also test with arguments like '--all-logs on', which issues an 'unrecognizeable argument' error (with a different error reporting path). Stripping excess newlines is normal, both in the full help and error. That's done at the end of help formatting. |
I'll try and get a simple reproducer made shortly, however as a quick note I've found that using '--all-logs on' results in a properly formatted error message. |
Ah, ok - so I neglected to mention we're using subparsers which appears to be relevant here. My apologies. Here's a minimal reproducer that shows the behavior when using './arg_test.py foo --bar=on'
|
It's the subparser that's producing this error, specifically its 'prog' attribute. If I use a custom usage with a simple parser:
Notice that the error line includes the 'prog'. With subparsers, the main usage is included in the subcommand prog: print(subcmd_parser.prog) produces:
That's the usage plus the subcommand name, 'foo'. Generating the explicit error in the subcommand:
'bpo-42297.py: ' has been replaced by the usage+'foo', and no newline. We don't see this in the 'unrecognized' case because that error issued by the main parser.
If I explicitly set the prog of the subcommand: subcmd_parser = subparser.add_parser('foo', prog='myscript foo') The error becomes:
I can also add 'usage=usage_string' to the add_parser. For the most part add_parser takes the same parameters as ArgumentParser. Alternatively we can specify prog in subparser = parser.add_subparsers(dest='subcmd', metavar='subcmd', prog='myscript') resulting in:
I recently explored how 'prog' is set with subparsers in https://bugs.python.org/issue41980 I don't think anything needs to be corrected in argparse. There are enough options for setting prog and usage in subcommands to get around this issue. In the worse case, you might want to create an alternative
Action subclass that defines the prog/usage differently. |
Ok, yeah there seem to be several paths to avoid this behavior then. We should be fine exploring those options. Thanks for the pointer! |
We could look into using a different more compact 'prog' for these error messages. Currently the subparser 'prog' uses the main prog plus positionals plus the subparser name. The goal is to construct a subparser usage that reflects required input. This is fine for the usage line, but could be too verbose for some errors. In an error, the 'prog' just helps identify which argument has problems, and doesn't need the extra usage information. Most of the time that isn't an issue, since we don't use positional much in the main parser (and when used can't have variable nargs). But I don't have immediate ideas as to what can be conveniently (and safely) changed. |
# prog defaults to the usage message of this parser, skipping
# optional arguments and with no "usage:" prefix
if kwargs.get('prog') is None:
formatter = self._get_formatter()
positionals = self._get_positional_actions()
groups = self._mutually_exclusive_groups
formatter.add_usage(self.usage, positionals, groups, '')
kwargs['prog'] = formatter.format_help().strip() This code only makes sense if the custom usage is None. Then automatically generated message includes prog and names of positional arguments preceding subparsers. The custom usage replaces the full usage line. If it is close to the generated usage, it includes options, a set of all subparser names, "..." for subparser arguments. E.g. I think that using full custom usage instead of specially formatted partial usage string is wrong. What should we use instead? I think that falling back to the generated usage would be wrong too -- there is a reason why the custom usage was specified at first place. Then we can just set _prog_prefix to None and use subparser's name as its prog. It will produce less ugly result. |
…e parent parser The placeholder '...' is now used as the prog prefix in subparsers if a custom usage is specified in the parent parser and prog is not specified in the subparser. Previously the full custom usage of the parent parser was used as the prog prefix in subparsers.
#124532 makes |
…e main parser The usage parameter of argparse.ArgumentParser no longer affects the default value of the prog parameter in subparsers. Previously the full custom usage of the main parser was used as the prog prefix in subparsers.
On other hand, using the generated prog prefix as if the custom usage was not specified looks not bad. #125891 ignores custom usage when generating the default prog prefix. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: