[Python-Dev] why The Trick can't work
Alex Martelli
aleaxit at yahoo.com
Sun Oct 19 06:25:34 EDT 2003
On Sunday 19 October 2003 00:44, Scott David Daniels wrote:
...
> >>There is also a problem with the strategy if if gets called by a
> >>C only extension. It is perfectly feasible for a C extension to
> >>hold the reference to an object, call the copying sort (directly
> >>or indirectly), and then be very surprised that the copy did not
> >>take place.
> >
> > Alas, I fear you're right. Darn--so much for a possible little but
> > cheap optimization (which might have been neat in PySequence_List
...
> I'm afraid I'm confused here. If the C code is like:
>
> ... at this point PTR refers to an object with refcount 1
> OTHER = <invoke sortcopy>(PTR)
> ... Then it might be that PTR == OTHER ...
>
> What possible harm could come? The C code should expect a
> sortcopy method to recycle the object referred to by PTR
> if "the Trick" isn't used.
No! The point of a sorted *copy* is to NOT "recycle the object",
else you'd just call PyList_Sort. There is no precedent for a C
function documented as "may steal a reference if it feels like it
but need not". Without The Trick, PTR* is unchanged -- so it
cannot be changed by The Trick without exposing weirdness
for such a C-coded extension in these circumstances.
I think such a C-coded extension must ALREADY avoid calling
filter under such circumstances (haven't tested yet) -- and that
undocumented issue is bad enough already...
> I am a trifle confused about
> what harm occurs. Seems to me that list(v) (and alist[:])
> could quite happily implement "the Trick" without fear of
> failure.
Yes, but they're not "C-coded extensions". These Python expressions cause
PySequence_List and PyList_CopySlice respectively to be called (in the end
it always goes rapidly to the copy-slice one), and it's not trivial to find
a spot that is NOT callable by a C-coded extension where The Trick could
live safely.
Alex
More information about the Python-Dev
mailing list