Josiah Carlson wrote: > Perhaps I missed something about the concatenation implementation, but in > order to prevent the rendering of lazy concatenation objects, shouldn't you > need to keep a reference and pointer to the left and right > strings/concatenation objects? This isn't the same as a (small) slice > holding onto a reference to a (big) string, but there is still an object > lifetime consideration. > You didn't miss anything--your summary is correct. The lazy concatenation object holds references to both the left and right objects. Since this isn't wasting memory, and it doesn't change Python's memory allocation behavior in any significant way (apart from the aforementioned able-to-fail APIs), I omitted it.
> P.P.S. I'm not certain, but I believe the V2 lazy slicing could be cleaned up > with the use of weak references. That's an interesting point. They would simplify the implementation slightly, though perhaps not as much as you'd hope. I think I'd still need much of the existing code in order to solve the really nasty boundary case (when the original string goes away during low-memory conditions). Also consider: weak references would add their own overhead to the implementation. In particular, weakref callbacks are on Python objects, so it always builds a tuple and calls via PyObject_Call(). In the final analysis I'm not sure a weakref-based implementation would make V2 lazy slicing any more palatable to the discerning Py3k core dev community. /larry/ _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
