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

Eli Bendersky eliben at gmail.com
Thu Aug 15 05:23:19 CEST 2013

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>

More information about the Python-Dev mailing list