[issue23159] argparse: Provide equivalent of optparse.OptionParser.{option_groups, option_list, get_option}
Eric McDonald added the comment: Yes, this issue could be closed. I think the concept is still valid and perhaps worthy of future consideration as it is a means of unifying two different configuration processing mechanisms in the standard library without having developers reinvent that wheel every time. I'll close it, though, if having a "stale" issue floating around is bothersome. -- resolution: -> later stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue23159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23159] argparse: Provide equivalent of optparse.OptionParser.{option_groups, option_list, get_option}
New submission from Eric McDonald:
There are several use cases for having the equivalent of the
optparse.OptionParser 'get_option' method and the 'option_groups' and
'option_list' properties in argparse.ArgumentParser class.
(1) Easy alteration of the text of the default help option. With optparse, one
could write:
>>> oparser.get_option( "-h" ).help
'show this help message and exit'
>>> oparser.get_option( "-h" ).help = "Show this help message and exit."
>>> oparser.get_option( "-h" ).help
'Show this help message and exit.'
The equivalent facility does not appear to exist in argparse. (Issue #19462,
http://bugs.python.org/issue19462, is about a different use case. And, while
https://docs.python.org/3/library/argparse.html#add-help suggests a workaround
with add_help=False and then creating a new option with the 'help' action, it
is still less convenient than altering the existing help option.)
(2) Inspection of all the argument declarations in an ArgumentParser object
after it has been populated. This is particularly useful if you want to look
for the equivalent of the available options in config files and don't want to
have write explicit code which separately enumerates the available config file
keys and how to handle them. With an OptionParser, one could use the
'option_groups' attribute to find all option groups (to correspond to config
file sections) and the 'option_list' attribute to find all options (to
correspond to config file keys); these are all part of the published interface
and provide relatively simple data types to inspect. With an Argument Parser,
one needs to rely upon the unpublished interface (the '_actions' attribute of a
parser, etc...).
--
components: Library (Lib)
messages: 233394
nosy: emcd
priority: normal
severity: normal
status: open
title: argparse: Provide equivalent of
optparse.OptionParser.{option_groups,option_list,get_option}
type: enhancement
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue23159>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23159] argparse: Provide equivalent of optparse.OptionParser.{option_groups, option_list, get_option}
Eric McDonald added the comment: @paul.j3, thanks for the sample code for argparse extension. I agree that subclassing is a way to go for use in third-party projects. But, if someone ever wanted to add an abstraction layer in front of argparse.ArgumentParser and configparser.ConfigParser in the standard library, then modification of the argparse module might be more convenient. However, in the intervening months since I originally filed this ticket, I ended up exploring an alternative to inspecting populated argparse.ArgumentParser instances for this use case (parser abstraction layer). The module I ended up writing is more of a framework in that it lets you supply argument and config parsers and then populate them via a common interface. While this design is perhaps higher maintenance, I think that it gives more flexibility and control than inspecting already-populated parsers. So, from my perspective, I no longer consider this use case to be a compelling reason for adding more optparse-like behavior to argparse. (If there interest in the little framework that I wrote, I can share my code and take the discussion to an appropriate mailing list.) Again, thanks for taking the time to write the argparse_extended.py code. -- ___ Python tracker <http://bugs.python.org/issue23159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
