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

[Josiah Carlson]

"Jim Jewett" <jimjjewett at gmail.com> wrote:
> 
> On 1/31/07, Josiah Carlson <jcarlson at uci.edu> 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