^ this ^ never understood why certain methods (or are they functions?) are not called on the objects. This is one of the reasons I love Ruby, everything is clearly an object.

> ^ this ^ never understood why certain methods (or are they functions?) are not called on the objects.

Because they don't depend on a given class, they're protocols. There's no "master class" in which to put them, so they go in some sort of bastardized CLOS-like generic method instead.

With duck typing, that shouldn't matter. Lots of methods in the Python standard library take "file-like objects" that have read() methods and no common superclass, and that works fine without read being a top-level function.

There's no need for a super class to have a len() method. I don't get your reasoning here, Python is not a statically typed language.

reasoning by BDFL here: http://stackoverflow.com/a/237312/1188079

Similarly weirdly, the string join method really confuses me:

    ''.join([1, 2, 3])

That actually makes sense. Because the joining is something that a string knows how to do. Why should arbitrary lists know about string manipulation?

By the way, your example has an error, since you can't join a list of numbers. You can only join lists of strings. I.e.

    ' '.join("Hello", "World")

It seems strange at first but now it feels pretty natural. The alternatives might be to have a new global function (like len) or to have every possible iterator type have join (which sounds complicated).

In python 1.X it was a function under the string module. This is maintained in 2.x but goes away in 3.x.

string.join(['1','2','3'], ' ') == ' '.join(['1','2','3'])

It is rather arbitrary yeah, but I don't mind it. Len kind of makes sense as a function.