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

Eli Bendersky eliben at gmail.com
Thu Aug 15 16:59:21 CEST 2013

On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith <eric at trueblade.com> wrote:

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 formatspec 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' Eric, which-ever way you interpret the spec, the above violates the least-surprise principle; do you agree? It's easily one of those things that makes the "WTF, Python?" lists. Do you disagree?

Unfortunately, I don't think there's a lot we can do about it now. It's a design mistake, locked with backwards compatibility until "Python 4".

For IntEnum, being in control of format and being a new class, I suppose we can create any behavior we want here. Can we do more? Is it even conceivable to rig the boolean sub-type to change this behavior to be more rational? I suspect that no, but one can hope ;-) And in any case, the documentation has to be tightened a bit formally to express what we mean exactly, how it translates to the behavior of builtin types, and what is allowed for custom types.

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130815/580366bc/attachment.html>

More information about the Python-Dev mailing list