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 ethan.furman
Recipients barry, eli.bendersky, eric.smith, ethan.furman, ncoghlan, serhiy.storchaka
Date 2013-08-28.08:17:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377677837.69.0.245951420255.issue18738@psf.upfronthosting.co.za>
In-reply-to
Content
On 08/14/2013 09:27 PM, on PyDev, Nick Coghlan wrote:
> For enums, I believe they should be formatted like their
> base types (so !s and !r will show the enum name, anything without
> coercion will show the value).

I agree.  While one of the big reasons for an Enum type was the pretty str and repr, I don't see format in that area.


So, these are some of the ways we have to display an object:

str()       calls obj.__str__()
repr()      calls obj.__repr__()

"%s"        calls obj.__str__()
"%r"        calls obj.__repr__()
"%d"        calls... not sure, but we see the int value

"{}".format()  should (IMO) also display the value of the object

Using int as the case study, its presentation types are ['b', 'd', 'n', 'o', 'x', 'X'].  Notice there is no 's' nor 'r' in there, as int expects to display a number, not arbitrary text.

So, for mixed-type Enumerations, I think any format calls should simply be forwarded to the mixed-in type (unless, of course, a custom __format__ was specified in the new Enumeration).

Patch attached.
History
Date User Action Args
2013-08-28 08:17:18ethan.furmansetrecipients: + ethan.furman, barry, ncoghlan, eric.smith, eli.bendersky, serhiy.storchaka
2013-08-28 08:17:17ethan.furmansetmessageid: <1377677837.69.0.245951420255.issue18738@psf.upfronthosting.co.za>
2013-08-28 08:17:17ethan.furmanlinkissue18738 messages
2013-08-28 08:17:17ethan.furmancreate