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.

Author terry.reedy
Recipients bethard, chris.jerdonek, r.david.murray, terry.reedy, wim.glenn
Date 2013-01-15.20:24:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1358281451.32.0.993449826824.issue16468@psf.upfronthosting.co.za>
In-reply-to
Content
The exception question is messy, but I think it is the wrong question. The doc is correct in that it says what the code should be doing. To test whether an argument is in a collection of choices, the code should just say that: 'arg in choices' (as far as I know, it does -- for the actual check). In other words, I think the original intent of this issue is correct.

"Clearly the module was written under the assumption (in multiple places) that choices are iterable." I think it should not. We implement 'in' with '__contains__', rather than forcing the use of iteration, for good reason. I discussed some examples in msg175520.

As far as I know, the reason argparse iterates is to bypass the object's representation methods and produce custom, one-size-fits-all, usage and error messages. As discussed in #16418, this supposed user-friendliness may not be. To me, restricting input for this reason is a tail-wags-dog situation. If the object is not iterable, just use repr for the messages instead of exiting. Let the app writer be responsible for making them user-friendly and not absurdly long.
History
Date User Action Args
2013-01-15 20:24:11terry.reedysetrecipients: + terry.reedy, bethard, r.david.murray, chris.jerdonek, wim.glenn
2013-01-15 20:24:11terry.reedysetmessageid: <1358281451.32.0.993449826824.issue16468@psf.upfronthosting.co.za>
2013-01-15 20:24:11terry.reedylinkissue16468 messages
2013-01-15 20:24:10terry.reedycreate