Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Does anyone else aside from zed have burning issues with optparse? I'm genuinely curious. I use it quite a lot, but have never really had to push the boundaries of what optparse can do. As an example, my optparse code usually looks something along these lines:

    from optparse import OptionParser
    parser = OptionParser()
    parser.add_option("--force", default=False, action="store_true")
    parser.add_option("--host", default="localhost")
    options, args = parser.parse_args()
Is it really that bad? Where does it fall down?


Zeds way (look in the lamson source: it is in lamson.args and well documented) gives you a bi more freedom.

So it passes out any options it finds by default and lets you decide what to do with it - you only have to call a function if you want to set a default.

It lets you run args.parse_and_run_command to directly run a function and pass it the cmdline options as a dict.

It's all very handy and is totally compatible with previous cmdline structures!

I think it's a neat option & hopefully someone will convince Guido to have it in Python core in the future :) (doubt it though)

Grab the lamson source and dig it out to get a better idea.


I use it frequently and I like the output it creates. I sure as hell like python's better than C#'s (== none at all and people doing all kinds of crazy broken crap inlined into Main(string[] args).

I've never managed to use optparse without the docs open though. I'm not sure that's a defect, but it seems like room for improvement.

Can someone (zed?) point at a library in any other language that's better?


I liked Getopt::Long in Perl. Even in Python, argparse or optfunc are better (IMHO)


And honestly, Zed's revolutionary replacement isn't that great (http://lamsonproject.org/docs/api/, see lamson.args/lamson.commands).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: