[getopt-sig] Option package requirements

[Greg Ward]

[Russ Cox reacts to Matthias Ulrich's proposals]
> All of the examples you propose have non-standard behaviors,
> introduce ambiguities, and only serve to confuse users.  There's
> no good justification for any of the examples you present.
> In _my_ HO, all of them are examples of bad design, and it
> would not be such a bad thing if the standard Python option
> parser made it very hard or impossible to emulate them.

I completely agree with you here.  (And, for the record, I think sox
definitely belongs in the doghouse with tar and rpm for unnecessarily
difficult command-line UIs.  sox is the worst offender in my books, but
that's probably only because I have long since made my peace with tar
and rpm (and I use Debian now ;-).)

But, irony of ironies, it seems to me that your iterator interface is
exactly the tool for people who *do* want to perpetrate such awkward,
non-standard UIs.  A one-option-at-a-time, let-me-write-all-the-code-
dammit interface is *just* what the doctor ordered if you want to deal
with anti-social things like context-sensitive options, multiple sets of
options on the same command line, order sensitivity, and the like.
Writing such a beast with Optik would be really painful -- you'd need a
lot of callbacks that interact with each other in complicated ways.  I
think that discouraging that sort of bad UI is a *feature*.  I thought
that the appeal of your iterator interface is that it exposes the
flexibility to be evil for people who (think they) need it.

        Greg
-- 
Greg Ward - Linux nerd                                  gward@python.net
http://starship.python.net/~gward/
Never put off till tomorrow what you can put off till the day after tomorrow.