On 11 February 2002, Guido van Rossum said:

No immediate objection, although there are some other fancy options packages around, and IMO you have to explain why Optik is better.

Well, here's what I like about Optik:

* it ties short options and long options together, so once you define your options you never have to worry about the fact that -f and --file are the same

* it's strongly typed: if you say option --foo expects an int, then Optik makes sure the user supplied a string that can be int()'ified, and supplies that int to you

* it automatically generates full help based on snippets of help text you supply with each option

* it has a wide range of "actions" -- ie. what to do with the value supplied with each option. Eg. you can store that value in a variable, append it to a list, pass it to an arbitrary callback function, etc.

* you can add new types and actions by subclassing -- how to do this is documented and tested

* it's dead easy to implement simple, straightforward, GNU/POSIX- style command-line options, but using callbacks you can be as insanely flexible as you like

* provides lots of mechanism and only a tiny bit of policy (namely, the --help and (optionally) --version options -- and you can trash that convention if you're determined to be anti-social)

Anyways, read the docs at optik.sourceforge.net for the whole deal.

Can we change the name? Optik is nice for a standalone 3rd party module/package but a bit too fancyful for a standard library module.

Sure, no problem.

It could be a new function in getopt:

from getopt import OptionParser
[...]
parser = OptionParser()

I guess that's OK if we're agreed that Optik is the be-all, end-all option-parsing tool. (I happen to think so, but I'd like to get opinions from a few other python-dev'ers before I let this go to my head.) I'm pretty cool to names like "super_getopt" or "fancy_getopt", despite having perpetrated precisely the latter in the Distutils. ;-(

Greg

I'd also be in favour of providing option parsing through getopt only. If getopt is not enough, extend it (in moderate ways, rather adding customization mechanisms instead of alternatives, etc). If that involves incorporating code from Optik, fine. However, I don't think the standard library should have two modules that do essentially the same thing; such scenarious will raise question whether one is better than the other and which of them is maintained.

I think Optik provides one key idea that makes it better: an options parser object that can be invoked multiple times and each time returns a new options object whose attributes are variables corresponding to various options.

I'd be happy to say that the old getopt.getopt() interface will be deprecated.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Maybe we should turn the Optik documentation into a PEP (or at least make a PEP with a pointer to it) so that people with competitive solutions can either suggest improvements or claim that their solution is a better starting point.

IMO we don't need a PEP, but we do need to solicit feedback from people with competitive solutions. Can you post something to c.l.py and c.l.py.announce?

--Guido van Rossum (home page: http://www.python.org/~guido/)

I am happy to do an announcement but I feel like there needs to be a place to redirect conversation. Should we set up a mailing list? Or do all interested people want to join comp.lang.python and perhaps use a subject prefix for filtering? "OPT: ..."

They can post to python-dev (and even subscribe -- it's open these days) or someone can summarize. I don't expect a huge discussion. Please make it clear in the announcement that followups in c.l.py will be ignored -- they must send at least one email to python-dev to make us aware that they're competing. Ideally, it should compare their solution to Greg's list of key features of Optik, which he posted here:

http://mail.python.org/pipermail/python-dev/2002-February/019937.html

Please include that link in your announcement.

--Guido van Rossum (home page: http://www.python.org/~guido/)

On 11 February 2002, I said:

A good starting point for modules that compete with Optik can be found in "User Interfaces" section of the Vaults of Parnassus:

http://www.vex.net/parnassus/apyllo.py/808292924

OK, I've looked at all the option-parsing packages listed in Parnassus. I've read the docs for all of them, and flipped through the source for some of them. Here's the executive summary:

* only one of them, arglist.py by Ben Wolfson, has a nice OO design similar to Optik

* the one feature that several of the competition offer but Optik does not (yet) is the ability to specify an option that *may* take a value, but doesn't necessarily *have to* take a value. Ironically, this is one of my requirements for the Distutils, motivated by the --home option to the "install" command.

I think arglist.py is the only serious contender here. Based on my cursory inspection, all of the others have rather deep flaws. (Eg. they implement a non-standard syntax, or they do all their work at import time rather than providing a class to instantiate and do option-parsing work, or they have painful/awkward/hairy programming interface.)

I'll attach my full notes. Anyone else who feels like doing this should start at the *bottom* of the list on Parnassus, since I devoted progressively less time and energy to each package along the way. ;-)

Greg