[Python-Dev] why The Trick can't work

[Alex Martelli]

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