> On 3 Nov 2019, at 13:31, Andrew Barnert <abarn...@yahoo.com> wrote: > > 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.
Why? Because you then say: > 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__. And str of bytes deviate from this in that it returns what should be a repr, not a str. > 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, Agreed. > 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. Sure. > 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. Sure. But they don't have to. So that seems like it doesn't matter to the discussion. > 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…) Ah. Now finally an argument. Yes that was better than just <bytes...>. But if str(bytes) raised and repr(bytes) did not and print(bytes) used repr(), then you wouldn't have had to look at the bytes to guess where it came from, you'd get a crash at the place where the problem was. Which would be much better! / Anders _______________________________________________ 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/6KSWXJN7CCFE6PFPNQEDBXXOAI7V56XI/ Code of Conduct: http://python.org/psf/codeofconduct/
