[Python-ideas] The non-obvious nature of str.join (was Re: sum(...) limitation)

[Andrew Barnert]

On Monday, August 11, 2014 12:56 PM, Terry Reedy <tjreedy at udel.edu> wrote:



> Given that the two parameters of join are a concrete string and the 
> abstraction 'iterable of strings', join can only be a method of the 
> joiner.


In many languages (those with generic types), the notion of Sequence<String>, or S:Sequence where S.ElementType==String, or similar, makes sense.

The problem is that you can't define methods on specializations of types, only on the generic types. And Sequence.join makes no sense, because that implies the nonsensical Sequence<int>.join. (Neither of those applies to C++, where you can add methods to specializations, or add methods to the template and they just don't appear on specializations where they make no sense because of SFINAE. But I don't know of any other language that does things that way.)

But since most of those languages have leaky type systems despite most of them supposedly being statically strongly typed, it "works".

It's been fun to watch people try to do the same thing in Swift, which really is strongly typed, and will not let you define a Sequence.join method unless it compiles for any ElementType. Of course there's no such problem defining a String.join method whose parameter is S:Sequence where S.ElementType== String, so String.join works just fine. So anyone coming to Swift from Python can add a join method without even thinking twice, while anyone coming from any other language will fight with the compiler for a while, then give up and either copy to an ObjC NSArray types to escape the type system, or copy and paste their join loop all over their code.

But anyway, pointing out that every OO language gets this wrong may be entertaining, but it doesn't help the fact that everyone coming to Python from those other languages looks for it in the wrong place.