
Python: Why can’t we write list.len()? - ceronman
http://stupidpythonideas.blogspot.com/2016/02/unified-call-syntax.html
======
ThatGeoGuy
> It’s become part of the “modern C++ dogma” that free functions are part of a

> type’s interface, just like public members. But some things that are part of
> a

> type’s interface, you call function-style; others, you call dot-style—and,

> because there’s no rhyme or reason behind the distinction, you just have to

> memorize which are which. And, when designing types, and protocols for those

> types to interact with, you have to pick one arbitrarily, and be careful to
> be

> consistent everywhere.

Is this really it though? I don't agree that "there's no rhyme or reason
behind the distinction." In fact, it's probably because non-member functions
improve encapsulation [1], and because it is not possible to calculate the
length of an internal buffer in C++ from outside the class. Unlike in Python,
you can't access "private" or implementation specific members in a C++ class,
so getting the length of a list or vector is something that has to be part of
the class. On the other hand, you can access elements of a class without
needing the underlying implementation, so it's reasonable to write a find
procedure that is separate from the class itself.

For this reason, you're not "pick[ing] one [protocol] arbitrarily," you're
doing it to preserve encapsulation and thus have a stronger object
orientation. Perhaps the author can shed some light on what they meant here.

EDIT: minor formatting of quote

[1] [http://www.drdobbs.com/cpp/how-non-member-functions-
improve-...](http://www.drdobbs.com/cpp/how-non-member-functions-improve-
encapsu/184401197)

------
w8rbt
Because len() is a global function. That's perfectly fine in an OO system
(everything does not have to be an object, attribute or method). Sure, it's
not as consistent as anything.len(), but it works just fine. That's often the
reason why Ruby claims to be a cleaner OO implementation than Python.

To me, Python really shows its warts when reversing a string. Something you
never do out side of school (or on big ending to little endinan conversions).

In Python 2:

    
    
        string[::-1]
    

In Ruby:

    
    
        string.reverse()
    

Now that's mind boggling and totally yucky.

