[Python-checkins] CVS: python/dist/src/Lib string.py,1.46,1.47
bjorn
bjorn at roguewave.com
Tue Feb 22 13:25:32 EST 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