2017-11-21 20:22 GMT+03:00 Chris Barker email@example.com wrote:
But the way you did your example indicates that:
bytes((42, 43, 44, 45, 46))
would be an even better __repr__, if the goal is to make it clear and easy that it is a "container of integers from 0 to 255"
I've been programming since quite some time ago, and hex has NEVER come naturally to me :-)
Yes, it is better, but it seemed too radical to me:)
2017-11-21 18:16 GMT+03:00 Steven D'Aprano firstname.lastname@example.org wrote:
I'd rather give bytes a hexdump() method that returns a string:
'2a 2b 2d 2e 2f'
(possibly with optional arguments to specify the formatting).
Since Python 3.5 bytes has a .hex() method, the same as yours .hexdump() but without spaces. But still it is a string.
2017-11-21 18:38 GMT+03:00 Victor Stinner email@example.com:
While it may shock you, using bytes for "text" makes sense in some areas. Please read the Motivation of the PEP 461: https://www.python.org/dev/peps/pep-0461/#motivation
It does not, because it is really useful feature. But rather, ascii was made so that it would fit into a byte, and not vice versa.
Nevertheless, bytes are the strangest object in Python. It looks like a string (which contains only ascii), but it is not a string, because if you index, it does not return a byte -> bytes (b'123 ')! = Bytes (b'1'). May be it is closer to tuple, it is also immutable, but bytes(3) creates a sequence b '\ x00 \ x00 \ x00', but tuple not (and what the hell is b'\x00\x00\x00'?). Maybe it has some relationship to integers but int(b'1') == 1 when bytes([int(49)]) == b'1', i.e with integers it is not a friend either.
It is bytes...
With kind regards, -gdg