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[0] (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
http://search.cpan.org/doc/GWARD/Getopt-Tabular-0.3/Tabular.pod
if you've ever wondered how far this sort of thing can be taken in a
high-level, dynamically typed language.
Greg
--
Greg Ward - software developer gward@cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4