On 27Oct2016 0251, Serhiy Storchaka wrote:
On 27.10.16 02:44, Eric V. Smith wrote:
But on the other hand, the existing behavior is well specified and has
been around since object.__format__ was added. I'm not sure it needs
changing. What's the harm in leaving it?
More complicated code. And maybe this behavior is less intuitive. It
contradicts the documentation.
From the documentation of the format() builtin [1]:
"The default format_spec is an empty string which usually gives the same
effect as calling str(value)."
From the description of the format specification mini-language [2]:
"A general convention is that an empty format string ("") produces the
same result as if you had called str() on the value."
[1] https://docs.python.org/3/library/functions.html#format
[2] https://docs.python.org/3/library/stdtypes.html#str.format
The only point where this bothers me is that alignments don't work:
>>> class F: pass
...
>>> '{}'.format(F())
'<__main__.F object at 0x02148AFE6B70>'
>>> '{:100}'.format(F())
Traceback (most recent call last):
File "", line 1, in
TypeError: non-empty format string passed to object.__format__
>>> '{:<100}'.format(F())
Traceback (most recent call last):
File "", line 1, in
TypeError: non-empty format string passed to object.__format__
You need to explicitly include '!s' to be able to align it, which then
means overriding __format__ in that class later won't have any effect.
>>> '{!s:<100}'.format(F())
'<__main__.F object at 0x02148AFEE240>
'
Having the default __format__ behave like this makes me happiest:
... def __format__(self, fmt):
... return format(str(self), fmt)
My 2c. YMMV. etc.
Cheers,
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
