<br><br><div><span class="gmail_quote">On 8/30/06, <b class="gmail_sendername">Jack Diederich</b> &lt;<a href="mailto:jack@psynchronous.com">jack@psynchronous.com</a>&gt; 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>&gt; &gt; and also based on the cET (and NFS) experiences, it wouldn't surprise me<br>&gt; &gt; if a naive 32-bit text string implementation will, on average, slow things down
<br>&gt; &gt; *more* than any string view implementation can speed things up again...<br>&gt; &gt;<br>&gt; &gt; (in other words, I'm convinced that we need a polymorphic string type.&nbsp;&nbsp;I'm not<br>&gt; &gt; so sure we need views, but if we have the former, we can use that mechanism to
<br>&gt; &gt; support the latter)<br>&gt;<br>&gt; +1 for polymorphic strings.<br>&gt;<br>&gt; This would give us the best of both worlds: compact representations<br>&gt; for ASCII and Latin-1, full 32-bit text when needed, and the
<br>&gt; possibility to implement further optimizations when necessary. It<br>&gt; could add a bit of complexity and/or a massive speed penalty<br>&gt; (depending on how naive the implementation is) around character<br>&gt; 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.&nbsp;&nbsp;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[1] 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>&nbsp;Paul Prescod<br><br></div></div>