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

[Martin v. Löwis]

> >We could even provide a Generic function which
> >delegates the new get functions to the existing ones, accessing
> >segment zero.
> >  
> >
> Wouldn't this require more information about the lock implementation? 

The generic function would just invoke the unlocked routine, and thus
it would only be applicable for types that don't require locking (as
the underlying memory can't move, anyway). If there must be a true
lock count in the implementation, you couldn't use the generic wrapper.

I don't know how useful that would be, as I don't know whether the typical
buffer-supporting object has movable memory or fixed memory; I'd expect that
immutable object typically have fixed memory, and mutable objects typically
have relocatable memory. So only immutable types could use the wrapper.

>  As PEP-298 stands,  I thought that was left up to the buffered type. 
>  It might make sense to change the locking getpointer fields into lock, 
> and release into unlock.  Then compose the primitive operations in the 
> wrapper as you suggested.   That wouldn't fix the size_t problem though.

Ah, right - this would be another restriction for using the generic wrapper.
Perhaps then there is really no point in having it.

> >I now recall what the issue is: you can't assume that modifying the
> >argument tuple object to record resources is feasible, as this breaks
> >apply (where in every case the user allocates a tuple, and where this
> >is a plain old tuple).
> >  
> >
> Is the efficiency of apply() so critical that a conversion is ruled out?

I would think so, yes: allocating objects is one of the most costly operation
in Python. It is more efficient now that we have pymalloc, but still.

There is also the in-C calls to functions that use Py_BuildValue, then
PyObject_Call; returning an enhanced tuple from BuildValue might break
existing code, yet copying the tuples inside PyObject_Call (if needed)
would add a price there, too.

So I'm now leaning towards not requiring a new type.

> Way over my head here...  I guess the point is that arg tuples aren't 
> the only point of attack.

No, they really are the issue. However, I cannot guarantee that ParseTuple
is always called with enhanced tuples, so the correctness this is meant to
provide isn't really provided.

Regards,
Martin