[Python-Dev] Call for reviewer!

[Trent Mick]

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