Christopher Barker wrote: > 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 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 <python...@gmail.com> wrote: > On Sun, Mar 15, 2020 at 6:12 PM Stephen J. Turnbull < > turnbull.stephen...@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-le...@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/LETMD2YBFFA5MAI6H2RXPOEUKA6U77KY/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/J6Q24KWPQQLA35VPORGB5HXPOQORC5QL/ Code of Conduct: http://python.org/psf/codeofconduct/
