Eric V. Smith added the comment:
Forgot to add: I haven't looked at the docs yet, but I agree they should be
clear on this issue.
The docs should say: for types that implement the documented mini-language, "s"
is the same as "". It's just that not all types implement the mini-language
Eric V. Smith added the comment:
About translating ":s" to "":
> The library seems
willing to do this for the empty format string, but not when the client
code specifically asks for a string
You're not asking for a string when you specify ":s". You're asking the object
to interpret "s"
Jason Spencer added the comment:
Then I would argue that it is at least a documentation bug. The 3.6 format
spec mini language still claims that {} is equivalent to {:s}, which now is
only conditionally true.
I would also argue that having different behavior for {} and {:s}, which
are
Eric V. Smith added the comment:
I agree this is the desired behavior, and not a bug.
Because you are not specifying a __format__ in your class, object.__format__ is
being called. By design, it does not understand any formatting specifiers,
instead reserving them for your class to
Martin Panter added the comment:
It looks like you are describing the result of Issue 7994. Documentation:
https://docs.python.org/release/3.5.3/reference/datamodel.html#object.__format__
https://docs.python.org/release/3.5.3/whatsnew/3.4.html#api-and-feature-removals
--
nosy:
New submission from Jason Spencer :
Objects with __str__ but WITHOUT __format__ are string-convertible and
default-to-str formattable. But the explicit use of '{:s}' as a format string
fails to format these objects as expected. Either it is no longer the case
that '{}' and '{:s}' are
