[Python-Dev] format, int, and IntEnum (original) (raw)

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) 'True' format(True, '10') ' 1'

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: http://mail.python.org/pipermail/python-3000/2007-August/010121.html.

http://docs.python.org/3/library/string.html#format-specification-mini-language 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 of action.

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.

-- Eric.



More information about the Python-Dev mailing list