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

Fredrik Lundh effbot at telia.com
Tue Feb 22 19:48:34 CET 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