On Nov 3, 2019, at 13:01, Anders Hovmöller <bo...@killingar.net> wrote: > > Well, the last part requires that print can coerce bytes to str, not strictly > that it must do so via str(). repr() should return b'foo' but str() could > have returned <bytes object at 0x6363737>.
That would be very confusing. When they differ, it’s always repr that returns something like <bytes object at 0x6363737>, as object.__repr__ gives. The only time you get that from str is on types without a __str__ method that fall back to __repr__. Generally, objects that have an obvious and unambiguous representation as code that could be pasted into the REPL and get back and equal object use that for repr, and everything else uses angle brackets (which will always be a SyntaxError if you try to paste it at the REPL) with at least the type and id and sometimes other stuff. Objects that have a better representation for normal humans, even if it may be ambiguous or incomplete for programmers, use that for str, otherwise they just fall back to the repr. There are a few exceptions (e.g.; the repr of an infinitely recursive list isn’t eval-able), but I don’t think there’s any type that does the opposite of the usual. So, since there’s no good human-readable representation for bytes (without knowing what encoding it is, or whether it’s non-text data), it falls back to the repr. Also, this feature actually saved me time in a 2-to-3 port. A bunch of the code had been written by one of those people who puts str(x) all over the place even when x is already guaranteed to be a str, like buf = str(sock.recv(bufsize)). So there are bugs all over the place in 3.x, even after going through all the 2to3 flags and trying to guess what this call to str was meant to do. And being able to search the output and logs for “b'” worked just as well as being able to search for your “<bytes” would have, but the fact that we also got the actual bytes in that log made it easier to guess where it came from. (It helped that one main source of bytes was UTF-16, and the \0 after each ASCII byte is pretty easy to spot…) _______________________________________________ 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/VIKWLWLDX3JKQOUGEUZ3EOX5T5JL7YBJ/ Code of Conduct: http://python.org/psf/codeofconduct/
