String.join revisited (URGENT for 1.6)

[Johannes Stezenbach]

Fredrik Lundh <effbot at telia.com> wrote:
>Eric Jacobs wrote:
>> Doesn't seem like it would have to. Just imagine a method in the sequence
>> "class" that said:
>>
>>      def join(self, separator):
>>          result = self[0]
>>          for x in self[1:]:
>>              result = result + separator + x
>>          return result
>>
>> No new operators are necessary, unless you want join to do something
>> completely different...
>
>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.

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.

The now implemented separator.join(list) looks wrong to me.
Not that I couldn't get used to it, but in the light of considering
something as evil as case-insensitivity in an attempt to make Python
easier for beginners, this seems to be at least questionable.

Guess-what-the-number-three-problem-of-future-Alice-users-will-be-ly y'rs
Johannes