[getopt-sig] The bake-off

[Greg Ward]

On 30 May 2002, A.T. Hofkamp said:
> The bad side of Optik is that it is not particularly special in the world
> of option parsing, i.e. it does not do anything real fancy.

Exactly.  Change "bad" to "good" and that could be me talking.

> Also, Optik tries to do its thing as a whole.
> This is in my opinion the core fundamental disagreement.
> 
> For simpler needs than Optik, i.e. something near
> 
> for arg in sys.argv:
>     if arg == option-e:
>     	# handle option -e
>     elif ...

If you have one or two options, it's a wash: DIY or getopt or Optik are
all about the same amount of code.  But when those one or two options
grow, as they always do, Optik wins hands-down.

> or for something much more complex, like "cvs <command>
> <command-specific-options>", Optik delivers no support, i.e. in both cases,
> we are back to scratch "we have sys,argv, what now ?"

Not true.  This was discussed in detail back in Feburary; all you have
to do is create multiple OptionParser objects, and pass each chunk of
your command-line through them in turn.  I even posted (untested,
hypothetical) code for this.

> The same happens when you'd want to add something new, like for example a
> config file.
> Greg (the author of Optik) considers support for such situations outside
> the goal of Optik (his goal is 'something better than getopt' as I recall).

I don't think this is one of the Nineteen Pythonic Theses, but maybe
there should be a Twentieth:

   Don't let "perfect" be the enemy of "good enough".

Perfection is unattainable by us puny mortals; good enough is, well,
good enough.

BTW, I have written one app that uses Optik and a config-file (although
the config file is just a Python module, as I have decided that Python
is after all the right language for config files).  It's good enough.

> For people understanding the object-oriented concepts, argtools is the
> smallest and most flexible (though not flexible enough to handle e.g. cvs
> like option parsing).

*splutter* but you just criticized Optik for not being able to handle a
"sub-command" style of interface out-of-the-box!

> The downside of argtools is that it does not do everything, for example the
> user still has to write a help-page by hand.
> Optik is also object-oriented, but its interface to the user buries a lot
> of it. Also, Optik is far more complete. That makes it an ideal tool for
> the average case, but extending Optik is very difficult (basically, the objects
> are dropped, and you are stuck with call-backs to functions in a
> non-object-oriented fashion).

Callbacks are not the standard way of extending Optik; they're just
there for cases where you don't need to extend the core classes.
They're not strictly necessary, but they are convenient.  I imagine they
will be especially useful for naive users who are afraid of subclassing.

Extensive, detailed instructions for how to extend Optik -- in the OO
way, by subclassing Option and/or OptionParser -- are included in the
source distribution.  Several examples of what you can do by subclassing
Optik are in the examples/ directory.

        Greg
-- 
Greg Ward - programmer-at-large                         gward@python.net
http://starship.python.net/~gward/
Those of you who think you know everything really annoy those of us who do.