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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/5B46FTPOWDWNWDD7UL2HCDGSVPCSUUR3/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IRF6PY33LQAQXGBGBEHVWZFOAUQV7J6D/ Code of Conduct: http://python.org/psf/codeofconduct/
