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

..and the sample add_option call:

    parser.add_option(
        "-q",
        "--quiet",
        action="store_false",
        dest="verbose",
        default=True,
        help="don't print status messages to stdout")

I don't see anything repetitive, nor unnecessarily object-oreiented

`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.

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...

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.

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.

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.

FWIW: argparse is not google's

You're right; Google code confuses me sometimes. :) It's owned by Steven Bethard.

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 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.