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
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.
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
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 0x000002148AFE6B70>' '{:100}'.format(F()) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: non-empty format string passed to object.__format__ '{:<100}'.format(F()) Traceback (most recent call last): File "<stdin>", line 1, in <module> 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 0x000002148AFEE240> '
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
On 27.10.16 19:59, Steve Dower wrote:
Having the default __format__ behave like this makes me happiest:
.... def __format__(self, fmt): .... return format(str(self), fmt)
My 2c. YMMV. etc.
See issue7994 [1] for arguments against this. [1] http://bugs.python.org/issue7994
On 25.10.16 12:37, 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
What is the decision about this?
On 01/22/2017 11:48 AM, Serhiy Storchaka wrote:
On 25.10.16 12:37, 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
Can you give an example of this corner case? -- ~Ethan~
participants (4)
-
Eric V. Smith
-
Ethan Furman
-
Serhiy Storchaka
-
Steve Dower