[Python-checkins] CVS: python/dist/src/Lib string.py,1.46,1.47
Fredrik Lundh
effbot at telia.com
Tue Feb 22 13:48:34 EST 2000
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!)
-- 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?
-- there is no common base class for sequence objects.
still convinced that all sequence containers should be
required to know how to concatenate strings?
> 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 ;-)
</F>
More information about the Python-list
mailing list