hans at zephyrfalcon.org
Thu Oct 21 18:32:55 CEST 2004
Chris S. wrote:
> Josiah Carlson wrote:
>> In terms of .len() vs .__len__(), it is not supposed to be called
>> directly by user code; __len__() is called indirectly by the len()
>> builtin (and similarly for the other __<op>__() methods, check common
>> spellings in the operator module).
> I realize that. My point is why? Why is the default not object.len()?
> The traditional object oriented way to access an object's attribute is
> as object.attribute. For those that are truly attached to the antiquated
> C-style notation, I see no reason why method(object) and object.method()
> cannot exist side-by-side if need be.
Python is a multi-paradigm language. It supports OO, but also
imperative and functional styles. There is nothing "antiquated" about
the len() notation, it's simply a different style.
Admittedly, it has been there from the very beginning, when not every
built-in object had (public) methods, so obj.len() was not an option
> Using method(object) instead of
> object.method() is a throwback from Python's earlier non-object oriented
There were no such days. Python has always been object-oriented.
> and something which should be phased out by p3k. Personally, I'd
> like to see the use of underscores in name-mangling thrown out
> altogether, as they "uglify" certain code and have no practical use in a
> truly OO language, but I'm sure that's a point many will disagree with
> me on.
I don't know what "truly OO" is. It appears that every language
designer has his own ideas about that. Hence, Java's OO is not the same
as C++'s, or Smalltalk's, or Self's, or CLOS's, or...
I suppose it might be clearer if one could write
def +(self, other):
but then again it might not. I personally don't have a problem with
__add__ and friends.
More information about the Python-list