Re: The bake-off

> The only serious candidate discussed in this SIG is your Optik.

This is what settled things for me.  Unless
we're going to build a new option parser
from scratch, the only one under consideration
that accomodates what people want is Optik.
People have built big programs with Optik and
reported that they were happy (not just satisfied,
but happy!) with the experience.  No one has even
tried to build big complex programs with the
other tools under consideration.

I will probably still use my own trivial iterator-based
parser, but what I expect from my programs (e.g.,
not super-verbose help messages or explanations
of what went wrong on the command line) is not what
everyone else expects or wants.  I'm not writing
programs that I expect to give to lots and lots of people.

For inclusion in the standard Python library, it seems
pretty clear that people would be happiest with Optik.

The other big plus in favor of Optik is that Greg clearly
cares to some extent about what users want and has
a history of evolving Optik to make it better.

In contrast, my solution is just exactly right and
couldn't possibly be improved ;-) so I'm not very
interested in working further on it.

My only nit with Optik (and a very small one at that)
is the dual syntax for adding options.  I'd rather just
see the normal Python list syntax and drop the 
add_option method, but the latter seems entrenched.
(In fact, the reason I was turned off by Optik originally
was I didn't know about the list syntax and thought 
the add_option was the only way to go.)

Russ