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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4