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: Provide equivalent of optparse.OptionParser.{option_groups,option_list,get_option} #67348
Comments
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 bpo-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...). |
The attached file subclasses ArgumentParser, explores how these optparse methods might be added to argparse. The __name__ section demonstrates how they might be used. argparse differs from optparse in a number of ways:
------------------- The idea of coordinating config sections with parser argument groups is interesting, but I question whether the stock argparser should be modified to facilitate this. It sounds like something that belongs in a custom subclass. Ipython populates its argparse parser with arguments derived from config files. This provides multiple config levels - default, custom file, and calling arguments. I don't recall whether it makes any use of argument groups. |
@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. |
So, this bug report could be closed, right? |
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. |
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:
The text was updated successfully, but these errors were encountered: