[Python-3000] Making more effective use of slice objects in Py3k (original) (raw)

Paul Prescod paul at prescod.net
Thu Aug 31 10:05:18 CEST 2006

On 8/30/06, Jack Diederich <jack at psynchronous.com> wrote:

On Wed, Aug 30, 2006 at 08:56:03PM -0700, Bob Ippolito wrote: > > and also based on the cET (and NFS) experiences, it wouldn't surprise me > > if a naive 32-bit text string implementation will, on average, slow things down > > more than any string view implementation can speed things up again... > > > > (in other words, I'm convinced that we need a polymorphic string type. I'm not > > so sure we need views, but if we have the former, we can use that mechanism to > > support the latter) > > +1 for polymorphic strings. > > This would give us the best of both worlds: compact representations > for ASCII and Latin-1, full 32-bit text when needed, and the > possibility to implement further optimizations when necessary. It > could add a bit of complexity and/or a massive speed penalty > (depending on how naive the implementation is) around character > operations though. Having watched Fredrik casually double the speed of many str and unicode operations in a week I'm easily +1 on whatever he says. Bob's support makes that a +2, he struck me as quite sane too. That said can you guys expand on what polymorphic[1] means here in particular?

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.

Paul Prescod -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-3000/attachments/20060831/0f61bc29/attachment-0001.htm

More information about the Python-3000 mailing list