[getopt-sig] The bake-off

[A.T. Hofkamp]

Hello Guido, SIG,

I'd like to respond to your challenge as author of argtools.
I also tried to describe how Optik, argparser, and argtools 'feel', or at
least how I experienced it.

On Wed, 29 May 2002, Guido van Rossum wrote:

> As an exercice in how easy each of the three alternatives makes it to
> change the option set, I'd like to see each version augmented with
> this feature.  There may be no config file yet, so maybe the default

Argtools doe not need to be augmented, it already supports this.
It it would not this, one would need to write a new derived class for a
yes/no option, which takes about 5-10 lines of Python.


With respect to the (now very dead) discussion:
Basically, the discussion ended with in a deadlock-like situation.
In my opinion, there exists fundamental disagreement about how to
approach the option parsing problem in the general case.

First of all, Optik does a nice job for the average case. Its use of
objects for options is a natural choice for many programs. Also, it is
relatively easy to explain to new-comers.
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.
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 ...

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 ?"
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 think (and a number of other people in this SIG as well), that we should
aim for something more flexible/modular, to avoid the situation that a user
of the option parsing library has to start from scratch even (especially!!)
in the extremely simple and extremely complex cases.

Argparser of Russ Cox aims for the simple case (which I consider very
readable, in particular for people not used to objects), argtools is a
special-purpose library that I wrote in C++, and translated to Python.
The latter tool is very basic, and extremely object-oriented (more than
Optik).

Unfortunately, I do not have the time to implement a modular parsing
library to a level like Optik.

As for the proposals done later, I did not understand what was happening,
and how that proposal relates to other option parsing libraries.

> without the help text) and how many lines had to be changed.  If the
> three contestants come out in the same order as in the first contest,
> that settles the matter for me.  If not, we'll have to try to
> understand why.

The Argtools version will not change in any way, except that a different
class must be instantiated.

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).
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).
Argparser is not object-oriented, and thus like getopt, is extremely accessible
for newbies, and users not familiar with object-oriented concepts. The
downside is that the library offers no structure for the more complex cases
(i.e. it is a lot of DIY).


Albert
-- 
Unlike popular belief, the .doc format is not an open publically available format.