[Python-3000] Immutable bytes type and dbm modules
Guido van Rossum
guido at python.org
Tue Aug 7 16:42:42 CEST 2007
On 8/6/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> >>> The most efficient representation of immutable bytes is quite different
> >>> from the most efficient representation of mutable bytes.
> >>
> >> In what way?
> >
> > Well, in some runtime environments (I'm not sure about Python), for
> > immutables you can combine the object header and the bytes array into a
> > single allocation. Further, the header need not contain an explicit
> > pointer to the bytes themselves, instead the bytes are obtained by doing
> > pointer arithmetic on the header address.
>> Hmm. That assumes that the mutable bytes type also supports changes to
> its length. I see that the Python bytes type does that, but I don't
> think it's really necessary - I'm not even sure it's useful.
It is. The I/O library uses it extensively for buffers: instead of
allocating a new object each time some data is added to a buffer, the
buffer is simply extended. This saves the malloc/free calls for the
object header, and in some cases realloc is also free (there is some
overallocation in the bytes type and sometimes realloc can extend an
object without moving it, if the space after it happens to be free).
> For a bytes array, you don't need a separate allocation, and it still
> can be mutable.
>> > So in other words, the in-memory layout of the two structs is different
> > enough that attempting to combine them into a single struct is kind of
> > awkward.
>> ... assuming the mutable bytes type behaves like a Python list, that
> is. If it behaved like a Java/C byte[], this issue would not exist.
There is no requirement to copy bad features from Java.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list