[Python-Dev] Re: [Python-Dev] RE: [Python-Dev] Re: [Python-Dev] String methods... finally

Ka-Ping Yee ping at lfw.org
Tue Jun 15 10:50:34 CEST 1999

On Tue, 15 Jun 1999, Mark Hammond wrote:
> > hmm.  consider the following:
> >
> >     space = " "
> >     foo = L"foo"
> >     bar = L"bar"
> >     result = space.join((foo, bar))
> >
> > what should happen if you run this:
> >
> >     a) Python raises an exception
> >     b) result is an ordinary string object
> >     c) result is a unicode string object
> Well, we could take this to the extreme, and allow _every_ object to grow a
> join method, where join attempts to cooerce to the same type.

I think i'd agree with Mark's answer for this situation, though
i don't know about adding 'join' methods to other types.  I see two
arguments that can be made here:

    For b): the result should match the type of the object
    on which the method was called.  This way the type of
    the result more easily determinable by the programmer
    or reader.  Also, since the type of the result is
    immediately known to the "join" code, each member of the 
    passed-in sequence need only be fetched once, and a
    __getitem__-style generator can easily stand in for the

    For c): the result should match the "biggest" type among
    the operands.  This behaviour is consistent with what
    you would get if you added all the operands together.
    Unfortunately this means you have to see all the operands
    before you know the type of the result, which means you
    either scan twice or convert potentially the whole result.

b) weighs more strongly in my opinion, so i think the right
thing to do is to match the type of the separator.

(But if a Unicode string contains characters outside of
the Latin-1 range, is it supposed to raise an exception
on an attempt to convert to an ordinary string?  In that
case, the actual behaviour of the above example would be
a) and i'm not sure if that would get annoying fast.)

-- ?!ng

"In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand."
    -- Gerald Holton

More information about the Python-Dev mailing list