> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4