String.join revisited (URGENT for 1.6)

[Fredrik Lundh]

Johannes Stezenbach wrote:
> >like, for example, joining strings efficiently?
> >
> >(If you don't see my point, try benchmarking your code vs. string.join
> >on 10, 1000, 100000 substrings. Do you think the timing difference can
> >be eliminated by writing your code in C?)
> 
> So why not using the C equivalent of
>
>     def join(self, separator):
>         if type(separator) == type(""):
>             # insert efficient implementation of current " ".join here
>         else:
>             result = self[0]
>             for x in self[1:]:
>               result = result + separator + x
>           return result
>
> and by that having both efficient (for strings) and general (usable for
> other types) list element joining.

have you looked at "string.join" in 1.6?

here's the actual code:

    def join(words, sep = ' '):
        return sep.join(words)

it's not that different from your example, with one notable exception:
it doesn't work if the separator class doesn't provide an "efficient
implementation of join".

(on the other hand, it works for any type providing an implementation,
not just 8-bit strings.  python 1.6 has more than one string type, you
know...)

now, would your modified version be a great improvement over the
current 1.6 release?  that pretty much depends on your answers to
these two questions:

-- does "join" really make sense on things that are not strings?
   (hint: does "+" always mean concatenation?  does "join" make
   sense if it doesn't?  should join([1, 2, 3], 10) really return 36?)

-- does it really matter if the implementation hook happens to be
   called "join"?

in the current release, the answers are "no" (hypergeneralization)
and "no" (no matter what it's called, people will find it and use it).

if you have better answers, please motivate.

> If I remember this right, the argument against list.join(separator)
> was "don't put string knowledge in the list class". But with the above
> implementation this is avoided because the efficient string joining
> is just a special case optimization which isn't visible from the outside.

oh, you just have to close your eyes and pretend it's not visible ;-)

</F>