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

[Todd Miller]

Martin v. Löwis wrote:

>Todd Miller <jmiller@stsci.edu> writes:
>
>  
>
>>Point taken.  What I'm really proposing is this:
>>    
>>
>
>Thanks for detailing this proposal. I now agree with your assumption
>that missing release calls might cause problems; I'd expect that they
>indeed will cause problems in many applications.
>
Thanks for reading it.  

>
>The main issue is the interaction with ParseTuple, the 's', 'w', and
>'t' converters invoke a buffer operation, after which (under your
>proposal) the object is locked, there is no corresponding release
>call, and no place to put such a call.
>
I've used this aspect of PyArg_ParseTuple,  but forgot about it.    I 
was thinking that you're right,  the original object is "gone", we're 
stuck.   But...  it's still (in all probability) lying around in the arg 
tuple,  so some sort of PyArg_ReleaseBuffers is possible.   It could 
even be a near-carbon-copy of the PyArg_ParseTuple which "lost" the 
object to begin with,  to make the book keeping easy:

PyArg_ParseTuple(args, "iw#Os",  &someInt,  &writeableptr, 
&writeablesize, &someobject, &readableptr)

becomes:

PyArg_ReleaseBuffers(args, "iw#Os")

at exit time.   The parse spec defines which parts of the tuple to 
release, and which not to release.  Anything which is not w,s, or t gets 
skipped.  w,s,t are released.  With this call,  it becomes possible to 
"fix"  the PyArg_ParseTuple case.

Incidentally,  does PEP-298 solve this now?   (I think the answer is no. 
   PEP-298 is just using a different approach to "phased introduction" 
by leaving the original problem fully exposed in backwards compatability 
mode.  Or am I missing something here too?)

>
>So, once you have passed an array to some C function expecting a
>char*, you cannot extend the array anymore.
>
Well,  this does sound bad,  but I was assuming the core and library 
would be "fixed" at the first introduction of locking, and the only 
problem would be with non-conforming extensions.    I now think that 
"lock violations" might be better handled using the warning framework, 
defaulting to a one time warning.  

Todd