[issue42980] argparse: GNU-style help formatter
New submission from Will Noble : argparse allows GNU-style long options (with '=' in between the option and the value as opposed to a space): https://docs.python.org/3/library/argparse.html#option-value-syntax Call it pickiness, but I'd like to be able to print the help message in that format. Looking at the code, a simple refactor would be much cleaner than implementing my own custom help formatter and having to copy-paste a bunch of implementation details that are potentially subject to change in future releases. I'll submit a patch shortly. -- components: Library (Lib) messages: 385359 nosy: will priority: normal severity: normal status: open title: argparse: GNU-style help formatter type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Change by Will Noble : -- keywords: +patch pull_requests: +23098 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24275 ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Will Noble added the comment: The main contribution of my PR is simply factoring out _format_option_with_args as an overridable method. Note that this actually enables subclassing HelpFormatter to produce all the examples you presented above with 1-3 trivial lines of code, as opposed to overriding the entire _format_action_invocation which is 20 lines in the base class. If HelpFormatter had a stable internal structure (i.e. some sort of assurance that it's overridable methods were not subject to change), I wouldn't have bothered including an implementation of GnuStyleLongOptionsHelpFormatter in this PR, since I could just implement it downstream as-needed. However, I chose to push it upstream because a) it's trivial and non-invasive and b) it establishes a use-case of _format_option_with_args for posterity, just in case anybody came in later and saw such a trivial, "private" (underscore-prefixed) method and decided to inline it. This lack of perceived stability is alluded to in https://bugs.python.org/issue42966. My preferred solution would be to refactor HelpFormatter to have more overridable methods like this, make them non-"private", document them properly, and keep them relatively stable. In order to do that, we'd want to establish all the desired use-cases and be sure to craft the method structure in such a way that they're all supported. Since that would be a somewhat daunting design task and probably not high on the priority list atm, I think this small incremental improvement pushes things in the right direction; establishing a desirable use-case without committing to too many implementation details yet. -- ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Will Noble added the comment: Ya I was following the precedent of non-documentation figuring that formal documentation should be done for the entire class and that would be a much larger undertaking and maybe involve further refactoring. I could potentially undertake that task in the future but I think it's out-of-scope for this change. -- ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
