[Python-Dev] PEP-298: buffer interface widening too much?

Martin v. Löwis Martin v. Löwis
Sat, 14 Dec 2002 20:16:13 +0100


> I've been following the PEP-298 discussion a little, because I fear 
> eventually IAGNI.   But when I look at the proposed changes,  I can't 
> help but get the feeling that the "too wide" buffer interface just got 
> wider.  By "too wide",  I am referring to the extraneous segmentation 
> and character buffer aspects of the existing interface.  Adding three 
> more calls for the locking problem bugs me.  Doesn't anything ever get 
> simpler?

The locked buffer interface is simpler than the original buffer interface.
It does not support segmentation.

> It seems to me that the existing (3!) calls for 
> acquiring the buffer pointer can do just fine.   Except...
> 
> In the case of existing extensions,  there will certainly be no call to 
> the release function.

This is a minor problem. The major problem is that the existing protocol
does not guarantee locking. So if you find an object that supports the buffer
interface, you still don't know how long you can use the pointer 
you've received. It might become invalid after calling nearly any Python
API function.

The PEP authors believe that this can't be retroactively fixed 
by declaring the existing interfaces to be locked, and I tend to agree:
changing the docs doesn't change the code "out there".

> But is it really necessary to mess with the reference 
> counts?   I'm having a hard time imagining a situation in which the 
> reference count for a buffer goes to zero while it is locked which is 
> not a bug somewhere else.  What am I missing?  

Not sure what you are referring to here. If it is the PEP: it doesn't
tell whether reference counts should be increased. If you are referring
to my messages: I'm not saying that the reference counts should be increased.
I'm saying that the PEP does not specify what the interaction of locking
and reference counting is.

> So,  in the end,  what I'm wondering is whether there's a simpler middle 
> ground between dropping the PEP and implementing it as it stands now.   

There certainly is. The advantage of the PEP process is that there always
is a specific proposal to discuss. We only have this proposal at the moment,
so we can't discuss anything else. If you want to make a different proposal,
please propose specific wording (either as a new PEP, or as a modification
of the existing one). I can't picture precisely what it is that you are
proposing, nor what its consequences would be.

Regards,
Martin