[Python-Dev] The "lazy strings" patch [was: PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom]

"Martin v. Löwis" martin at v.loewis.de
Sat Oct 21 09:59:30 CEST 2006

Larry Hastings schrieb:
> I've significantly enhanced my string-concatenation patch, to the point
> where that name is no longer accurate.  So I've redubbed it the "lazy
> strings" patch.

It's not clear to me what you want to achieve with these patches,
in particular, whether you want to see them integrated into Python or

> The major new feature is that string *slices* are also represented with
> a lazy-evaluation placeholder for the actual string, just as
> concatenated strings were in my original patch.  The lazy slice object
> stores a reference to the original PyStringObject * it is sliced from,
> and the desired start and stop slice markers.  (It only supports step =
> 1.)

I think this specific approach will find strong resistance. It has been
implemented many times, e.g. (apparently) in NextStep's NSString, and
in Java's string type (where a string holds a reference to a character
array, a start index, and an end index). Most recently, it was discussed
under the name "string view" on the Py3k list, see


Traditionally, the biggest objection is that even small strings may
consume insane amounts of memory.

> Its ob_sval is NULL until the string is rendered--but that rarely
> happens!  Not only does this mean string slices are faster, but I bet
> this generally reduces overall memory usage for slices too.

Channeling Guido: what real-world applications did you study with
this patch to make such a claim?

> I'm ready to post the patch.  However, as a result of this work, the
> description on the original patch page is really no longer accurate:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1569040&group_id=5470&atid=305470
> Shall I close/delete that patch and submit a new patch with a more
> modern description?  After all, there's not a lot of activity on the old
> patch page...

Closing the issue and opening a new is fine.


More information about the Python-Dev mailing list