New submission from Tadek Kijkowski <tkijkow...@gmail.com>:

Current implementation of the argparse module doesn't make it easy for 
developers to customize the help text message format. On one hand the module 
doesn't provide any builtin ways to do it, and the only way is to provide 
developer's own formatter class, on the other hand developers are threatened, 
that all internal structures of the module, including API of the HelpFormatter 
class is subject to change. Trying to customize anything but the most basic 
things, developer risks that his or hers module will suddenly stop working with 
a new version of argparse.

For most basic customization there is a set of four alternative formatting 
classes, but their usage as well as development of additional formatting 
classes is hindered by following reasons:
- Only one formatting class can be used at a time. Although arguably devloper 
can safely derive his own formatter class from multiple argparse's formatters - 
if he or she will come up with this idea.
- At this moment there is no way to pass any configuration data to the 
formatter object, so each formatter class can only change one aspect of the 
output format.
- Any new functionality added to argparse help formatting has to take form of 
new formatter class. If it is significant change, it means duplicating parts of 
HelpFormatter code and in the future maintaining additional classes.
- Even if additional formatter classes are added to argparse, developers have 
make sure that the new class is present in the argparse used by their module - 
either add dependency to specific argparse version, or dynamically check for 
presence of the new class in argparse module.

The most important part of this enhancement request is change in argparse 
public API - addition of class CustomHelpFormat. Object of this class would 
serve as factory for CustomizableHelpFormatter objects and could be passed to 
ArgumentParser constructor in place of format class type:

custom_format = argparse.CustomHelpFormat()
custom_format.indent_increment = 4
custom_format.raw_description = True
parser = argparse.ArgumentParser(formatter_class=custom_format)

The idea of passing callable instead of class type as formatter_class argument 
is not new, but this time it would be part of official API with access to 
internal details and maintained along with the module.

In conrtast to the list of drawbacks above, the advantages of this solution are:
- It is much easier to do basic customization. Developers won't have to search 
the internet for information how to customize argparse output, when they just 
want to focus on their own application functionality.
- There is no need to check for presence of future additional help formatter in 
the argparse module. One just has to set appropriate attribute in the 
'custom_format' object. If required functionality is not present in the module 
on the system, it would be simply ignored, developer could even safely set 
attribute for future feature not present in released version.
- Detection of implemented feature would is much easier - developer would just 
call `hasattr(custom_format, "hybrid_text_formatter")` and modify displayed 
text accordingly in the absence of the requested feature.
- Development of new features should be easier - instead of creating new class 
for each possible aspect of customization, new features could be combined in 
one new class, or even added to the base HelpFormatter and just enabled by an 
attribute.

Altough this solution will not immediately help developers wanting to customize 
their argparse, the main idea is that it will unclog development of new 
formatters and incorporating existing propositions and possibly lessen or 
remove the need for client side customizations.

Initially, the new class would contain attributes corresponding to funcionality 
of existing alternative formatting classes as well as arguments to default 
HelpFormatter - indent, max help position and width.

Attached implementation of the CustomizableHelpFormatter class may seem 
rudimentary or hackish (or maybe not). Perhaps it should implement all 
appropriate methods instead of patching self.

----------
components: Library (Lib)
files: CustomizableHelpFormatter.txt
messages: 385263
nosy: monkeyman79
priority: normal
severity: normal
status: open
title: argpare: customizable help formatter
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49750/CustomizableHelpFormatter.txt

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42966>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to