

Opster: Pythonic option parsing - Ysx
http://blogg.ingspree.net/blog/2009/09/14/opster/

======
calambrac
Wait, I missed the newsletter: what don't we like about optparse?

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

~~~
mr_dbr
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")

~~~
danohuiginn
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...](http://wiki.python.org/moin/ConfigParserShootout#ConfigParser.2CoptparseMarriage)

------
garnet7
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?

------
tsally
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/annotate/head%3A/lamson/args.py)

~~~
req2
Lamson's argument parsing is directly addressed at the top of this article.

~~~
tsally
Yes I am aware, but he doesn't like it. I do.

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

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

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

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

