[Python-3000] Lazy strings (was Re: Py3k release schedule worries)
Guido van Rossum
guido at python.org
Tue Jan 9 18:47:02 CET 2007
> > On 12/30/06, Talin <talin at acm.org> 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.)
> "Guido van Rossum" <guido at python.org> wrote:
> > 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.)
On 1/8/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> 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) )?
I wasn't referring to anything in particular; I have neither looked at
any of the discussion not at any patches. I was just stating the
expectation that indexing a sequence should take O(1) time. (I'd be
okay with an *amortized* O(1) since that is if course still O(1), as
long as it really is.)
> Was this in reference to delayed construction time overhead as in the
> case of lazy strings?
Not in particular; I was just arguing from a clean slate. Though I
guess you could argue that since construction time is curerntly O(N),
if you could win some on construction you'd have that to play with to
meet the O(1) access goal. Although of curse then you run the risk of
implementing something that doesn't have any performance benefits yet
is much more complicated, which is exactly the basis of my arguments
against all this kind of cleverness.
> Both? Neither? Something else that I've forgotten?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list