[Python-Dev] Re: [Python-Dev] RE: [Python-Dev] Re: [Python-Dev] String methods... finally
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.)
"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