Eric V. Smith wrote:
> Debugging. I sometimes do things like: print('\n'.join(str(thing) for
thing in lst)), or various variations on this. This is especially useful >
when maybe something in the list is a bytes object where I was expecting a
string.
>
> I'm not saying it's the best practice, but calling str() on an object is
a currently a guaranteed way of making a string out of it, and I
> don't think we can change it.
I could see that being useful actually. Regardless of "best practices",
it's reasonably common to indiscriminately convert a large sequence of
objects into strings for basic inspection purposes. There may be better
means of debugging, but I wouldn't want to prevent that option entirely for
bytes objects.
But, I suspect that backwards compatibility might be too much of a concern
here for the change to be worthwhile either way. Adding the TypeError or
even gradual deprecation would more than likely lead to a decent amount of
code breakage and maintenance; and changing it to implicitly perform a
UTF-8 encoding would very likely cause some confusion and debugging
difficulties for those who frequently inspect via string conversion.
Thanks for the insight.
On Mon, Dec 16, 2019 at 3:43 AM Eric V. Smith <e...@trueblade.com> wrote:
> On 12/16/2019 3:05 AM, Kyle Stanley wrote:
>
> Chris Angelico wrote:
> > ANY object can be passed to str() in order to get some sort of valid
> > printable form. The awkwardness comes from the fact that str()
> > performs double duty - it's both "give me a printable form of this
> > object" and "decode these bytes into text".
>
> While it does make sense for str() to be able to give some form of
> printable form for any object, I suppose that I just don't consider something
> like this: "b'\\xc3\\xa1'" to be overly useful, at least for any practical
> purposes. Can anyone think of a situation where you would want a string
> representation of a bytes object instead of decoding it?
>
> Debugging. I sometimes do things like: print('\n'.join(str(thing) for
> thing in lst)), or various variations on this. This is especially useful
> when maybe something in the list is a bytes object where I was expecting a
> string.
>
> I'm not saying it's the best practice, but calling str() on an object is a
> currently a guaranteed way of making a string out of it, and I don't think
> we can change it.
>
> Eric
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/5B46FTPOWDWNWDD7UL2HCDGSVPCSUUR3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/IRF6PY33LQAQXGBGBEHVWZFOAUQV7J6D/
Code of Conduct: http://python.org/psf/codeofconduct/
