[Python-Dev] format, int, and IntEnum

[Eli Bendersky]

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 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'
>
>
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>