Python's join seems to focus not on the items to join, but on the symbol, as compared to Ruby or Smalltalk, for a design reason?

Question

I thought one of the cornerstone of OOP is that, we have objects, which are the items we are interested in dealing with, and then we send messages to them.

So it may seem natural that, I have a collection of items, and I need to put them into one string, so to do it:

  ["x", "o", "o"].join(" | ")    # joining a tic-tac-toe row in Ruby

(Smalltalk does it the same way). The " | " is in some way thought of as an argument, one token of how to join it. It can be " " too, if the game board is to be simpler. So the joining element " | " is not particularly something we have interest in -- it is not the main objects in the program that have particular importance or significance.

If Python does it using

  " | ".join(["x", "o", "o"])

It does feel somewhat strange that it almost feels like we are passing a message to the argument, to tell the argument about something. Maybe Python is more procedural? To tell the joining string to perform some duty for us?

Is it to save implementation, so that we don't have to define a join for each collection class we have? But isn't it true that we can also just write once for any collection class, such as in Ruby:

module Enumerable
  def my_join(joiner)
    self.inject {|a,b| a.to_s + joiner + b.to_s}
  end
end

(something like this, calling to_s on each item, relying on the to_s of each class to do its own proper thing, to convert to a string, and then concatenating them). So then we don't have to implement for each of String, Hash, or Set, or whatever collection class we have.

Or does Python out right doesn't go the OOP route? It uses len("abc") and type([]) instead of "abc".len() or [].type() even in Python3 too it seems. Does Python do it this way for a design reason?

Answer 1

Python's join is designed to work on any iterable. This means the designers had to decide where to put it. Since it works on more than just lists, but always requires(separator) and returns a string, they decided to make it part of the string type.

Armin Ronacher says it better than me:

http://lucumr.pocoo.org/2011/7/9/python-and-pola/#seemingly-inverse-logic

"Imagine Python would not work that way. You would have to convert the iterable into an actual list first to convert it into a string. Ruby people will now argue that Ruby solves this problem with mixing in modules, and they are certainly correct that this is an option. But this is a concious design decision in the language which has many implications. Python encourages loose coupling by having these protocols where the actual implementations can be elsewhere. One object is iterable, another part in the system knows how to make it into a string."