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?
">

(original) (raw)




On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith <eric@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