<br><br><div><span class="gmail_quote">On 8/30/06, <b class="gmail_sendername">Jack Diederich</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Aug 30, 2006 at 08:56:03PM -0700, Bob Ippolito wrote:<br>> > and also based on the cET (and NFS) experiences, it wouldn't surprise me<br>> > if a naive 32-bit text string implementation will, on average, slow things down
<br>> > *more* than any string view implementation can speed things up again...<br>> ><br>> > (in other words, I'm convinced that we need a polymorphic string type. I'm not<br>> > so sure we need views, but if we have the former, we can use that mechanism to
<br>> > support the latter)<br>><br>> +1 for polymorphic strings.<br>><br>> This would give us the best of both worlds: compact representations<br>> for ASCII and Latin-1, full 32-bit text when needed, and the
<br>> possibility to implement further optimizations when necessary. It<br>> could add a bit of complexity and/or a massive speed penalty<br>> (depending on how naive the implementation is) around character<br>> operations though.
<br><br>Having watched Fredrik casually double the speed of many str and unicode<br>operations in a week I'm easily +1 on whatever he says. Bob's support<br>makes that a +2, he struck me as quite sane too.<br><br>That said can you guys expand on what polymorphic means here in particular?
</blockquote><div><br>I think that Bob alluded to it. They are talking about a string that uses 1 byte-per-character for ASCII text, perhaps two bytes-per-character for a mix of Greek and Russian text and four bytes-per-character for certain Chinese or Japanese strings. From the Python programmers' point of view it should be an invisible optimization.
<br><br> Paul Prescod<br><br></div></div>