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

[Jim Jewett]

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:

> > > 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.

> Almost certainly, but the point is that you could get back to what you
> wanted via str(obj), unicode(obj), etc., which would incur (in the worst
> case) the overhead you saved before, or raise a MemoryError exception
> (unless its linux, in which case you will likely segfault).

> > 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.)

> I'm not terribly concerned about the implementation details of an object
> I don't need to use.  As long as it works, it is fine.  I am concerned
> about the implementation details of objects I will use.

The reason to ask for these is that then you could use it anywhere a
str could be used (unless they explicitly did CheckExact).  Since the
object itself would be in charge of creating a "normal" str when
needed, you wouldn't have to do it pre-emptively before passing it to
a library.

> I believe the base type included with Python should allocate the memory
> on creation.  Why?  Because the implementation is simple, and I believe
> that a base type implementation should be as simple as possible.

Do you think it should happen to do that as an implementation detail,
or that it should *promise* to do so, and bind all string-alikes to
the same promise?

-jJ