"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > On 12/30/06, Talin <[EMAIL PROTECTED]> wrote: > > Maybe this would be a good time to review, or at least restate, the > > specific plans for strings in Py3K? I know that there's been a great > > deal of discussion on this, but a lot of that discussion took place > > *before* Larry's work (specifically, before a number of people in this > > group drank the lazy-strings KoolAid.) > > The *only* think that I care about is that we end up with a single > string type named 'str' that has the same semantics (and some of the > same performance) as the current Unicode strings. (I mention > performance because s[i] should remain an O(1) operation.)
Could I get some clarification on this point? Were you referring to the structure I had offered that would allow the proper handling of surrogate pairs in the case of s[i], which would result in access time being a function of the number of surrogates in the string (in the worst case O(log num_surrogates) )? Was this in reference to delayed construction time overhead as in the case of lazy strings? Both? Neither? Something else that I've forgotten? - Josiah _______________________________________________ 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
