Is there any guarantee (or even string expectation) that the __str__ for an object won't change? [snip] *reality check*: I imagine a LOT of code out there (doctests, who know what else) does in fact expect the str() of builtins not to change -- so
Christopher Barker wrote:
this is probably dead in the water.
Regardless of whether we can improve/modify the __str__ for existing
builtin objects, I think it is definitely worthwhile to clearly establish
whether they are a part of the stable API in the first place. Users should
be able to know if they can rely on the __str__ remaining the same across
versions.
My personal preference would be for the __repr__ to be stable (since it's
already denoted as the "official" string representation, often can be used
to replicate the object and/or uniquely identify it) and for the __str__ to
be unstable/subject to change.
As for whether the __str__ of any builtin object *should* be modified is
another question entirely. I'm of the opinion that it should require
sufficient justification: the benefit in readability/utility gained from
the change by the majority of its users should outweigh the cost of
potential breakage.
If we've not provided any guarantee for the __str__ to remain the same
across versions (which is true, AFAIK [1]), the fact that some users have
chosen to rely on it doesn't seem like it should prevent any changes from
being considered at all. It just means that the changes have to be
adequately worthwhile and evaluated on a case-by-case basis.
---
[1] - I have not extensively reviewed all of the documentation for all
__str__ stability guarantees or lack thereof, but there are none in the
places where I'd expect it would be present. In particular:
https://docs.python.org/3.8/reference/datamodel.html#object.__str__ or
https://docs.python.org/3.8/library/stdtypes.html#str.
On Sun, Mar 15, 2020 at 9:30 PM Christopher Barker
On Sun, Mar 15, 2020 at 6:12 PM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Also, I'd like to note that "inf" and "-inf" (and "nan" for that matter) are not "informal". They are readable input, part of Python syntax:
% python3.8 Python 3.8.2 (default, Feb 27 2020, 19:58:50)
float("inf") inf float("-inf") -inf
which, of course is what __repr__ is supposed to do, though in this case it doesn't quite: In [11]: fp = float("inf")
In [12]: eval(repr(fp))
--------------------------------------------------------------------------- NameError Traceback (most recent call last) <ipython-input-12-4f5249ac51be> in <module> ----> 1 eval(repr(fp))
<string> in <module>
NameError: name 'inf' is not defined
So they are not "readable input, part of Python syntax", but they are part of the float API.
Anyway, Python now has two different ways to "turn this into a string":, __str__ and __repr__. I think the OP is suggesting a third, for "pretty version". But then maybe folks would want a fourth or fifth, or .....
maybe we should, instead, think about updating the __str__ for standard types.
Is there any guarantee (or even string expectation) that the __str__ for an object won't change?
I've always wondered why the standard str(some object) wasn't pretty to begin with.
As for using unicode symbols for things like float("inf") -- that would be an inappropriate for the __repr__, but why not __str__ ?
*reality check*: I imagine a LOT of code out there (doctests, who know what else) does in fact expect the str() of builtins not to change -- so this is probably dead in the water.
-CHB
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LETMD2... Code of Conduct: http://python.org/psf/codeofconduct/