optparse alternative

[Henry Ludemann]

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.