[Python-checkins] CVS: python/dist/src/Lib string.py,1.46,1.47

[Gerrit Holl]

<quote name="Fredrik Lundh" date="951241714">
> bjorn <bjorn at roguewave.com> wrote:
> > I must respectfully disagree.  When doing OO design, the fundamental
> question
> > is "if I want to do 'foo', to what am I doing 'foo'?"...  In this case "if
> I
> > want to 'join', what am I 'joining'?", the answer is that you're joining a
> > sequence type.  Thus, IMHO it the natural (and extensible to user types)
> way
> > to do it would be:
> >
> >     [1,2,3].join()
> >     (1,2,3).join(' ')
> 
> umm.  you seem to be missing a few things:
> 
> -- python 1.6 will have *two* different string types.
> 
> -- python 1.6 will have lots of sequence types (at
>    least one more than 1.5.2!)

If types will eventually be classes, I think it would not be hard to
add one method to all SequenceTypes.

> -- while join can be *defined* as a series of concatenations,
>    *implementing* things that way doesn't work in real life.  do
>    you really think that *all* sequence objects should know
>    how to join all possible string types in an efficient way?  or
>    is that better left to the string implementation?

I find 'string.join(['a','b','c'], '\t') MUCH more readable than
tab.join(['a','b','c']). I'll probably keep using the former.

> -- there is no common base class for sequence objects.

Not yet. If it will be, I find it much better to have the method
added to the Sequence.

> still convinced that all sequence containers should be
> required to know how to concatenate strings?

Yes.

> > if you think of another domain, say a gui with a textarea this might
> become
> > clearer. Nobody would want to write:
> >
> >     "foo bar".put(textarea)
> 
> read the list of issues again.  still think this is a
> great example?
> 
> > Besides has anyone even considered " ".join(myUserListDerivedClass)?
> > How about " ".join(myTreeThatHasLinear__getitem__)?
> 
> if you mean what I think you mean, this already works
> in 1.5.2
> 
> btw, string.join(sequence, separator) won't go away.
> (it'll call separator.join to do the work, but that's just
> an implementation detail ;-)

I'll still use that one.

regards,
Gerrit.

-- 
Comparison Python GUI's: http://www.nl.linux.org/~gerrit/gui.html
Please comment!