[Python-Dev] PEP 298, final (?) version
Guido van Rossum
Thu, 01 Aug 2002 11:34:04 -0400
> > The only thing I consider worth changing is to rename the
> > whole stuff from 'fixed buffer interface' to 'locked buffer
> > interface', which makes more sense at the current state.
Ditto. Ready for implementation now.
> Sorry if I missed this before, but:
> > If the object never resizes or reallocates the buffer
> > during it's lifetime, this function may be NULL. Failure to call
> > this function (if it is != NULL) is a programming error and may
> > have unexpected results.
> Not sure I like this. I would prefer to put the burden of "you must provide
> a (possibly empty) release function" on the few buffer interface
> implementers than the many (ie, potentially any extension author) buffer
> interface consumers.
> I believe there is a good chance of extension authors testing against, and
> therefore assuming, non-NULL implementations of this function. OTOH, if
> every fixed buffer consumer assumes a non-NULL implementation, people
> implementing this interface will quickly see their error well before it gets
> into the wild.
> No biggie, but worth considering...
Hm, *users* of the interface would always go through this API:
int PyObject_AquireFixedReadBuffer(PyObject *obj,
const void **buffer,
int PyObject_AcquireFixedWriteBuffer(PyObject *obj,
void PyObject_ReleaseFixedBuffer(PyObject *obj);
But I'm still very concerned that if most built-in types
(e.g. strings, bytes) don't implement the release functionality, it's
too easy for an extension to seem to work while forgetting to release
the buffer. I recommend that at least some built-in types implement
the acquire/release functionality with a counter, and assert that the
counter is zero when the object is deleted -- if the assert fails,
someone DECREF'ed their reference to the object without releasing it.
(The rule should be that you must own a reference to the object while
you've aquired the object.)
For strings that might be impractical because the string object would
have to grow 4 bytes to hold the counter; but the new bytes object
(PEP 296) could easily implement the counter, and the array object too
-- that way there will be plenty of opportunity to test proper use of
--Guido van Rossum (home page: http://www.python.org/~guido/)