optparse alternative

Henry Ludemann lists at hl.id.au
Mon Mar 14 20:27:36 CET 2005


> As far as I can tell, your module has one functional advantage over
> optparse--it validates arguments as well as options.

Functionality wise, that is probably about it. It is more from a 
seperation of command line / functionality code that I wrote this; that 
the command line code should be seperate from the actual functional code.

> The rest seems to be cosmetics, and personally I prefer the cosmetics 
> of optparse.

All to their own... I actually wrote this before I was aware of 
optparse, and so didn't consider the benefits / disadvantages of that 
way of doing it. It's simply a different approach. That said, what I 
like about this approach is that it is non-obtrusive on the functional code.

> For one thing, it uses the variable/function naming style found 
> throughout
> most of the stdlib. 

True... I originally wrote the code in camel case, and have attempted to 
change it to the standard from PEP 8. I guess I missed a few things :-)

> optparse has also been widely used and tested for
> the last four years.

Again, true, but then again, this module (unlike optparse) uses the 
standard getopt module for all command line parsing, which has been 
around for even longer. So the bugs are all in the method invoking (my 
code), and not in the parsing. <grin>

> I think you would be better off trying to extend optparse to deal with
> non-option arguments, and you can tap into the installed base of
> existing optparse users and even get your code included in the stdlib
> if Greg Ward agrees. Whereas that's really unlikely for an entirely
> new module--there just isn't the need for a THIRD way to do the same
> thing.

Yeah, a third module would be a bit redundent. I had actually written 
most of this module before I became aware of optparse (it was one of 
those bash the head against the wall moments when I found it), but 
decided to continue with this version because I liked the cosmetics of 
it (it seemed less intrusive on the functional code). Once it was more 
or less finished, I decided to clean it up and post it in the hope it 
might be useful to someone else, and perhaps more, to get any comments 
that could improve it. And besides, variety is the spice of life :-)

> Just a suggestion.

Thanks for your comments...



More information about the Python-list mailing list