"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.)
If I understood the lazy string stuff, this requirement more or less kills them (at least with the rope-based implementation that I last paid attention to), unless we consider ammortization arguments. It also seems to kill any attempts to make the underlying representation always ucs-2, with surrogate pairs working the way they were intended (pairs are seen as one character, not two), as the algorithm/structure involved got O(log n) performance for s[i] on strings with surrogate pairs, O(1) otherwise. This does not, however, preclude the construction of a wrapper type that implements lazy strings, views, etc., or its packaging as a 3rd party module for Python 2.x and/or 3.x . - 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
