HN Explorer

25 comments

[ 3.0 ms ] story [ 67.4 ms ] thread
calambrac
Wait, I missed the newsletter: what don't we like about optparse?
makecheck
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.

calambrac
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.
jnoller
FWIW: argparse is not google's
makecheck
You're right; Google code confuses me sometimes. :) It's owned by Steven Bethard.
DannoHung
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)

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

piranha
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.
mr_dbr
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
piranha
`action`, `dest` - this is particular examples of boiler plate. Why do I need to specify action if it's easily inferred from default value?
thristian
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.

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.

piranha
Yes, this was not my intention, though this thought is interesting, maybe I need to look into this.
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")
tsally
The argument parsing file used by Lamson is pretty good.

http://bazaar.launchpad.net/%7Ezedshaw/lamson/development/an...

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

[deleted]
(comment deleted)