[Python-checkins] CVS: python/dist/src/Lib string.py,1.46,1.47
Gerrit Holl
gerrit.holl at pobox.com
Tue Feb 22 15:13:26 EST 2000
<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!
More information about the Python-list
mailing list