<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>On Aug 15, 2013, at 10:59 AM, Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 8/15/2013 12:27 AM, Nick Coghlan wrote:<br>
> I think Eric is overinterpreting the spec, there. While that particular<br>
> sentence requires that the empty format string will be equivalent to a<br>
> plain str() operation for builtin types, it is only a recommendation for<br>
> other types. For enums, I believe they should be formatted like their<br>
> base types (so !s and !r will show the enum name, anything without<br>
> coercion will show the value) .<br>
<br>
</div></div>I don't think I'm over-interpreting the spec (but of course I'd say<br>
that!). The spec is very precise on the meaning of "format specifier":<br>
it means the entire string (the second argument to __format__). I'll<br>
grant that in the sentence in question it uses "format specification",<br>
not "format specifier", though.<br>
<br>
I think this interpretation also meshes with builtin-in "format": with<br>
no format_spec argument, it uses an zero-length string as the default<br>
specifically to get the str(obj) behavior.<br>
<br>
Using bool as an example because it's easier to type:<br>
<br>
>>> format(True)<br>
'True'<br>
>>> format(True, '10')<br>
' 1'<br>
<br></blockquote><div><br></div><div>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?<br></div></div></div></div></div></blockquote><div><br></div>Oh, I completely agree that it doesn't make much sense, and is surprising. I was just trying to explain why we see the current behavior. <div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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".<br></div></div></div></div></div></blockquote><div><br></div>Agreed. </div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>For IntEnum, being in control of __format__ and being a new class, I suppose we can create any behavior we want here. </div></div></div></div></div></blockquote><div><br></div>Right. That's the intent. I'd personally be okay with checking for int format codes (bdxX, etc.) and treating it as an int, otherwise a string. As I've pointed out, it's slightly fragile, and there are a few cases where a valid int format spec will give an error when treating it as a string, but that doesn't bother me. </div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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 ;-)<br></div></div></div></div></div></blockquote><div><br></div>I don't think there's much we can do, unfortunately. I think bool should work the same as the proposed IntEnum changes, but that's an incompatible change. </div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div>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.</div></div></div></div>
</div></blockquote><br></div></div><div>I'm okay with that. </div><div><br></div><div>Eric.</div><div><br></div></body></html>