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.

- This will break a small number of valid int format strings, but we
should just accept that potential breakage. This is something to
consider if we're replacing existing ints with IntEnums (which I'm not
generally in favor of, anyway).

- Live with the fact that we'll need to update this code if we add any
int (or float) presentation types.

I think we might want to consider the same thing for bool.__format__,
but that's another issue. Maybe int could grow a __format_derived_type__
method implements the above, and bool and IntEnum could set their
__format__ to be that. Which probably points out that the original
int.__format__ design is flawed (as Nick pointed out), but too late to
change it.

Or, thinking even more outside the box, maybe int.__format__ could
implement the above logic if it knows it's working on a derived class.
That would change bool as well as all other int-derived types, but leave
int itself alone. More breakage, but potentially more useful. But again,
we should open another issue if we want to pursue this approach.