[Python-Dev] PEP 298, final (?) version

[Guido van Rossum]

> > 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.
> 
> Agreed.

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,
                                           size_t *buffer_len);

        int PyObject_AcquireFixedWriteBuffer(PyObject *obj,
                                             void **buffer,
                                             size_t *buffer_len);

        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
the protocol.

--Guido van Rossum (home page: http://www.python.org/~guido/)