[Python-Dev] format, int, and IntEnum
Eric V. Smith
eric at trueblade.com
Thu Aug 15 12:03:56 CEST 2013
On 8/15/2013 12:27 AM, Nick Coghlan wrote:
> I think Eric is overinterpreting the spec, there. While that particular
> sentence requires that the empty format string will be equivalent to a
> plain str() operation for builtin types, it is only a recommendation for
> other types. For enums, I believe they should be formatted like their
> base types (so !s and !r will show the enum name, anything without
> coercion will show the value) .
I don't think I'm over-interpreting the spec (but of course I'd say
that!). The spec is very precise on the meaning of "format specifier":
it means the entire string (the second argument to __format__). I'll
grant that in the sentence in question it uses "format specification",
not "format specifier", though.
I think this interpretation also meshes with builtin-in "format": with
no format_spec argument, it uses an zero-length string as the default
specifically to get the str(obj) behavior.
Using bool as an example because it's easier to type:
>>> format(True, '10')
I think it was Guido who specifically wanted this behavior, although of
course now I can't find the email about it. The closest I could find is
Talin (PEP 3101 author) requesting it:
says 'A general convention is that an empty format string ("") produces
the same result as if you had called str() on the value. A non-empty
format string typically modifies the result.' Again, the wording is not
very tight, but it is talking about format specifiers here.
I still think the best thing to do is implement __format__ for IntEnum,
and there implement whatever behavior is decided. I don't think changing
the meaning of existing objects (specifically int here) is a good course
Whether we can implement code that breaks existing format specifiers
that would work for "int" but won't work for "str" is open to debate.
See http://bugs.python.org/msg195225. Personally, I think it's okay, but
if you think IntEnum needs to be an exact replacement for int, maybe not.
More information about the Python-Dev