[getopt-sig] The bake-off
Guido van Rossum
guido@python.org
Thu, 30 May 2002 12:01:03 -0400
> > 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.
It seems you have misunderstood me. I wasn't expecting *any* of the
*tools* to require changes. I wanted to measure the changes needed to
the examples of using the tools, i.e.
http://www.python.org/sigs/getopt-sig/ripoff_argtools.py
to implement the change in requirements.
> 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 way I understand Optik, you can create multiple parser instances:
one for the global options that come before the command name, and one
for each command's specific options. That sounds like a fine
solution to me; I don't think I expect more from an options parser.
> The same happens when you'd want to add something new, like for
> example a config file.
Which is also out of scope for an options parser.
> 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 agree; that's what I've asked for.
> 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.
May I point out that perfection is often the enemy of "good enough"?
Or maybe I should just say YAGNI (You Ain't Gonna Need It -- Google
for it if this is the first time you see this).
> 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.
Well, that settles it then. Let's not be distracted by theoretically
optimal solutions when we have something that works now (remember the
Zen of Python).
> 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.
You mean the "--no-xxx" syntax already has standard support? Nice.
[Arguments based on OO-ness snipped]
--Guido van Rossum (home page: http://www.python.org/~guido/)