On 30 September 1999, Guido van Rossum said:
Marc-Andre, you're not hearing what Mark is saying. He wants a change to the standard library, and he knows that small additions to existing modules there stand a better chance of adoption than new modules.
I personally liked the idea of getoptex() best, except I would call it getopt_or_die().
Gasp! Guido hath drunk from the poisoned well of the Great Camel and it doth infest his thinking! "or die" indeed -- not an idiom I've seen since the last time I wrote some Perl code (umm, last week?).
If the usage message is omitted it can synthesize one from the (short and long) options arguments and sys.argv (the latter being a bit controversial, but it's just a default).
Hmm... Perhaps getopt_or_die() shouldn't take the args argument but extract sys.argv[1:] itself?
Whatever we call it, it should be able to take an explicit argument list, and only default to sys.argv[1:]. What if I want to parse options from an environment variable or a config file? I also like the "don't clobber sys.argv, but return the modified version instead" model -- it's nice to keep a pristine copy of the original argument list!
Another problem with getopt is that it doesn't correlate long and short options. I wrote distutils.fancy_getopt (download your copy today! hurry, don't delay -- at this price, it WON'T LAST LONG!) to address this, and to maybe someday do something with help text.
On the other hand, don't listen to me -- I tend to write mammoth, bloated, all-singing, all-dancing command-line parsing modules for every new language I encounter. They get more insane with each iteration. I have yet to top my Getopt::Tabular for Perl, though; see
if you've ever wondered how far this sort of thing can be taken in a high-level, dynamically typed language.