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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
