Opster: Pythonic option parsing(blogg.ingspree.net)
blogg.ingspree.net
Opster: Pythonic option parsing
http://blogg.ingspree.net/blog/2009/09/14/opster/
4 comments
Wait, I missed the newsletter: what don't we like about optparse?
Its API: it needs a lot of boiler plate code just to make it work, a lot of repetitions and it's object-oriented while there is no need in being so.
A lot? There's about two lines I'd consider "boiler plate" (three if you count the import)
from optparse import OptionParser
parser = OptionParser() # initialise parser
parser.add_option(...) # add option 1
parser.add_option(...) # add option 2
(options, args) = parser.parse_args() # run parser, get values
parser.add_option(
"-q",
"--quiet",
action="store_false",
dest="verbose",
default=True,
help="don't print status messages to stdout")
`action`, `dest` - this is particular examples of boiler plate. Why do I need to specify action if it's easily inferred from default value?
My gripe with optparse is that there's no built-in way of reading options from a config file, and allowing them to be overwritten from the command-line. I've ended up kludging together my own code to do so (as, I think, have many others), but I'd much rather have that kind of thing work out-of-the-box.
But, at first glance, this new 'opster' doesn't try to address that.
But, at first glance, this new 'opster' doesn't try to address that.
What about something like..
defaults = load_stored_config_to_dict('example.conf')
parser.add_option(
"-q",
"--quiet",
action="store_false",
dest="verbose",
default=defaults['quiet'],
help="don't print status messages to stdout")yeah, that's not a bad way of doing it. I ended up with something more convoluted, partly because of the catch-22 situation of wanting to be able to specify the config file from the command-line.
More discussion of this problem: http://deadbraincells.org/configopt/docs/configopt.html http://wiki.python.org/moin/ConfigParserShootout#ConfigParse...
More discussion of this problem: http://deadbraincells.org/configopt/docs/configopt.html http://wiki.python.org/moin/ConfigParserShootout#ConfigParse...
Yes, this was not my intention, though this thought is interesting, maybe I need to look into this.
The thing I don't like about optparse is that the documentation only mentions about half of the features. Sure, it's the most useful half, but every other standard library module has an API reference that at least mentions all the methods on every class.
For my current project at work, we're using optparse along with the configparse extension to read config files, and a bunch of monkey-patching to make it all work well together. Further development in the realm of runtime configuration is welcome, if frustratingly diverse at times.
For my current project at work, we're using optparse along with the configparse extension to read config files, and a bunch of monkey-patching to make it all work well together. Further development in the realm of runtime configuration is welcome, if frustratingly diverse at times.
Apparently enough that even another alternative (Google's "argparse") is a candidate for inclusion in the next standard library, or so I thought. :)
I only have experience with the default "optparse", and not "argparse" or any others. While optparse seems like more than enough for what I use, I know of exotic command line bastardizations that optparse would never be able to handle without some tweaks.
I only have experience with the default "optparse", and not "argparse" or any others. While optparse seems like more than enough for what I use, I know of exotic command line bastardizations that optparse would never be able to handle without some tweaks.
Looking at argparse just now, I get that one, if you need more functionality than what optparse offers, it's clearly superior. I just don't really get what opster's offering, though.
I like optparse, but I wish it handled positional arguments too.
(I fully expect someone to now come and tell me how to get it to handle positional arguments easily)
(I fully expect someone to now come and tell me how to get it to handle positional arguments easily)
I think what you're looking for is the parse_args() method, which returns a pair; one part is the named option values, the other part is everything that's left. So you handle positional arguments by iterating over the "what's left" part.
Nope. I still need to
# Check which arguments are available
# Cast them
# Provide utilization information for the arguments
# Provide defaults
# Do all the other stuff that optparse does for options
Hmm... I guess Google's argparse really is the future.
# Check which arguments are available
# Cast them
# Provide utilization information for the arguments
# Provide defaults
# Do all the other stuff that optparse does for options
Hmm... I guess Google's argparse really is the future.
This reminds me: did anything ever come of Zed's "Curing Python's Neglect" blog post? He wrote:
> but I realize that none of this will be fixed until > there’s a cultural shift in Python away from this > habit of Neglect.
Did that end up motivating any positive change?
> but I realize that none of this will be fixed until > there’s a cultural shift in Python away from this > habit of Neglect.
Did that end up motivating any positive change?
[deleted]
The argument parsing file used by Lamson is pretty good.
http://bazaar.launchpad.net/%7Ezedshaw/lamson/development/an...
http://bazaar.launchpad.net/%7Ezedshaw/lamson/development/an...
Lamson's argument parsing is directly addressed at the top of this article.
Yes I am aware, but he doesn't like it. I do.
Do you care to address any of his points so as to be relevant to the article ostensibly being discussed here?
He makes a fair argument to use his options, rather than Lamson's.
He looked at a Lamson release several versions out of date and several of his points are incorrect. So not only did he not take the time to check the newest version, he didn't take the time to properly analyze the version he did check.
Choice example: command function (can’t invent better name, sorry) need to have preformatted name (like command_ping).
This is incorrect. From the documentation: Note that the _command suffix is optional and configurable, but it is there to disambiguate your commands so you can use Python reserved words and base types as your command names. Without it, you can do a list_command or a for_command. This is after line 10 of the Lamson argument source file. Couldn't read that far I guess.
I wont bother addressing his other points. Putting in effort to refute an argument put together with no effort is nothing something I enjoy doing.
Choice example: command function (can’t invent better name, sorry) need to have preformatted name (like command_ping).
This is incorrect. From the documentation: Note that the _command suffix is optional and configurable, but it is there to disambiguate your commands so you can use Python reserved words and base types as your command names. Without it, you can do a list_command or a for_command. This is after line 10 of the Lamson argument source file. Couldn't read that far I guess.
I wont bother addressing his other points. Putting in effort to refute an argument put together with no effort is nothing something I enjoy doing.
This would've been a much better initial post, though it still fails to address the merits of the system - more DRY, less required human toil, and (apparently) errors on incorrect command lines.
I wasn't criticizing the new system, just his poor representation of existing solutions. I don't need to address the merits of his system. As for why I didn't make that my initial post, see above. Also, anyone who bothered to click on the link I provided could have seen just as easily as I did that the claims about Lamson were false.