[Python-3000] Immutable bytes type and dbm modules (original) (raw)
Jim Jewett jimjjewett at gmail.com
Tue Aug 7 23:14:00 CEST 2007
- Previous message: [Python-3000] Immutable bytes type and dbm modules
- Next message: [Python-3000] Immutable bytes type and dbm modules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 8/7/07, Guido van Rossum <guido at python.org> wrote:
If b"..." is immutable, the immutable bytes type is in your face all the time and you'll have to deal with the difference all the time.
There is a conceptual difference between the main use cases for mutable (a buffer) and the main use cases for immutable (a protocol constant).
I'm not sure why you would need a literal for the mutable version. How often do you create a new buffer with initial values? (Note: not pointing to existing memory; creating a new one.)
E.g. is the result of concatenating a mutable and an immutable bytes object mutable? Does it matter whether the mutable operand is first or second?
I would say immutable; you're taking a snapshot. (I would have some sympathy for taking the type of the first operand, but then you need to worry about + vs +=, and whether the start of the new object will notice later state changes.)
Is a slice of an immutable bytes array immutable itself?
Why wouldn't it be?
The question is what to do with a slice from a mutable array. Most of python uses copies (and keeps type, so the result is also mutable). Numpy often shares state for efficiency. Making an immutable copy makes sense for every sane use case I can come up with. (The insane case is that you might want to pass output_buffer[60:70] to some other object for its status output.)
-jJ
- Previous message: [Python-3000] Immutable bytes type and dbm modules
- Next message: [Python-3000] Immutable bytes type and dbm modules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]