On Thu, Apr 22, 2021 at 5:22 PM Stephen J. Turnbull
<[email protected]> wrote:
>
> @serhiy Moving my speculative discussion to python-ideas. CC as
> courtesy, comment from you is welcome but not necessarily expected.
>
> Serhiy Storchaka writes:
>
> > format() without format specifier and str() should return the same
> > value in general, otherwise it will confuse users.
>
> I think this is a good rule of thumb because it's a very plausible
> default for format(), and easy to explain.
>
> But then what is the purpose of format()? Why not just give str() the
> functionality of format(), and deprecate format() for future use? Or
> vice versa, format() might be the better name, but the backward
> compatibility implications given the pervasive use of str() would be
> awesome, and not in a good way.
str() is already bigger than it needs to be. It is the constructor for
string objects, but it's also able to decode a bytes-like object or
buffer, and can convert arbitrary objects to strings. It shouldn't
also be responsible for *formatting* arbitrary objects, even though
they'll end up as strings.
> Given how pervasive both str and format are, and the fact that str
> also has both .format() and .__format__ methods, I guess I'm asking
> for a lot of trouble. But this plethora of approaches to providing a
> string presentation of an object seems designed to confuse users, and
> it's not clear to me that trying to maintain str(thing) == format(thing)
> necessary helps dissolve that confusion.
>
The normal job of format() is to format something in a specific way.
>>> format(123456, "x")
'1e240'
And that's also what's going to be used in an f-string:
>>> f"{123456:x}"
'1e240'
So if you're writing an f-string and you do this:
>>> x = 123456; f"{x} {x:}"
'123456 123456'
you would expect that the empty format string, and the omitted format
string, will do the single most obvious method of formatting - just
turn it into a string in whatever way the object things appropriate.
Technically you CAN make str(x) and format(x) do different things, but
you can also mess with other expectations:
>>> class X:
... def __float__(self): return 2.5
... def __int__(self): return 4
... def __index__(self): return 6
...
>>> "hello world"[X()]
'w'
>>> int(X())
4
>>> float(X())
2.5
>>> int(float(X()))
2
I'd consider the one problem here (enums) to be a bug to be fixed,
albeit one with backward compatibility issues, and then for the rest,
just keep a general documented recommendation and leave it at that.
ChrisA
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/JUGPFEOMVUBM3EHIVEVJQ76CY5NDBCIM/
Code of Conduct: http://python.org/psf/codeofconduct/
