On Thu, Aug 15, 2013 at 3:20 PM, Eric V. Smith <report@bugs.python.org>wrote:

>
> Eric V. Smith added the comment:
>
> On 8/15/2013 5:46 PM, Eli Bendersky wrote:
> > The whole point of IntEnum and replacing stdlib constants with it was
> friendly str & repr out of the box. This means that "just printing out" an
> enum member should have a nice string representation. And "just printing
> out" means:
> >
> > print(member)
> > "%s" % member
> > "{}".format(member)
>
> 100% agreed.
>
> > !s/!r are quite esoteric - IntEnum should behave in the nicest way
> possible out of the box.
>
> Not only that, they're not part of the __format__ protocol, anyway.
>
> > Let's just rig IntEnum's __format__ to do the right thing and not worry
> about Enum itself. I hope that mixin-with-Enum cases are rare (and most are
> IntEnum anyway), and in such rare cases users are free to lift the
> implementation from IntEnum.
>
> Agreed.
>
> And the next question is: what is "the right thing"? Does it always
> appear to be a str? Or sometimes str and sometimes int? And how far
> deviant from plain int can it be?
>
> I think the answers should be:
>
> - Formats as int if the length of the format spec is >= 1 and it ends in
> one of "bdoxX" (the int presentation types).
>
> - Possibly format as float if the format spec ends in "eEfFgGn%" (the
> float presentation types), but the utility is doubtful. However, int
> converts to float with these, so we may as well do the same.
>
> - Otherwise formats as a str.
>
>
Sounds good to me. One of IntEnum's raison d'êtres is to be an integer with
a nice string representation. So it makes sense to make it show itself as a
string, unless expicitly asked for an int. Float-conversion *is* dubious,
but I agree that following int's lead here is harmless and least surprising.

Naturally, compatibility with % formatting is desired. '%s' is str, '%i' is
int().
*
*
*

*