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 chris.jerdonek
Recipients bethard, chris.jerdonek, r.david.murray, terry.reedy, wim.glenn
Date 2013-01-15.21:12:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I don't disagree that this feature could be useful.  I'm just not sure it should go into a maintenance release.  It feels like an enhancement to me because to use this feature, the user will have to use the API in a way they haven't before, and we will probably have to do things like add documentation and examples for this new use case (e.g. explaining that users passing non-iterable choices will need to implement a user-friendly repr() for help to render nicely).

Also, it introduces new questions like: if we're going to be using repr() for that case, then why wouldn't we allow repr() to be used for iterable choices if the user would like to better control the behavior (e.g. for very long lists)?  Why not have a unified way to deal with this situation (e.g. something like __argparse_repr__ with a better name, or else provide or document that certain formatters should be used)?  These don't seem like bug-fix questions.

> 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.

Another possibility is that it was the most helpful message for the use case the writers originally had in mind.  Certainly, for example, seeing the available choices '0, 1, 2, 3, 4' is more useful than seeing 'xrange(5)'.
Date User Action Args
2013-01-15 21:12:10chris.jerdoneksetrecipients: + chris.jerdonek, terry.reedy, bethard, r.david.murray, wim.glenn
2013-01-15 21:12:10chris.jerdoneksetmessageid: <>
2013-01-15 21:12:10chris.jerdoneklinkissue16468 messages
2013-01-15 21:12:09chris.jerdonekcreate