[Alex Martelli] >[Kevin Jacobs] >>[Guido van Rossum] >>>I don't like the trick of avoiding the copy if the refcount is one; >>>AFAIK it can't be done in Jython. >> >>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 > even if copysort never happens and the optimization is only for > CPython -- I don't see why an optimization being impossible in > Jython should stop CPython from making it, as long as semantics > remain compatible). It's certainly possible for C code to call > PySequence_List or whatever while holding the only reference, > and count on the returned and argument objects being distinct:-(. 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. 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. -Scott David Daniels Scott.Danies at Acm.Org
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