> >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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4