Adding new types and new actions are the big, obvious reasons why you
might want to extend optparse. I can think of at least two
other areas to play with.
First, the simple one: OptionParser tries to be helpful by
calling sys.exit() when appropriate, i.e. when there's an
error on the command-line or when the user requests help. In the
former case, the traditional course of letting the script crash with a
traceback is unacceptable; it will make users think there's a bug in
your script when they make a command-line error. In the latter case,
there's generally not much point in carrying on after printing a help
message.
If this behaviour bothers you, it shouldn't be too hard to ``fix'' it.
You'll have to
subclass OptionParser and override the error() method
subclass Option and override the take_action() method--you'll
need to provide your own handling of the ``help'' action that
doesn't call sys.exit()
The second, much more complex, possibility is to override the
command-line syntax implemented by optparse. In this case,
you'd leave the whole machinery of option actions and types alone, but
rewrite the code that processes sys.argv. You'll need to
subclass OptionParser in any case; depending on how radical a
rewrite you want, you'll probably need to override one or all of
parse_args(), _process_long_opt(), and
_process_short_opts().
Both of these are left as an exercise for the reader. I have not
tried to implement either myself, since I'm quite happy with
optparse's default behaviour (naturally).
Happy hacking, and don't forget: Use the Source, Luke.
