[getopt-sig] Prefer non-imperative -- my 1 cent

[Russ Cox]

Can you give an example (perhaps a big one) where option
parsing with Optik-style objects makes things clearer
than the traditional loop?  

I will grant that perhaps there are cases where the
loop might just get too big, but I have a hard time
envisioning them.  In particular, just having
lots of options doesn't seem like enough to make
the option loop not work.  You claim that tying "all
the logic related to an option into a single solitary
stanza" is a good thing, which I grant.  What I don't
understand is how many of these:

	elif o=='-o' or '--optionlong':
		# single solitary stanza here

don't actually do that or could get "sufficiently
bloated that it is difficult to take in the structure
of it at once."

All that aside, my big problem with the Optik-style
modules, and to a lesser extent getopt, is the barrier
to entry.  Option parsing is something everyone has to
do, more or less; it should require as little work
as possible to get simple parsing in place.  The fact
that it's _not_ simple enough is why people settle for
quick and dirty things like

	if sys.argv[1]=='-d':
		debug=1
		sys.argv = sys.argv[1:]

when they want just one or two options.  This problem
is certainly endemic in C programs; I haven't surveyed
enough Python programs to make informed comments about
how widespread the practice is in Python.

On the other hand, since (in the module I posted)
it's hardly any more code to use the option parser:

	opt = OptionParser()
	for o in opt:
		if o=='-d':
			debug=1

I think people are more likely to use it, even for quick
and dirty argument parsing.  I think that's the big deal.

Of course, it's possible that there is some hybrid scheme
that would satisfy everyone, but I really don't have
any feel for argument parsing so hairy that you need
parsing objects and callbacks and the like: someone please
enlighten me.

Thanks.
Russ