[getopt-sig] there isn't really any discussion here

Derek Harland derek@chocolate-fish.com
Wed, 13 Feb 2002 20:58:17 -0000


----- Original Message -----
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: <getopt-sig@python.org>
Sent: Wednesday, February 13, 2002 6:24 PM
Subject: [getopt-sig] there isn't really any discussion here


> I admit to being somewhat disheartened by the recurring cries for
> supposed features like ``optional arguments'' (which introduce parsing
> ambiguities) and ``mandatory options'' (a contradiction in terms).

I'm not sure I understand either of these worries.  To me an optional
argument is usually a simple flag to the program to indicate something.  I
mean you either compile a c program in debug mode, or you  don't.
Alternatively its something you specify if required, otherwise the program
decides it for you.

Then again some other options are mandatory but there values are not known
in advance.

eg.  I have scripts that do something and need to know the date for which
they are processing data.  You specify it with --close=20020201 eg if you
wish to run it historically.  Otherwise it assumes you mean today (as you
nearly always do) ... thats an optional argument to me.

This same script only processes data relating to a specific currency.  You
have to give a currency for it to operate on --currency=EUR.  It can't run
without knowing a currency to operate on.  Thats mandatory.

Object orientated, iterative, getopt or purely inspecting sys.argv ... lots
of scripts *have* to be given something.

> I did gain something from all this, namely that I now have an
> argument parser that is simpler to use than the current getopt.
> Now I won't need to consult the getopt documentation every
> time I write a main() function.  For that I am quite grateful.

We may disagree about the approach, but this sums up the problem entirely.
I dislike getopts in all of its incarnations ... remembering that colons
represent argument options, that the return values include the '-' or '--'
in the option name.  It just isn't very friendly, which is Python's
underlying strength.

But without *something* better people will always be forced to reinvent an
obviously square wheel.

> Russ

Des