The attached patch demonstrats a possible implementation for deferred string addition. The idea is to have str.__add__ save references to its inputs rather that do the concatenation immediately. The moment some other method needs the full string, it is generated recursively so that the whole concatenation can be done with a single join.
Logged In: YES user_id=764593 There is an implicit assumption that any component/part with its own 'components' attribute will be another UserString (or, at the very least, will act like one when traversed). Would it be better to check whether the subobject actually is a UserString (since new-style objects can freely use multiple inheritance), or to do some sort of guard in add? (Perhaps immediately stringifying anything with a components attribute that is not a UserString?)
Logged In: YES user_id=80475 The patch is not meant to be loaded to UserString. Rather it is a proof-of-concept demonstration of how deferred string addition would work. Even it pure python form, it shows how to convert an O(n**2) process to O(n). If the concept is approved, the goal is to alter the C code for stringobject.c, unicodeobject.c, and to make a more thorough version for UserString.
