[Python-Dev] Call for reviewer! (original) (raw)

Trent Mick trentm@ActiveState.com
Tue, 15 Aug 2000 12:53:46 -0700

On Tue, Aug 15, 2000 at 03:19:23PM -0400, Tim Peters wrote:

There are 5 open & related patches to getopt.py: 101106 thru 101110 inclusive. Who wants to review these? Fair warning in advance that Guido usually hates adding stuff to getopt, and the patch comment

I examined the entire 1.6b1 tarball for incompatibilities, and found only 2 in 90+ modules using getopt.py. probably means it's dead on arrival (2+% is infinitely more than 0% <0.1_ _wink>). On that basis alone, my natural inclination is to reject them for lack of backward compatibility. So let's get some votes and see whether there's sufficient support to overcome that.

-0 (too timid to use -1)

getopt is a nice simple, quick, useful module. Rather than extending it I would rather see a separate getopt-like module for those who need some more heavy duty option processing. One that supports windows '/' switch markers. One where each option is maybe a class instance with methods that do the processing and record state for that option and with attributes for help strings and the number of arguments accepted and argument validification methods. One that supports abstraction of options to capabilities (e.g. two compiler interfaces, same capability, different option to specify it, share option processing). One that support different algorithms for parsing the command line (some current apps like to run through and grab all the options, some like to stop option processing at the first non-option).

Call it 'supergetopt' and whoever cam 'import supergetopt as getopt'.

Keep getopt the way it is. Mind you, I haven't looked at the proposed patches so my opinion might be unfair.

Trent

-- Trent Mick TrentM@ActiveState.com