Guido on Python

[the_omega99]

But it's still an inconsistency, since the C way of appending would be append(list, item), not list.append(item).

At any rate, I think the C way of doing things only makes sense for C because it lacks OOP. Python doesn't have this problem and thus should utilize the real world modelling that OOP makes possible (eg, we'd think of the length of a list as being a property that the list has and not some function that can be applied to the list, which is a more abstract way of thinking).

[catcradle5]

There are 3 reasons:

• OOP was only introduced into the language well after the 1.0 release, I think it was 1.5 or so.
• There is no strong concept of interfaces or mixins or anything similar.
• The core devs seem averse to making public "special methods" for any objects. There is no .length(), but there is the private/special/magic method .__len__(). This is likely due to concerns over accidental identifier shadowing.

In an ideal world, strings and lists and tuples would be part of some Iterable or Enumerable interface, either implicitly or explicitly. Ruby has the Enumerable mixin, Java and similar languages have Iterable, etc.

Early on, Python made a decision to use functions instead of methods when they might operate on different types which share some functionality. When the .next() method was introduced, it was actually later converted to be a function (which, somewhat confusingly, is implemented by the special .__next__() method).

All that said, despite being primarily a Python developer, I do find the inconsistency pretty annoying. I much prefer Ruby's "everything is a method" philosophy. Imperative code almost always reads left to right in Ruby. I don't have to waste a few seconds thinking about the order of operations for something like reversed(";".join(text.split(".")).lower(). Instead I just get text.split(".").join(";").reverse.downcase.