> > 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. > [Mark] > 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... I thought nobody would call these functions directly, but only through the PyObject_AcquireBuffer/PyObject_ReleaseBuffer functions, but maybe you're right. So probably it should be required that the release function must be implemented if any of the aquire functions is implemented. We could even implement the lockcount in every fixed buffer object even if it does no actual locking, and issue a warning or raise an exception in the destructor if it is not zero. (Or can we somehow prevent clients from calling these functions without going through the PyObject_ funcs?) Thomas
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