On 1/31/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > "Jim Jewett" <[EMAIL PROTECTED]> wrote: > > On 1/31/07, Josiah Carlson <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
