"Jim Jewett" <[EMAIL PROTECTED]> wrote: > > On 1/31/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > P.S. One of the reasons why I have been pushing for a wrapper, is > > primarily because 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 (with a sufficiently restricted meaning of 'anything'). > > What exactly do you mean by a wrapper? > > Are you thinking of something like a 3rd-party library providing a > 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, > and the good from neither.
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. The portions that didn't conform were the portions I didn't implement. Implementing the single segment buffer interface made it usable to be passed to socket.send(), file.write(), etc., and implementing a proper __str__ method made the objects usable as a source perhaps when passing to some other API that *needed* a str. The point of such a lazy concatenation/slicing wrapper, derived from Larry's patches, would be to offer the exact same API as unicode. Basically anywhere you could use unicode before, you could use the new object. If you _needed_ to have a unicode object, you would use unicode(obj) (or whatever it is renamed to in Python 3). Certainly it could be distributed as a 3rd party module (I would consider downloading and installing it), but I believe the point of it would be to include it with Python, maybe accessable via 'import string', 'import collections', or somewhere else. - Josiah _______________________________________________ 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
