homepage

I've recently had to subclass optparse.OptionParser, and copy-paste the
exit method, just to change where errors were printed to (I needed
stdout rather than stderr). I've also had a request from a client to
log errors with command-line parsing to a file, rather than to stdout.
So, this patch adds an error_log parameter to OptionParser.__init__
which is used instead of stderr internally (and, of course, defaults to
stderr).

To move this forward would need patches against py3k, assuming that the original patch is agreed upon in principle.

Having an easy way to control where output goes makes sense. This is a new feature, however, and thus only a candidate for 3.2, and in 3.2 it would be better to target it at argparse. I think argarse makes this easier to do via subclassing, but doing so the easy way seems to require overriding a 'private' method (_print_message). I've added Steven to the nosy list to see what he thinks.

Not sure, but I think _print_message in argparse isn't exactly what the OP is looking for if they really only care about errors. If you want to override how errors are printed, then it's absolutely correct to override the error method (in argparse at least), and your overridden method should be given every message that is normally printed as an error.
If by errors, you mean "anything the parser might print out" (e.g. the output of "--help"), then you may indeed want _print_message to become public so you can override it. Let me know.

Hi Daniel, did you read Steven suggestions? are you willing to propose a patch about your feature request against argparse (optparse is deprecated and no more under development in stdlib)?

Following issue9938, argparse now offers a convenient way to handle errors. I propose to close this issue as out of date.