[Python-Dev] PEP 298, final (?) version
Thomas Heller
thomas.heller@ion-tof.com
Thu, 1 Aug 2002 16:19:37 +0200
> > 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