6.21.5.3 Other reasons to extend optparse
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 error()
-
subclass Option and override take_action()--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.
 |
 |
 |
Python Library Reference |  |
 |
 |
Release 2.4.1, documentation updated on 30 March 2005.