I come to praise .join, not to bury it...

[Russell E. Owen]

In article <97rka002k9 at news1.newsguy.com>,
 "Alex Martelli" <aleaxit at yahoo.com> wrote:

>"Russell E. Owen" <owen at astrono.junkwashington.emu> wrote in message
>news:97p7iq$kk2$1 at nntp6.u.washington.edu...
>    [snip]
>> However, I do agree that join is not intuitive. I believe the problem
>> (at least for the way I look at it) is that join should be a list
>> method, not a string method. I.e.:
>>
>>   joined_string = ['a', 'b'].join(', ')
>>
>> makes a lot of sense to me. The current join string method does not.
>
> (long discussion about polymorphism omitted).

I'm afraid I don't understand where the polymorphism comes in, so I 
cannot comment on that.

>...
>Say that I'm implementing a sequence-like object.  Would
>having .join as a part of the set of methods I must write
>be an _advantage_ to me?  As things stand now, to "be a
>sequence" I must just implement __getitem__ in the
>appropriate manner -- accepting an index from 0 to N-1,
>and raising IndexError for indices outside the range -- and
>maybe implement __length__ to return N.  With this small
>amount of effort, I gain the ability to be used as sequence
>in any existing context -- from the for statement onwards.

I'm afraid we disagree here. Collections can all inherit from a parent 
collection class, a perfectly reasonable requirement. You then define 
the few methods that are required to make your own kind of collection. 
The parent class should define things like join (which is, of course, a 
very simple method).

-- Russell