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.

classification
Title: getopt errors should be specialized
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: eric.araujo, gruszczy, r.david.murray, richlowe
Priority: normal Keywords: patch

Created on 2010-05-28 00:44 by richlowe, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
8841.patch gruszczy, 2011-03-02 09:46 review
Messages (14)
msg106632 - (view) Author: Richard Lowe (richlowe) Date: 2010-05-28 00:44
The GetoptError exception raised by getopt.getopt() to indicate errors in provided arguments seems intended to be displayed to the user[1], but is not localized and doesn't contain enough information, short of interpreting the error string, for consumers to raise their own, localized, error.

[1] http://docs.python.org/library/getopt.html
msg122628 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-28 04:49
Do you want to provide a patch?
msg129818 - (view) Author: Filip Gruszczyński (gruszczy) Date: 2011-03-01 22:08
I'd be happy to provide a patch.

How about extending getopt api to something like this:

>> optlist, args = getopt.getopt(['-b'], 'e', not_recognized="no %s option, mate!")
GetoptError: no -b option, mate!

Or maybe you should provide a dictionary?

>> optlist, args = getopt.getopt(['-b'], 'e', errors={'not_recognized': "no %s option, mate!")
GetoptError: no -b option, mate!

I have little experience with making design decisions, so if someone could guide me here, I will get down and provide a patch with proposed solution.
msg129820 - (view) Author: Filip Gruszczyński (gruszczy) Date: 2011-03-01 22:10
One more solution. Maybe getopt should expose variables that hold error messages (rather than have them hardcoded in the code), that can be simply substituted by the user before he runs getopt? But I don't really like this one.
msg129824 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-03-01 22:23
Filip: The standard way of doing localization is thanks to the gettext module.

Richard: Regarding the contents of the error messages, please make specific remarks on what is lacking.
msg129825 - (view) Author: Filip Gruszczyński (gruszczy) Date: 2011-03-01 22:27
I understand I should do something similar to what is done in argparse:

from gettext import gettext as _, ngettext

...

message = ngettext('conflicting option string: %s',
                   'conflicting option strings: %s',
                   len(conflicting_actions))

and then let user define those messages somewhere in his own po files?
msg129827 - (view) Author: Richard Lowe (richlowe) Date: 2011-03-01 22:29
I don't find anything lacking about the error messages, I meant that there were no more specific exceptions, or fields in GetoptError to allow the caller to tell what was specifically wrong and provide its own localized messages.  So while the defaults are unlocalized, all an application can do is interpret the error string to provide a localized message.

The solution I was thinking of is getopt raising sub-types of GetoptError for each specific error case (unknown option, option requires argument, etc), and the message text of each of those being localized through gettext().  I'm not sure what problems that could cause with compatibility however, beyond obviously anyone who's already resorted to interpreting the string would have problems.
msg129828 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-03-01 22:35
Richard: It’s not common to use subclasses to allow message customization.  Would gettext cover your need?
msg129830 - (view) Author: Richard Lowe (richlowe) Date: 2011-03-01 22:49
Sure, just localizing them in the getopt implementation would be fine.

I suggested subclassing to solve the more general problem of the caller being able to tell one getopt error from another, for which it is a pretty common solution.
msg129861 - (view) Author: Filip Gruszczyński (gruszczy) Date: 2011-03-02 09:46
Here is a small patch. Could you advise me, how can I test it now? Or is it an issue, that doesn't require writing new tests?
msg129864 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-03-02 10:24
> I suggested subclassing to solve the more general problem of the
> caller being able to tell one getopt error from another, for which it
> is a pretty common solution.

Now I see what you meant and understand your request.  optparse has five different error classes and argparse has two, but they don’t bubble up to the caller, they’re caught and turned into error messages.  getopt is different, since it require its users to do the gruntwork, so having different exceptions for different user errors would be helpful.  Compatibility would not be an issue, we’d just make all classes inherit from GetoptError so that except clauses would still work.  I think you should take this to the python-ideas mailing list: Do other getopt users need this functionality?  What subclasses should there be?

Filip: Localization of error messages in getopt is another enhancement.  Would you mind opening another report and moving your patch there?  Thanks.
msg129866 - (view) Author: Filip Gruszczyński (gruszczy) Date: 2011-03-02 10:32
Here it is: http://bugs.python.org/issue11371
msg189047 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2013-05-12 16:58
#11371 was closed on 2011-03-21 so what if anything needs doing here?
msg240333 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-04-09 14:54
A python-ideas discussion was requested, but none has been linked to.  So let's close this as uneeded.  It can always be reopened if there is renewed interest.
History
Date User Action Args
2022-04-11 14:57:01adminsetgithub: 53087
2015-04-09 14:54:57r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg240333

resolution: rejected
stage: needs patch -> resolved
2014-02-03 18:31:14BreamoreBoysetnosy: - BreamoreBoy
2013-05-12 16:58:34BreamoreBoysetnosy: + BreamoreBoy
messages: + msg189047
2011-03-02 10:32:48gruszczysetmessages: + msg129866
2011-03-02 10:24:01eric.araujosetmessages: + msg129864
title: GetoptError strings should be localized -> getopt errors should be specialized
2011-03-02 09:46:27gruszczysetfiles: + 8841.patch

messages: + msg129861
keywords: + patch
2011-03-01 22:49:16richlowesetmessages: + msg129830
2011-03-01 22:35:35eric.araujosetmessages: + msg129828
2011-03-01 22:29:15richlowesetmessages: + msg129827
2011-03-01 22:27:49gruszczysetmessages: + msg129825
2011-03-01 22:23:16eric.araujosetversions: + Python 3.3, - Python 3.2
messages: + msg129824
stage: needs patch
2011-03-01 22:10:19gruszczysetmessages: + msg129820
2011-03-01 22:08:38gruszczysetnosy: + gruszczy
messages: + msg129818
2010-11-28 04:49:08eric.araujosetnosy: + eric.araujo
messages: + msg122628
2010-07-11 02:26:32terry.reedysetversions: + Python 3.2, - Python 2.6
2010-05-28 00:44:08richlowecreate