Eric V. Smith added the comment: 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18738> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com