Attached below you will find the full "lazy strings" patch, which has both "lazy concatenation" and "lazy slices".  The diff is against the current revision of the Py3k branch, #53392.  On my machine (Win32) rt.bat produces identical output before and after the patch, for both debug and release builds.

As I mentioned in a previous comment, you can read the description (and ensuing conversation) about "lazy slices" here:
http://mail.python.org/pipermail/python-dev/2006-October/069506.html

One new feature of this version: I added a method on a Unicode string, s.simplify(), which forces the string to "render" if it's one of my exotic string subtypes (a lazy concatenation or lazy slice).  My goal is to assuage fears about pathological memory-use cases where you have long-lived tiny slices of gigantic strings.  If you realize you're having that problem, simply add calls to .simplify() on the slices and the problem should go away.

As for the semantics of .simplify(), it returns a reference to the string s.  Honestly I wasn't sure whether it should return a new string or just monkey with the existing string.  Really, rendering doesn't change the string; it's the same string, with the exact same external behavior, just with different bits floating around underneath.  For now it monkeys with the existing string, as that seemed best.  (But I'd be happy to switch it to returning a new string if it'd help.)

I had planned to make the "lazy slices" patch independent of the "lazy concatenation" patch.  However, it wound up being a bigger pain that I thought, and anyway I figure the likelyhood that "lazy slices" would be accepted and "lazy concatenation" would not is effectively zero.  So I didn't bother.  If there's genuine interest in "lazy slices" without "lazy concatenation", I can produce such a thing.
File Added: lch.py3k.unicode.lazy.slice.and.concat.patch.53392.txt