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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
