Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count.
The Python weirdness is actually a direct result from the language lacking generics…
For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.
Of course such non-discoverable and unintuitive design gets ignored everywhere!
We just established that even in Python the correct way to do it would be
Iterable[str].join(str) -> str
> For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.
So you're saying you've been able to implement custom Scala collection types, which is regarded some of the more difficult stuff one could possibly do, but you don't know how to implement an Iterator for your custom collection—as this is all needed for mkString to work? BTW, how did you implement the collection type at all without implementing Iterator for it? Your collection is not Iterable?
TBH, this does not sound very realistic. This sounds more like typical HN Scala FUD. People throwing around some vague, most of the time outright made up issues they've heard about somewhere about 10 - 15 years ago.
The semantically correct one is "Container[T : Printable].join(): String"; T must implement the Printable concept, but Python lacks concepts (or type-classes as these are alternatively called).
But this all is irrelevant as this is anyway not the signature of `str.join()` in Python. It's `str.join(Iterable[str]) -> str` there. With sane design and syntax it would just become `Iterable[str].join(str)`.