[Guido van Rossum] > [...] One of the tasks is to adopt Greg Ward's options parsing module, > Optik. I propose to adopt this under the name "options". Any comments? For what it might be worth, from all suggestions I've seen so far, "OptionParser" is the one I like best, because of the pre-existence of "ConfigParser", and the similarity between goals and complexity level. I understand that OptionParser is _also_ a class among others in those offered, and some of us do not see a reason to _give preference_ to one particular class. I would rather the module name also being one of its class name as a mere coincidence or accident, rather than the indication that some preference was given. The objection against it is not strong. In a previous message, I told why "options" looks a bad choice to me. The next worse is probably "optlib", because its ambiguity makes it pretty meaningless. Maybe that "Optik" could be retained as yet another possibility? It might not be so bad, all considered. ;-) -- François Pinard http://www.iro.umontreal.ca/~pinard
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