[Python-3000] Immutable bytes type and dbm modules

[Talin]

Guido van Rossum wrote:

> Assuming you weren't being sarcastic, array('B') and bytes() are very
> close except bytes have a literal notation and many string-ish
> methods. The buffer objects returned by the buffer() builtin provide a
> read-only view on other objects that happen to have an internal
> buffer, like strings, bytes, arrays, PIL images, and numpy arrays.
> Lists of integers don't have the property that the other three share
> which is that their C representation is a contiguous array of bytes
> (char* in C). This representation is important because to do efficient
> I/O in C you need char*.

I've been following the discussion in a cursory way, and I can see that 
there is a lot of disagreement and confusion around the whole issue of 
mutable vs. immutable bytes.

If it were up to me, and I was starting over from scratch, here's the 
design I would create:

1) I'd reserve the term 'bytes' to refer to an immutable byte string.

2) I would re-purpose the existing term 'buffer' to refer to a mutable, 
resizable byte buffer.

Rationale: "buffer" has been used historically in many computer 
languages to refer to a mutable area of memory. The word 'bytes', on the 
other hand, seems to imply a *value* rather than a *location*, and 
values (like numbers) are generally considered immutable.

3) Both 'bytes' and 'buffer' would be derived from an abstract base 
class called ByteSequence. ByteSequence defines all of the read-only 
accessor methods common to both classes.

4) Literals of both types are available - using a prefix of small 'b' 
for bytes, and capitol B for 'buffer'.

5) Both 'bytes' and 'buffer' would support the 'buffer protocol', 
although in the former case it would be read-only. Other things which 
are not buffers could also support this protocol.

6) Library APIs that required a byte sequence would be written to test 
vs. the abstract ByteSequence type.

7) Both bytes and buffer objects would be inter-convertible using the 
appropriate constructors.

-- Talin