Thanks for the comments...
Steven Bethard wrote:
Looks interesting, but is it really that different from optparse?
In the sense that they both do the same thing, no, not really. But the way they do it is quite different; optparse bases itself on setting variables, while this module is for invoking functions. I like this way a better, as it acts as a more 'usual' client of the code, in the sense that it uses publically exposed interfaces rather then internal variables for passing the information. That said, the reason I started this was that at the time I wasn't aware of optparse; my search through the help needed to be a bit more thorough. When I found optparse, I decided to continue on with this approach (mostly because I was having fun with it).
I do like the fact that you can specify a type with a conversion function. (In optparse, AFAIK, to add a new type you have to write your own subclass of Option that screws with Option.TYPES and Option.TYPE_CHECKER, which I've always thought was kinda nasty.)
Yeah, it works quite nicely; as it is a general function, you can use your own methods for creating arbitrary objects (so long as they take one parameter (a string)).
But I wonder if it wouldn't be better to extend optparse with the functionality instead of writing an entirely new module...
The way of getting the data through to the program is quite different (method vs data), so that would be a fairly radical change / addition for optparse.
-- http://mail.python.org/mailman/listinfo/python-list
