On 8/20/2013 9:26 PM, Ethan Furman wrote:
> Sounds like the way forward is to specify in the docs how the default 
> Enum __format__ behaves (basically honors width and justification 
> settings to yield the name, anything else passes through to the Enum 
> member) along with advice matching that for __str__ and __repr__: if you 
> want something different, write your own method.

I definitely agree on the documentation part.

But I think that IntEnum should have its own __format__, because it
wants something different.

And I still think that any interpretation of the format spec in
Enum.__format__ is a mistake, because you don't know what the string
means to the passed-to object. You're basically trying to guess: does
this look like something that makes sense as a str.__format__ specifier
and I should handle it directly, or does it make sense to the passed-to
object? And you can't know for sure.

> And I learned something else:  the format mini-language is really in two 
> parts; the first part is selecting the object to be printed ({} or {3} 
> or {some_name} or {other.name} etc., etc.) and the second part is the 
> format spec for the object selected.

This is why I've been trying to frame this discussion in terms of
built-in format() or obj.__format__(), and get away from str.format().

> The kicker is that each object can
> specify what it knows about.  So float's treat 'f' as float, but
> something else might treat 'f' as fixed.

And some other object might consider 'f' as being part of a literal
that's always output (like datetime).