[Python-Dev] Default formatting
Eric V. Smith
eric at trueblade.com
Wed Oct 26 19:44:51 EDT 2016
On 10/25/2016 5:37 AM, Serhiy Storchaka wrote:
> Classes that doesn't define the __format__ method for custom PEP 3101
> formatting inherits it from parents.
>
> Originally the object.__format__ method was designed as [1]:
>
> def __format__(self, format_spec):
> return format(str(self), format_spec)
>
> An instance is converted to string and resulting string is formatted
> according to format specifier.
>
> Later this design was reconsidered [2], and now object.__format__ is
> equivalent to:
>
> def __format__(self, format_spec):
> assert format_spec == ''
> return format(str(self), '')
>
> Non-empty format specifier is rejected.
>
> But why call format() on resulting string? Why not return resulting
> string as is? object.__format__ could be simpler (not just
> implementation, but for understanding):
>
> def __format__(self, format_spec):
> assert format_spec == ''
> return str(self)
>
> This can change the behaviour in corner case. str(self) can return not
> exact string, but string subclass with overloaded __format__. But I
> think we can ignore such subtle difference.
>
> [1] https://www.python.org/dev/peps/pep-3101/
> [2] http://bugs.python.org/issue7994
>
I don't feel strongly about this, one way or the other. As you say, it
would take an unusual case to see this behavior:
>>> class S(str):
... def __format__(self, fmt):
... return 'aha!'
...
>>> class O:
... def __str__(self):
... return S()
...
>>> format(O(), '')
'aha!'
>>>
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?
Eric.
More information about the Python-Dev
mailing list