[Python-Dev] format and int subclasses (Was: format, int, and IntEnum)

[Eli Bendersky]

On Wed, Aug 14, 2013 at 4:01 PM, Serhiy Storchaka <storchaka at gmail.com>wrote:

> 15.08.13 01:07, Ethan Furman написав(ла):
>
>>  From http://bugs.python.org/**issue18738<http://bugs.python.org/issue18738>
>> :
>>
>
> Actually the problem not only in IntEnum, but in any in subclass.
>
> 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').
>
> The question remains what to do with the sign option. And with the '='
> alignment.
>

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:

class IntSubclass(int):
    def __str__(self):
        return 'foo'

s = IntSubclass(42)

print('{:}'.format(s))
print('{:10}'.format(s))

This prints:

foo
        42

Which is, IMHO, madness.

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.

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.

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.

Eli

(*) 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130814/2c06b4c2/attachment.html>