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... -- http://mail.python.org/mailman/listinfo/python-list
