[Python-3000] Immutable bytes type and dbm modules

[Greg Ewing]

Guido van Rossum wrote:
> That would imply that b"..." should return a mutable bytes object,
> which many people have objected to.

I'm still very uncomfortable about this. It's so
completely unlike anything else in the language.
I have a strong feeling that it is going to trip
people up a lot, and end up being one of the
Famous Warts To Be Fixed In Py4k.

There's some evidence of this already in the way
we're referring to it as a "bytes literal", when
it's *not* actually a literal, but a constructor.
Or at least it's a literal with an implied
construction operation around it.

> is the result of
> concatenating a mutable and an immutable bytes object mutable? Does it
> matter whether the mutable operand is first or second? Is a slice of
> an immutable bytes array immutable itself?

These are valid questions, but I don't think they're
imponderable enough to be show-stoppers.

With lists/tuples it's resolved by not allowing them
to be concatenated with each other, but that's probably
too restrictive here.

My feeling is that like should produce like, and where
there's a conflict, immutability should win. Mutable
buffers tend to be used as an internal part of something
else, such as an IOStream, and aren't exposed to the
outside, or if they are, they're exposed in a read-only
kind of way.

So concatenating mutable and immutable should give the
same result as concatenating two immutables, i.e. an
immutable. If you need to add something to the end of
your buffer, while keeping it mutable, you use extend().

This gives us

   immutable + immutable -> immutable
   mutable + immutable -> immutable
   immutable + mutable -> immutable
   mutable + mutable -> mutable  (*)

   immutable[:] -> immutable
   mutable[:] -> mutable         (*)

(*) One might argue that these should be immutable,
on the grounds of safety, but I think that would be
too surprisingly different from the way other mutable
sequence work.

--
Greg