[Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?] (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Feb 15 07:44:12 CET 2006

Ron Adam wrote:

My first impression and thoughts were: (and seems incorrect now)

bytes(object) -> byte sequence of objects value Basically a "memory dump" of objects value.

As I understand the current intentions, this is correct. The bytes constructor would have two different signatures:

(1)   bytes(seq) --> interprets seq as a sequence of
                     integers in the range 0..255,
                     exception otherwise

(2a)  bytes(str, encoding)     --> encodes the characters of
(2b)  bytes(unicode, encoding)     the string using the specified
                                   encoding

In (2a) the string would be interpreted as containing ascii characters, with an exception otherwise. In 3.0, (2a) will disappear leaving only (1) and (2b).

And I was thinking a bytes argument of more than one item would indicate a byte sequence.

bytes(1,2,3) -> bytes([1,2,3])

But then you have to test the argument in the one-argument case and try to guess whether it should be interpreted as a sequence or an integer. Best to avoid having to do that.

Which is fine... so ???

b = bytes(0L) -> bytes([0,0,0,0])

No, bytes(0L) --> TypeError because 0L doesn't implement the iterator protocol or the buffer interface.

I suppose long integers might be enhanced to support the buffer interface in 3.0, but that doesn't seem like a good idea, because the bytes you got that way would depend on the internal representation of long integers. In particular,

bytes(0x12345678L)

via the buffer interface would most likely not give you bytes[0x12, 0x34, 0x56, 0x78]).

Maybe types should grow a bytes method?

Greg

More information about the Python-Dev mailing list