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 <[email protected]>
<http://bugs.python.org/issue18738>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
