len(my_list)
my_list.__len__()
And for other unary "magic methods", the disconnect can be even bigger. E.g. iter(x) is not just a synonym for x.__iter__() - it can also produce an iterator for something that only provides __len__ and __getitem__.
In the Ruby way, with otherwise similar setup, you would have a mixin that provided __iter__() given __len__() and __getitem__(), and classes that had the last two but wanted the behavior of the first would just include that mixin class as a parent, rather than having a separate branch in iter() to handle the different cases. (Ironically, its one way that Ruby is less TMTOWTDI than Python is.)
Python does have such a mixing, it's collections.abc.Sequence https://docs.python.org/3/library/collections.abc.html#colle...
somestring=somearray.join(' ')
somestring=' '.join(somearray)I don't use either Ruby or Python but I think that the first way is more natural.
foldLeft(tail(array), str(head(elem)), (acc: String, elem: T) -> acc + ',' + str(elem))
1 ",".join(["a", "b"])
2 ["a", "b"].join(",")
3 ",".split("a,b")
4 "a,b".split(",")
In Ruby it's 2 and 4.
I'm out of luck twice but at least Ruby has a and b always to the left and the comma always to the right so I always remember it.
print('Hello '.join('world!'))
I just don’t understand why Python thinks it necessary to define global functions for something that naturally should exist as a method.
And, of course, there’s no way to know up front when to use a global function vs when to use a method.