[Python-3000] Making more effective use of slice objects in Py3k

[Paul Prescod]

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