Message180009
| Author |
chris.jerdonek |
| Recipients |
bethard, chris.jerdonek, r.david.murray, terry.reedy, wim.glenn |
| Date |
2013年01月15日.11:36:51 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1358249812.91.0.860254598091.issue16468@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Attaching patch. With this patch, passing a non-iterable choices argument to parser.add_argument() raises (for example):
Traceback (most recent call last):
...
File ".../Lib/argparse.py", line 558, in _metavar_formatter
choice_strs = [str(choice) for choice in action.choices]
TypeError: 'MyChoices' object is not iterable
instead of the incorrect:
File ".../Lib/argparse.py", line 1333, in add_argument
raise ValueError("length of metavar tuple does not match nargs")
ValueError: length of metavar tuple does not match nargs
Is it okay to change this exception type in maintenance releases? The other option is to keep the error as a ValueError but to change the error message, though I think TypeError is the correct exception to allow through. Note that the existing ValueError is preserved for other code paths. Indeed, there are several tests checking for this ValueError and its error message, which the attached patch does not break.
If we want to consider accepting non-iterable choices for 3.4, we can still have that discussion as part of a separate patch. |
|