This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add error_log attribute to optparse.OptionParser
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: bethard, draghuram, eric.araujo, iritkatriel, odd_bloke, r.david.murray, sandro.tosi
Priority: normal Keywords: patch

Created on 2008-11-11 14:22 by odd_bloke, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
optparse-error_log.patch odd_bloke, 2008-11-11 14:22 Patch adding error_log attribute to OptionParser review
Messages (6)
msg75741 - (view) Author: Daniel Watkins (odd_bloke) * Date: 2008-11-11 14:22
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
msg109574 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-08 19:26
To move this forward would need patches against py3k, assuming that the original patch is agreed upon in principle.
msg109799 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-07-09 21:33
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.
msg111301 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2010-07-23 12:35
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.
msg128324 - (view) Author: Sandro Tosi (sandro.tosi) * (Python committer) Date: 2011-02-10 18:15
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)?
msg379658 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-10-26 10:15
Following issue9938, argparse now offers a convenient way to handle errors. I propose to close this issue as out of date.
Date User Action Args
2022-04-11 14:56:41adminsetgithub: 48547
2020-11-15 23:48:36iritkatrielsetstatus: pending -> closed
resolution: out of date
stage: resolved
2020-10-26 10:15:40iritkatrielsetstatus: open -> pending
nosy: + iritkatriel
messages: + msg379658

2014-02-03 19:17:58BreamoreBoysetnosy: - BreamoreBoy
2011-02-10 18:15:44sandro.tosisetnosy: + sandro.tosi
messages: + msg128324
2010-07-23 12:40:19eric.araujosetnosy: + eric.araujo
2010-07-23 12:35:27bethardsetmessages: + msg111301
2010-07-09 21:33:07r.david.murraysetnosy: + r.david.murray, bethard

messages: + msg109799
versions: - Python 3.1, Python 2.7
2010-07-08 19:26:05BreamoreBoysetnosy: + BreamoreBoy

messages: + msg109574
versions: + Python 3.1, Python 3.2
2008-11-11 14:35:42draghuramsetnosy: + draghuram
2008-11-11 14:22:58odd_blokecreate