[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