<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 14, 2013 at 4:01 PM, Serhiy Storchaka <span dir="ltr"><<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">15.08.13 01:07, Ethan Furman написав(ла):<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 From <a href="http://bugs.python.org/issue18738" target="_blank">http://bugs.python.org/<u></u>issue18738</a>:<br>
</blockquote>
<br>
Actually the problem not only in IntEnum, but in any in subclass.<br>
<br>
Currently for empty format specifier int.__format__(x, '') returns str(x). But __str__ can be overloaded in a subclass. I think that for less surprising we can extend this behavior for format specifier with the width, the alignment and the fill character but without the type char. I.e. int.__format__(x. '_<10') should return same as format(str(x), '_<10').<br>


<br>
The question remains what to do with the sign option. And with the '=' alignment.<br></blockquote></div><br></div><div class="gmail_extra">Yes, the problem here is certainly not IntEnum - specific; it's just that IntEnum is the first "for real" use case of subclassing 'int' in the stdlib. Consider this toy example:<br>

<br>class IntSubclass(int):<br>    def __str__(self):<br>        return 'foo'<br><br>s = IntSubclass(42)<br><br>print('{:}'.format(s))<br>print('{:10}'.format(s))<br><br></div><div class="gmail_extra">

This prints:<br><br>foo<br>        42<br><br></div><div class="gmail_extra">Which is, IMHO, madness.<br><br>In the issue, Eric pointed out that PEP 3101 says "For all built-in types, an empty format specification will produce the equivalent of str(value)", and that {:10} is not an "empty format specification", but this looks much more like a simple bug to me.<br>

<br></div><div class="gmail_extra">Following the "format terminology", I consider the format specification empty when the representation type (i.e. 'd', 'x' for ints, or 's' for string) is empty. Things like field width are completely orthogonal to the interpretation of the value (in a similar vein to traditional "%10d" formatting). If the lack of the representation type is interpreted as 'd' (which seems to be the case), it should always be interpreted as 'd', even when width is given.<br>

<br>A different question is *whether* it should be interptered as 'd'. Arguably, in the presence of subclasses of 'int', this may not be desirable. But this behavior seems to be officially documented so we may not have much to do about it. (*) Well, except making it logically consistent as specified above.<br>

<br></div><div class="gmail_extra">Eli<br></div><br><div class="gmail_extra">(*) So to get the str() for sure, user code will have to explicitly force the 's' representation type - {:s}, etc. It's not a big burden, and not really different from "%s" % obj.<br>

<br><br><br></div><div class="gmail_extra"><br><br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra"><br><br><br></div></div>