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/
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