I come to praise .join, not to bury it...

[Greg Ewing]

Alex Martelli wrote:
> 
> No!  string_join (in stringobject.c) currently just _checks_
> PyString_Check on the items -- if any item fails that, it
> delegates to PyUnicode_Join (if PyUnicode_Check OK's that).

And that's somehow not a typeswitch? If it's a regular
string do this... if it's a Unicode string do that...
smells like a typeswitch to me...

You seemed to be arguing that dispatching on the joiner
somehow resulted in an efficiency gain by going straight
to the right code for the kind of strings being joined,
and I was pointing out that that's not the case. But
maybe I misunderstood what you were saying.

> You gain a clean approach, which the implementation could
> (and should) exploit to access the items in the sequence
> through the _appropriate_ standard interface

It's only clean according to one measure of cleanness.
It could be considered cleaner to treat all the arguments
uniformly, and access them *all* through a standard
interface.

> There are NO technical costs associated with these
> advantages.

I disagree. I've mentioned one already -- it bloats the
string object, and makes the Python core larger and
less modular. 

> Only technical advantages and costs
> can be fairly put on the balance

I disagree with that, too. I think it's quite possible
and appropriate for a small technical advantage to be
outweighed by a larger aesthetic one. For example, there
are technical advantages to braces instead of indentation:
the scanner is easier to implement, it's easier to write
programs which generate code, and there's no chance of
space-tab confusion. On the indentation side, there's the
advantage that indentation and block structure always
agree. If you're counting technical advantages, that's
one in favour of indentation and three against. But I
doubt Guido would switch on that basis.

> Note that I've seen NO arguments AT ALL for having
> .join be a method on SEQUENCE object ... despite this 
> being often mentioned on an irrational-purely-aesthetical 
> basis.

I don't think the basis is irrational at all. It
seems to me that there are two quite distinct possible
reasons for deciding to make something a method of a
particular object.

One is to get polymorphism on that object. The other
is because the object makes sense as the direct object
(in the English grammar sense) of the operation, so
that you can naturally read x.verb(y) as "verb x
with y" or "verb x using y".

When these two considerations pull in the same
direction, all is well. And with most of the string
methods they do, but in the case of join, they don't.
There are good reasons for not making it a method of
the sequence, but when it is made a method of the
joiner, the resulting expression sounds backwards[1].

So we are faced with two alternatives, neither
of which are entirely good. In such cases, my
preference is not to choose either alternative --
i.e. make join a function, not a method.

Footnotes:
[1] In English, anyway. Maybe it doesn't sound backwards
    in Dutch. Hmmm... is THAT why Guido accepted it?

-- 
Greg Ewing, Computer Science Dept, University of Canterbury,	  
Christchurch, New Zealand
To get my email address, please visit my web page:	  
http://www.cosc.canterbury.ac.nz/~greg