[Python-3000] Immutable bytes type and dbm modules (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Aug 8 03:25:43 CEST 2007


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



More information about the Python-3000 mailing list