[Python-Dev] buffer objects

Mark Hammond mhammond@skippinet.com.au
Fri, 3 May 2002 09:40:15 +1000

[Scott, quoting Guido]
> > The buffer object was a mistake.
> >
> Bummer that you feel this way.  :-(
> It looked to me like PyBufferProcs made a small mistake by including
> bf_getsegcount() which is mostly a YAGNI in your terms.  I'm sure someone
> is actually using the segcount, but they probably wouldn't have missed it
> if it didn't exist.  A lot of code seems to assume the segcount is always
> 1.
> I thought the buffer object was on the right track (with a tiny read/write
> patch :-).

Jack chimes in:
> But I agree that a mutable
> binary array type such as the bufferobject is needed for
> efficient Python implementation of lots of things.

[Back to Scott]
> I guess I'm not getting the Python philosophy of things then.

You are not alone in this specific case.  I too thought the bufffer object
was a Good Thing(tm), and indeed the win32 extensions have good use for them
(supporting asynchronous IO on Windows for one).

It turns out that the buffer *interface* has a design flaw, best described
by using the array object as an example.  The real possibility exists that
code can use the buffer interfaces to get a pointer to writable memory for
the array.  The array may then be resized, thereby moving the buffer but
leaving the buffer pointer dangling.

So from my side of the fence, it seems the buffer interface was a mistake,
and at least 2 significant extension authors believe a r/w buffer *object*
is useful ;)

I am not too sure what to do here.  I can never remember the conversation
moving past "it was a mistake" into the realm of "and here is what we should
do instead."  As far as I can tell, this same stalemate has also prevented
any progress on the buffer interface flaw described above - no one really
knows what the "right thing" is.