> **Open Issue:** I'm undecided on whether indexing bytes and buffer
> objects should return small ints (like the bytes type in 3.0a1, and
> like lists or array.array('B')), or bytes/buffer objects of length 1
> (like the str type). The latter (str-like) approach will ease porting
> code from Python 2.x; but it makes it harder to extract values from a
> bytes array.
The protocol encoding and decoding world calls these "octet strings" and
it makes encoding and decoding discussions a lot easier. ASN.1 calls
them that and it's a good thing.
In that frame of mind, the first element is an octet, and while Python
would not add a new datatype, just like it doesn't have one for
character, it would be an unsigned integer in range(256).
> Methods
> -------
>
> The following methods are supported by bytes as well as buffer, with
> similar semantics. They accept anything that implements the PEP 3118
> buffer API for bytes arguments, and return the same type as the object
> whose method is called ("self"):
First, please enforce that where these functions take a "string"
parameter that they require an octet or octet string (I couldn't find
what kinds of arguments these functions require in PEP 3118):
>>> x = b'123*45'
>>> x.find("*")
TypeError: expected an octet string or int
>>> x.find(b'*')
3
>>> x.find(42)
3
Second, Please add slice operations and .append() to mutable octet strings:
>>> x[:0] = b'>' # start of message
>>> x.append(sum(x) % 256) # simple checksum
Joel
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
