2017-11-21 20:22 GMT+03:00 Chris Barker <chris.barker@noaa.gov> 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 <steve@pearwood.info> 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 <victor.stinner@gmail.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 '[0])! = 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