[Python-3000] Poll: Lazy Unicode Strings For Py3k

Wed Jan 31 22:14:04 CET 2007

On 1/31/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> "Jim Jewett" <jimjjewett at gmail.com> wrote:
> > On 1/31/07, Josiah Carlson <jcarlson at uci.edu> wrote:

> > > ... I believe that the added complexity to the *base type*
> > > is too much, while a wrapper object would be free to do just about
> > > anything

> > ... string-like object which doesn't claim to inherit from str, and has a
> > subtly different API? That seems to get the bad from both choices,

> Do you remember my "string view" post from last September/October or so?
> It implemented almost all of the string API exactly as the string API
> did, except that rather than returning strings, it returned views.

So there would be places where you couldn't safely use it, even though
it had all the required functionality.
How would you feel if it also
(1) Claimed to be a subclass of str (though it might not actually
inherit anything)
(2) Implemented the rest of the methods by delegation. (Call str on
itself, switch its "real" object to the new string, and delegate to
that.)
If these slight extensions are OK, then we agree that it should be
possible to use multiple implementations of str, and I don't see the
point of insisting that your strview isn't a real string. (And then
we move to the next step, where I ask that the API stop promising to
preallocate the data in a particular place.)
-jJ