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

[Kevin Jacobs]

On Sun, 19 Oct 2003, Alex Martelli wrote:
> On Sunday 19 October 2003 00:44, Scott David Daniels wrote:
> > 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.

Even worse, the C code may not know that it is calling a copy sort, and
assume that the new object is distinct from the original.  I'm not saying
that such C code is optimal, or even correct, but I suspect that a great
deal of it does exist.  Even worse than that is the possibility that a list
subclass can change the behavior of copysort in such a way that it changes
the refcount of the object and within the copysort call.  This could
confound any code naively attempting to use refcounts to detect the
"optimization", either by masking a copy or masking the lack of a copy.

So I'm not saying that it isn't a neat idea, but it does present more
problems than it solves.  Besides that, I find it no burden to copy then
sort, or write a utility function that does so -- and I manage a project
with well over 1 million lines of Python/C-extension code at the moment.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (440) 871-6725 x 19         E-mail: jacobs at theopalgroup.com
Fax:   (440) 871-6722              WWW:    http://www.theopalgroup.com/