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

bjorn bjorn at roguewave.com
Tue Feb 22 19:25:32 CET 2000


Tim Peters wrote:

> [Greg Ewing]
> > Oh, no, nooo, nooooooo...
> >
> > Is there time to stop this madness?
>
> Doubt it.  It was debated at length before Barry implemented it.  Write it
> this way instead, and it reads beautifully & naturally:
>
> tab = "\t"; space = " "; nospace = ""
>
> tab.join(list_of_strings)
> space.join(ditto)
> nospace.join(user_sequence)
>
> That is, you don't *have* to use a character literal (which indeed "looks
> funny", although less and less so the longer the string).
>
> > ...
> > Whatever you do, don't stuff it onto some arbitrary
> > type just for the sake of making it a method.
>
> It's not arbitrary.  The essence of the current string.join is the string
> used as glue; indeed, that's why join has been in the string module all
> along.

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(' ')

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)

since the "right" way to do it would be:

    textarea.put("foo bar")

Besides has anyone even considered " ".join(myUserListDerivedClass)? How about
" ".join(myTreeThatHasLinear__getitem__)?

Just my 2% of $1.

-- bjorn





More information about the Python-list mailing list