[Python-Dev] PEP-298: buffer interface widening too much?
Todd Miller
jmiller@stsci.edu
Sun, 15 Dec 2002 09:37:15 -0500
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